0.5 Northgate Group: Incidents, Obligations and Evidence

Introduction

An organization's history is design evidence. Its incidents show which controls failed under real attack; its audit findings show which controls exist on paper and not in practice; its obligations show what it must be able to prove, to whom and how fast.

An architect who reads the history designs for the failures the organization has actually had and the duties it actually carries, which a generic threat list can't supply.

Northgate Group's history is short and busy. In 2026 it had seven security incidents across three companies, nine findings from audits, tests and reviews, and a peer company's ransomware attack that the CEO forwarded to the board. It carries obligations under UK, German and EU law, under two defense customers' contracts and possibly under US export control.

The figure lays the year out in the order it happened. This lesson takes the incidents, the findings and the obligations in turn, then the sensitive data those obligations protect and how it moves, and ends with the evidence pack: the files every later module draws on.

An incident is the most honest evidence an estate produces, because it shows what a control did when it mattered, whatever it was configured to do.

For an architect, the question about each incident is which assumption in the design failed, and whether the same assumption is still holding up something else; who was at fault is a question for someone else. Northgate's seven fall into a few shapes, and the shapes matter more than the count.

The first shape is a control that worked and didn't protect. In I-1, from 27 February to 3 March, an adversary-in-the-middle proxy copied Catherine Richardson's session after she passed MFA; the session was replayed against Exchange Online that evening and on 2 and 3 March, and a forwarding rule sent her mail outside, which the default outbound policy allowed.

In I-6, on 12 March, ransomware ran on Laura Bennett's laptop from a macro document saved by Outlook, while Intune reported the laptop compliant; Defender detected it at 11:02, running and not remediated.

The second shape is an account the policy never saw. In I-2, on 7 March, the directory synchronization account signed in from 185.220.101.47 with a password alone, and the sign-in log reads "Conditional Access: not applied". In I-7, on 15 March, a domain compromise reached a synchronized account holding Global Administrator, which then signed in to the Azure portal. Both are control-plane accounts outside the access design.

The third shape crosses a boundary. I-4 began at Präzision's domain, whose SPF record still included a former host's range, and ended in Northgate's finance team as a forged invoice that nothing rejected.

I-5, in August, began in a customer's real mailbox, where a reply in a genuine thread changed the bank details for a $186,400 payment that Systems paid, because payment changes were verified by email alone. I-3, in May, was a contractor's personal phone, lost at Birmingham Works with company mail on it and nothing able to wipe it.

Reading an incident well takes more than its summary: when it started, how and by whom it was detected, how long it ran and what stopped it. Where Northgate's records are silent on those points, the silence is information too. The records that do exist are pointed. I-1's session was replayed on three separate days before anyone acted, which says as much about detection as about authentication.

I-6 was detected and not remediated, so the endpoint product saw the attack and nothing was set to stop it. I-2's sign-in log names its own cause, and the place to look for the next one is the same log, filtered to the accounts no policy covers. Each incident becomes the inject for the lab in the module that designs against it.

A finding is a gap someone found by looking, before or after an attacker did. Its source tells you how far to trust it and what evidence will close it, because each kind of source tests something different. Read the source before the content, since a finding from a tabletop and one from a configuration review can describe the same gap and need entirely different evidence.

An internal audit tests whether controls exist and have evidence, so July's audit produced governance findings: of 64 controls in the register, 23 have no named owner and 31 no evidence they work (F-1), and the group has nine permanent Global Administrators, three of them held by outside providers (F-2).

A penetration test tests whether an attacker can reach something: in May the tester relayed NTLM authentication from the Birmingham network to the CAD license server and reached a share of controlled drawings from an unmanaged laptop on the guest Wi-Fi (F-3). It says nothing about controls nobody tried.

Reviews read configuration or reports at a point in time. March's due diligence found the former provider's account and application in Präzision's tenant with no contract obliging their return (F-4). September's application review found a partner integration with Graph application permissions to all mailboxes and no owner (F-6).

September's sharing report found 1,240 files shared outside the group, some through anyone links (F-7). October's change review found a Conditional Access change that couldn't be reversed exactly because nobody had exported the policy first (F-9), which makes every later change to access policy a change with no exact way back to the state before it.

A tabletop tests people and authority, and October's found what no review would: at 02:00 nobody on call could revoke a director's sessions, and Watchpoint escalated to a phone that was off (F-8).

None of the nine is closed, and their dates make the point. The audit's finding on permanent Global Administrators came four months after I-7, in which a synchronized account holding that role was used against the cloud: the evidence had already arrived from an attacker before the audit wrote it down.

Secure Score (F-5) reads Northgate 61 percent, Präzision 38 percent, Systems 29 percent, which is useful for tracking one tenant over time and weak for comparing three tenants whose licenses decide which points each can earn.

Events at peer companies reach boards more often than internal findings do, because a board can picture them. In September 2026 a UK hydraulics manufacturer of similar size lost three weeks of production to ransomware that began with a compromised remote-access account and ended with its backups encrypted. Northgate's CEO sent the article to the board with one line: "Could this happen to us?"

That question is harder than it looks. The board wants to know whether the specific chain that hurt a company like theirs would work at Northgate, how far it would get, and how long recovery would take. Answering it means walking the peer's chain through your own estate, one step at a time, and asking at each step what Northgate's own records say.

The case has already turned the question into requirements. SR-19 asks that the group can restore mail and files deleted by an attacker, for every company, and cites the peer event as its source. NFR-03 sets the objectives: recovery point for group mail and files is 24 hours or better; recovery time for the ERP and email is 8 hours.

The risk appetite adds that the board won't accept an unplanned stop of production systems during working hours. Read the figure against the incidents and the walk is uncomfortable: I-1 showed remote sessions can be taken, I-7 showed a directory compromise reaching Global Administrator, and the backup question has no answer in the records yet.

Modules 9 and 21 take the question up, from endpoint protection and from recovery. When they do, the peer's chain is the test: a design passes if each step meets a control that stops it or a recovery that outlasts it.

An obligation is something an organization must do because a law, a regulator or a contract says so. Obligations differ from requirements in one way that matters to an architect: the organization doesn't get to decide them, only how to meet them. Northgate has seven, each traced to the law, regulation or contract it comes from, and each names the company it binds, which isn't always the whole group.

The type is the first thing to read. Law applies whether or not anyone knows about it: UK GDPR for Northgate Engineering (O-1), EU GDPR for Präzision and EU staff data anywhere in the group (O-2), the works council's co-determination over systems that monitor staff at Präzision (O-3), and NIS2 as Germany's rewritten BSIG for Präzision and possibly the group (O-4).

Contracts bind because Northgate signed them. The UK prime's contract flows down DEFCON 658 and Def Stan 05-138, with a 24-hour notice to the prime and 12 months of security logs (O-5).

The US prime's will carry DFARS 252.204-7012 and CMMC Level 2 for Systems: a 72-hour report to the DoD, 90 days of images of affected systems, and NIST SP 800-171 protection (O-6). US export control may apply to some drawings and software, pending classification (O-7).

Some of these carry dates and duties a design has to plan around. The UK prime's assurance is a Supplier Assurance Questionnaire repeated every year, so its evidence has to be producible every year, not once. CMMC's second phase begins on 10 November 2026, when the DoD intends to require Level 2 status assessed by a third party, which puts Systems' assessment on a fixed clock.

And the works council's co-determination right at Präzision covers introducing and using systems that can monitor staff behavior or performance, which can include security monitoring that records what staff do, so its consultation is a step in the rollout plan, planned before the change.

This course isn't legal advice, and neither is the case. It tells you what Northgate believes applies; deciding whether that's right is a lawyer's job, and deciding what it means for the design is yours. The way in is to read each obligation for its verbs.

UK GDPR requires a notifiable personal data breach to be reported to the ICO within 72 hours of becoming aware of it. Behind "report" are three capabilities: detecting the breach, scoping which personal data it touched, and deciding within the window whether it's notifiable. Each needs evidence the design is already collecting when the breach happens, because none of it can be gathered afterward.

Every verb in the seven, report, retain, restrict, consult, evidence, becomes a capability and an artifact the design must be able to produce on demand.

Two of Northgate's obligations are open questions, and neither will be settled by the time you start designing. Präzision appears to be an important entity under the BSIG at 140 staff, and whether the group's size counts toward the threshold is a question nobody has yet raised, which falls to you.

Whether some drawings and software are ITAR or EAR technical data is with an outside adviser. Either way, O-7 asks that the technical data be identifiable and restricted to authorized people, including in Copilot and in sharing, and it leaves where the data may be stored to the design, which is the decision the classification will eventually constrain.

An architect's response to an open question is to design so that the answer, whichever it is, changes a parameter and leaves the architecture standing.

If Präzision is an important entity, it registers with the BSI within three months and reports a significant incident within 24 hours, 72 hours and one month. If it isn't, it has no such duty. A design that already gives Präzision the detection and reporting path a 24-hour report needs works either way; the answer only decides whether the report is sent.

The export question works the same way: a design that can identify the data, restrict it to named people and keep it in a chosen location absorbs either answer as a change to the list of people and the location.

Open questions go in a deliverable as assumptions, each with an owner and a date by which an answer is expected. When an answer arrives, the assumption is closed and every decision that depended on it is checked.

Without that list, a design quietly hardens around whichever answer its author expected. The list also tells the people waiting on each answer what depends on it, which is often the fastest way to get the answer.

Obligations protect data, and designs protect data where it is and where it goes. The group's own record of its sensitive data names each kind with its current locations, the people who should reach it and the obligations that apply, and the record is evidence too: it shows what Northgate has noticed, and its gaps show what it hasn't.

The gap between where the data lives and who should reach it is the design problem in miniature.

Customers' controlled drawings should reach named engineers per customer program; they live in the Engineering SharePoint site, engineers' OneDrive, the PLM system and email attachments. Export-controlled technical data sits in Systems' engineering file share and SharePoint, with copies at Northgate, and should reach US persons or authorized staff only.

Payroll and HR records should reach HR and finance per company, and live in three places with three sign-in arrangements. Payment instructions live in email and the ERP, which is where I-5 happened. Security logs and audit records sit in Sentinel and Microsoft 365 audit at Northgate and at tenant defaults elsewhere, although four obligations depend on them.

EU staff personal data sits in Präzision's tenant and HR folder and in group HR reports held in Northgate's tenant, so a report that crosses from Germany to the UK is a transfer that needs a lawful basis under O-2.

Two roles decide what happens to each kind of data. The owner decides who should reach it: the engineering director for drawings, HR for payroll. The custodian runs the systems that hold it. Most gaps exist because an owner's decision was never turned into the custodian's configuration. Data moves, and the pack draws six flows as they run today. Two show the pattern:

The first flow has three routes out of the group, none designed. The second hasn't started: the Copilot pilot will begin with whatever each pilot user can already open, which is why priority 3 put that access in scope.

Every module draws on the evidence pack, so it's worth knowing what it is for before the first lab. It holds 13 files, generated from one data source so that every count agrees across them and with this course. Its limits are part of reading it: nothing after its dates is in it, and nothing nobody wrote down.

Start with the group overview and the stakeholder interviews, which are in each person's own words, including where they contradict each other.

Read Marcus Webb's handover next, because it tells you what he thought mattered and left unfinished. Then the requirements register, with its 50 requirements, sources and owners; the incident and findings log; and the audit and penetration test extracts, which together say what the group wants and what has gone wrong.

The policy extracts include a data classification policy that was drafted and never approved, which matters because every data design later in the course needs a classification someone has signed.

The rest is reference: the as-is and data-flow diagrams in draw.io, the inventories of applications, licenses, devices and privileged roles, and the tenant exports, which are the existing set for Northgate and Präzision and a new one for Systems.

The US prime's questionnaire holds Systems' draft answers, several of which the export contradicts, and it hasn't been submitted. The pack is evidence, with the properties evidence has: written by people with their own purposes, sometimes wrong, and dated.

Practice

Files this lesson draws on

The evidence pack files used in this lesson, each linked for the Practice and for the modules that come back to it:

• 07-incidents-and-findings.xlsx: the seven incidents and nine findings, with dates and owners
• 08-internal-audit-extract-2026-07.docx and 09-penetration-test-summary-2026-05.docx: F-1, F-2 and F-3 as their authors wrote them
• 05-data-flows.drawio: the six data flows as they run today
• 11-us-prime-supplier-questionnaire.xlsx: Systems' draft answers, to test against its export