0.2 Northgate Group: Companies, Plan and Risk Appetite

Introduction

Security architecture starts with the business it serves, before any tenant. What an organization sells, who it sells to, what its customers demand of it, what its board is trying to achieve and how much risk the board will carry all decide which controls are worth building and which are waste. An architect who starts with the estate designs an excellent answer to a question nobody asked.

Northgate Group designs and makes hydraulic and motion-control systems for heavy industry. Until February 2026 it was one UK company. By June it was three: Northgate Engineering in England, Northgate Präzision in Stuttgart and Northgate Systems in South Carolina, each with its own Microsoft 365 tenant, its own IT and its own way of doing things.

The figure is the group as an architect first meets it: one owner and three separate estates with nothing connecting them. This lesson covers the business side of that picture, which the rest of the course is measured against: the companies, the dates, the board's plan, the customers who set the bar, the risk appetite and the money.

Before you look at a single policy, you need five answers about the business, and each one changes the design.

How it makes money. Northgate's revenue depends on a few large customers. A business like that is exposed to its customers' requirements in a way a retailer isn't: lose one prime contractor's trust and a large share of revenue goes with it. That makes customer assurance a design driver, not paperwork.

What it's changing. Two acquisitions in one year mean the estate you're designing is in motion. A design for the estate as it stands today will be wrong by the time it's built, so you design for the group the board intends, with a route from the group that exists.

Who it answers to. Regulators in three jurisdictions and contracts with defense customers in two countries set obligations the design must evidence. Lesson 0.5 sets them out.

What it's trying to achieve. The board's plan gives the order of priorities. When two good designs compete, the plan decides between them.

How much risk it will carry. The risk appetite turns "secure enough" into tolerances you can test a design against.

None of these answers is technical, and none appears in a tenant export. They come from the group's own documents, its people and its contracts. An architect who skips them ends up making the board's decisions without being asked, by choosing which risks matter on the board's behalf.

To get them, read what the business has already written, then talk to the people who own each answer and record what they say, including where they disagree. Northgate's interview notes are in the evidence pack, taken by your predecessor in September.

When you read a company record, look past the name to four things: what it does for the group, how many people depend on its systems, who runs its IT, and how long it has been part of the group. Each changes what a design for that company can assume.

Northgate Engineering Ltd designs and assembles hydraulic systems and is the group's headquarters, with 810 staff across Manchester, Birmingham and Bristol. Its Information Technology department of 42 reports to Phil Greaves, its Information Security team of five to Rachel Okafor, and the Watchpoint SOC monitors it under contract. It runs Microsoft 365 E5 with identities synchronized from on-premises Active Directory.

Northgate Präzision GmbH machines precision hydraulic components on one site in Stuttgart, with 140 staff, and joined in February 2026. Its IT is one person, Jonas Weber, and a former provider that still holds access. Northgate Systems Inc. builds electronic controls and software for hydraulic systems in Greenville, South Carolina, with 304 staff, and joined in June 2026. Its IT is two people and a local MSP.

The differences matter more than the similarities. Northgate Engineering can staff a change, test it and watch its effect. Präzision can do none of that without Jonas Weber, whose name a forged invoice to Northgate's finance team has already used. Systems depends on Saluda Managed IT, which built its policies and holds Global Administrator, so any change there is also a change to what an outside company can do.

Those differences are where most of the group's security risk sits, and also where most of its resistance to change sits. Each company's people have run their own tenant their own way, often for years.

Präzision's managing director wants to keep her company's autonomy; Systems' general manager wants nothing to change before her customer's assessment. A design that treats the three as interchangeable units of one estate will meet both objections in the first meeting.

The three tenants also share nothing. No cross-tenant access settings exist between them, so staff who collaborate across companies do it through guest accounts invited one at a time, email attachments and, for the ERP and PLM systems, Northgate accounts created by hand and reached over a VPN. Lesson 0.4 shows the detail; for now the point is the shape: three islands, joined by workarounds.

One distinction matters from the start, and Module 4 returns to it: a company is a legal boundary and a tenant is a technical one, and they need not match. Northgate's companies each have one tenant because that's how they arrived, and nobody has yet decided whether that should stay true.

A decision that can't be delivered before a deadline isn't an option for meeting it, and a decision that's cheap at a renewal and expensive between renewals should wait for one. An architecture is delivered in time as well as in space. Northgate's has fixed dates on both sides: dates it must meet, and dates on which its options change.

Two of the dates are commitments. The integration requirement, BR-02, says Präzision's staff work in Northgate's systems, and Northgate's in Präzision's, within 18 months of that acquisition, by August 2027. The US customer's supplier assessment must be passed before the contract is awarded, expected in the second quarter of 2027.

The US Department of Defense's CMMC program enters its second phase on 10 November 2026, from which it intends to require third-party Level 2 assessments, so the assessment the customer asks for will be the stricter kind.

The other dates are opportunities. Each company's Microsoft agreement renews on its own date: Systems in December 2026, Northgate Engineering in June 2027 and Präzision in February 2028, the last fixed by the purchase agreement. A renewal is the cheapest moment to change what a company licenses, and the most expensive moment to discover that a design depends on something nobody budgeted for.

The commitments are written into the requirements register, where each should have an owner. BR-02, the Präzision integration by August 2027, is owned by Marcus Webb. BR-03, the supplier assessment before award, is owned by Dana Whitfield, Systems' general manager.

The third, CON-05, says Systems' identity and tenant arrangements may not change in a way that delays the assessment, and it has no owner recorded. A constraint nobody owns is one nobody can relax, which is worth knowing before it blocks the first Systems design.

The two kinds of date pull in different directions. The assessment argues for changing Systems' tenant as little as possible before award; the integration argues for changing all three tenants as soon as possible. The requirements register records that tension, and lesson 0.3 shows where the course takes it up.

Some of these dates are firmer than others, and a design should say which it depends on. A renewal date is in a signed agreement; an award "expected" in a quarter is a forecast. The decision block above is the habit that follows from that difference, and every lab's assumptions list applies it.

Translating priorities into scope is the first step of every architecture engagement, and it's where the architect and the board find out whether they read the plan the same way.

The board approved a three-year plan in September 2026 with four priorities, in this order. The plan says nothing about security. Every priority depends on it, and an architect's first job with a plan like this is to read what each priority puts in scope.

Reading a priority this way tells you what to look at; deciding comes later. "Run fewer tools" leaves the choice of products open and requires the design to account for every capability the group already pays for before proposing anything new. "Adopt Copilot" puts in scope the files each pilot user can already open, which Module 17 examines from Microsoft's documentation.

The order of the priorities is also information. Integration comes first and the US contract second, yet the contract has the nearer deadline. When the two collide, as they will over Systems' tenant, the board's order is the default answer and anything else needs the board's agreement.

Part of the architect's job is noticing when a design quietly reverses a priority and saying so, so that the board makes its own choice.

In practice the priorities become a line in every decision record: which priority each option serves and which it costs. A record that states the trade-off can be argued with, and one that cites the priority it serves will still make sense to whoever reads it in year three of the plan.

Defense customers are demanding in a particular way: they flow their own obligations down to suppliers as contract clauses, and they assess the supplier against them.

Two customers shape more of Northgate's security architecture than any regulator, because their requirements arrive as contract terms with revenue attached. Northgate Engineering sells hydraulic assemblies to a UK defense prime that flows its supplier security clauses down to Northgate.

The contract carries DEFCON 658, the MOD Cyber Security Model, which sets controls from Def Stan 05-138 Issue 4 according to the contract's Cyber Risk Profile. Assurance is a Supplier Assurance Questionnaire that Northgate completes itself each year. The contract adds three terms: incident notice within 24 hours, drawings kept to named staff, and security logs kept for 12 months.

The UK prime's model ties controls to a risk profile set for each contract, and asks the supplier to assess itself against them every year.

Two of its terms are case facts with direct design consequences: the 24-hour incident notice needs a detection and escalation path that works at any hour, and the 12-month log retention needs logs kept, for the right systems, for longer than many default settings keep them.

Northgate Systems is being evaluated by a US defense prime for a multi-year controls contract carrying DFARS 252.204-7012 and a CMMC Level 2 requirement.

DFARS requires cyber incidents to be reported to the DoD within 72 hours and images of affected systems kept for 90 days, and covered defense information held in cloud services must meet FedRAMP Moderate or equivalent. The assessment is Level 2 against NIST SP 800-171 Revision 2, and Phase 2 of the program begins on 10 November 2026.

The US requirements differ from the UK ones in kind. They name a published control framework, NIST SP 800-171, an assessment against it by a third party, and conditions on where covered defense information may be stored.

A Microsoft 365 tenant can meet them, but which tenant, with which services, holding which data, is a decision the group hasn't made. Lesson 0.5 sets out their sources; both customers turn security into a condition of revenue.

They also make assurance recurring: the UK prime's questionnaire comes back every year, and the US prime's assessment will be repeated. The business has already asked for that, in BR-09: customers' security questionnaires are answered from evidence, within five working days.

An architecture that can't produce its evidence on demand will meet that requirement only by heroic effort each time, which is why every design in this course names its evidence as well as its controls.

A risk appetite statement says how much risk the board will carry in pursuit of its plan. Northgate's board signed one in October 2026, a page long, after a session-theft incident in March. Its value to an architect is that it turns judgment into tests: a design that would cause one of the outcomes the board won't accept is out, whatever else it does well.

Its five areas fall into three kinds of test. Two protect the business's ability to keep working. Production may lose a site's office systems for up to 4 hours outside shifts, but the ERP and shop-floor systems may never stop unplanned during production hours; and people may accept some extra friction for administrators, but no control may stop engineers sharing drawings with approved partners.

Two protect against exposure. The board will lose a day's work on one team's files, but never a customer's controlled drawings or payroll data; and it will take minor audit findings with a dated fix, but never a finding that puts a defense contract or a regulator's notice at risk.

The fifth is money: spend within the year-one budget is accepted, and a second product bought for a capability the group already licenses is not. The tests in the first kind constrain how you change things, those in the second constrain what you protect, and the last constrains what you buy.

Read each line as an acceptance criterion. "Any unplanned stop of the ERP or shop-floor systems during production hours" means every change you propose needs a way to deploy outside shifts and a way back. "A second product bought for a capability the group already licenses" means every proposed purchase must first show that the current licenses can't do the job.

The course doesn't resolve that for you, and neither does the board. The engineering director quotes the second line and the CISO quotes the first. A design that satisfies both exists, but it takes precision about who approved partners are, what sharing means and how a drawing is recognized, which is why three modules take the question up from different directions.

Not every line is equally testable as written. "Up to 4 hours, outside shifts" is a measure you can plan a change window against. "Minor audit findings with a dated fix" needs a definition of minor before anyone can test against it.

When a tolerance is qualitative, the architect's job is to propose the measure and get its owner to agree it, so that the test is the board's and not yours.

Who may accept a risk is set too. Rachel Okafor accepts risks below board level; anything above goes to the board, with Elena Petrova consulted and the owner of the affected system informed. Every lab's review checklist includes the appetite tests, and a design that leaves a risk in place names who would have to accept it.

Money and licenses constrain a design in different ways. The budget limits what can be bought; the licenses already held define what can be built without buying anything.

The board gave security a budget for the first year, and the group already holds licenses that carry more capability than it uses. Both are constraints, and the register records them together. CON-01 sets the year-one security budget at $950,000 above current spend, of which no more than $600,000 may be new licensing.

CON-02 keeps Präzision on Business Premium until its agreement renews in February 2028. CON-03 allows no new IT or security headcount in 2027, which means every design has to be run by the people the group already has. The licenses come from each tenant's own export:

What each license contains is set by Microsoft, and it shapes every later decision. Microsoft 365 E5 includes Microsoft Entra ID P2, which Privileged Identity Management needs; Business Premium, E3 and F3 include Entra ID P1 but not P2.

Microsoft 365 E3, as Microsoft's service plan reference listed it when last updated in August 2026, includes Defender for Endpoint Plan 1 and Defender for Office 365 Plan 1. Northgate Systems pays for both through its E3 licenses and uses a third-party endpoint product instead, which is exactly the kind of overlap the board's fourth priority is aimed at.

Those facts don't decide anything yet. Whether Systems keeps its endpoint product, whether Präzision gets P2, and whether the group consolidates licensing are questions for Modules 7, 9 and 23.

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:

• 01-group-overview.docx: the companies, the board's plan and the risk appetite
• 03-requirements-register.xlsx: BR-02, BR-03, BR-09 and the constraints CON-01 to CON-05
• 06-inventories.xlsx: licenses held and assigned in each company
• 13-tenant-exports.zip: each tenant's subscribedSkus export, with the service plans inside each license