0.3 Northgate Group: Stakeholders and Requirements

Introduction

Requirements are what a design is measured against, and they come from people. Every requirement in a register started as something a person wanted, feared or was obliged to do, and the people behind them don't agree with each other.

An architect who reads the register without knowing its authors misses why each line is there, which lines will be defended to the end, and which were written to settle an argument that's still going on.

Northgate's register holds 50 requirements written by the group's own people: 12 business, 20 security, 10 non-functional and 8 constraints. Twelve stakeholders stand behind them, from the CEO to the works council at Präzision, and their interview notes are in the evidence pack.

The figure is the order you'll work in throughout the course: the people first, then the register read with them in mind, then its conflicts and gaps, then who decides.

Missing a stakeholder is the most expensive mistake here, because the person you didn't consult appears when the design is nearly finished, with an objection that could have shaped it from the start.

A stakeholder is anyone who can approve, block, fund, run or be harmed by a design. Stakeholder analysis records, for each of them, four things that decide how they'll respond to what you propose: what they want, which is the outcome they'll judge your design by whatever it says about security.

What they fear, which is the objection you'll meet first. What they can approve, which tells you whether your design needs their signature. And what they push back on, which tells you which change is most likely to stall.

The four lenses do different jobs. Wants and fears explain behavior: Northgate's finance director wants one licensing bill and fears paying twice, so he'll read any proposal for whether it buys a capability the group already has. Approval rights are a matter of fact: they tell you whose signature a design needs. Pushback tells you where to put your effort before the meeting, while the design can still change.

Two traps catch new architects. The first is mistaking seniority for authority. The CEO can approve the roadmap and anything over the finance director's limit, but he doesn't approve identity designs; the CISO does. The second is treating objections as obstacles.

Katrin Hoffmann's objection to monitoring her staff rests on German law and her works council's rights, and a design that ignores it will be stopped legally, not just politically. Objections are often requirements nobody wrote down.

Getting the four lenses right depends on how you ask. "What would have to be true for this to work for your team?" gets a want, where "should we use labels?" gets an opinion about a product. Asking what would make them reject a proposal surfaces the fear and the pushback in one answer. Write down their own words, because a paraphrase drifts toward what you wanted to hear.

Record the four lenses before you design, and revisit them when a design changes, because a stakeholder who supported one version can oppose the next.

Reading a stakeholder list is mostly reading what each person can actually sign, which is narrower than their job title suggests. Groups formed by acquisition are especially uneven, because each company brought its own lines of authority with it.

Northgate's stakeholders span the three companies, the group's central functions and two outside parties: the SOC provider and Präzision's works council. Their approval rights fall into three groups, and each group objects to a different kind of design.

Money and direction sit with Graham Holt, the new Group CEO, who approves the roadmap and anything over the finance director's limit, and David Thompson, finance director and acting CFO, who approves spend within budget; both will ask what a design costs and when it shows a result, and Thompson resists any new product before the current licenses are used.

Rules sit with Elena Petrova, the GRC lead, who approves policies and the control register and pushes back on any control that produces no evidence.

How the work gets done sits with Owen Pryce, who approves engineering tooling and resists labeling or DLP that blocks a partner, and with Jonas Weber, who approves day-to-day changes in Präzision's tenant and will resist a migration that leaves him no say. A design meets the first group on cost, the second on evidence and the third on the working day.

Approval is narrower than job titles suggest. Rachel Okafor approves the architecture and every risk acceptance below board level, which makes her the accountable owner for most of what you'll design.

Phil Greaves approves changes to production systems, which gives him a practical veto over anything that touches them. Katrin Hoffmann and Dana Whitfield each approve changes in their own company, so neither the CISO nor the CEO can quietly reconfigure Präzision's or Systems' tenant over their heads.

Two stakeholders approve nothing at Northgate and still matter. Marcus Webb advises; his designs and unsigned decisions are the starting point for several modules. Sam Adeyemi runs the SOC contract; his team will operate whatever monitoring you design, and his contract covers only Northgate Engineering. A design that depends on Watchpoint monitoring Präzision is a design that depends on a change order.

Others in the case, such as the two L1 analysts and the remaining directors, appear as users whose access and data your designs cover; their needs reach you through the stakeholders above.

The works council is the one stakeholder that is a body, not a person. Under German law it has co-determination over technical systems designed to monitor employees, which turns its position into a constraint on Präzision's design, and the register records it as CON-06.

Writing a RACI down early stops the argument about who decides from happening during the decision itself.

A RACI chart says, for each kind of decision, who is Responsible for proposing it, who is Accountable for it, who must be Consulted before it's made and who is Informed afterward. In this course you're Responsible for proposing every architecture decision; the chart tells you everyone else's part.

The figure shows how concentrated accountability is. Five of the seven decision types end with Rachel Okafor, devices end with Phil Greaves, and licensing and spend end with David Thompson. That concentration is normal for a security architecture and has a consequence: Rachel Okafor's agreement is necessary for most designs and sufficient for few, because the people she must consult can still stop a design in practice.

The informed column is short: Graham Holt hears about tenancy, monitoring and licensing decisions, the three managing directors about identity and access, the sites about device decisions, and customers' contacts about data protection. The consulted column is where designs are won or lost. Tenancy decisions consult Präzision's and Systems' leaders and Marcus Webb, so a tenant design proposed without them will come back.

Monitoring decisions consult the works council for Präzision, which is the only place in the chart where an outside body has to be heard before a design is made. Read the chart before every lab, and name in your deliverable who you consulted and what they said.

Two faults are common in RACI charts and worth checking for whenever you inherit one. The first is two accountable owners for one decision, which means nobody is, because each can wait for the other.

The second is confusing the accountable owner with the person who does the work. Phil Greaves's team will implement most of what Rachel Okafor approves, which makes them responsible for building it, not accountable for the decision.

Classifying requirements is more than tidiness. Each kind is tested differently, owned by different people and given way to in a conflict for different reasons, so a requirement filed under the wrong kind tends to be handled wrongly.

Northgate's register uses four kinds, with an ID prefix for each, and every entry names its source, so you can read it against where it came from.

Business requirements state what the business needs in its own words, and a design must enable them. BR-04, engineers sharing controlled drawings with approved partners and customers without IT raising a ticket each time, comes from Owen Pryce's interview. It is a business requirement even though it has large security consequences, because it's about how the business works.

Security requirements state outcomes, and never products. SR-01 says a stolen password alone doesn't give access to any group system, and its source is the session-theft incident, I-1. It doesn't say "deploy multifactor authentication", because several controls could meet it and choosing among them is the design.

Non-functional requirements set the qualities a design must have: availability, recovery, operability and usability. NFR-05 says a user is asked for additional authentication no more than once a working day on a managed device in normal use, from Owen Pryce and a staff survey, and every access design must respect it.

Constraints are limits the design lives within and can't change: budgets, contracts, technical dependencies and legal positions. CON-04 says the CAD license server at Birmingham Works needs NTLM and can't be replaced before 2028, on the evidence of a vendor letter. A design can contain that dependency, isolate it or plan for its end, but it can't wish it away.

The kinds blur at the edges, and classifying a requirement correctly is part of reading it. "Contractors use their own phones on the shop floor" is business, because it describes how the business wants to work, even though it collides with a security requirement.

"The CAD license server needs NTLM" is a constraint, because nobody wants it; it's simply true until 2028. When a requirement seems to belong to two kinds, it's usually two requirements written as one, and splitting it makes both easier to test.

Of all the properties a requirement can have, testability is the one that decides whether it's useful at all.

A requirement is useful when someone can test a design against it and get a clear answer. That takes four properties: it states an outcome, it is measurable, it has an owner, and it names its source. Most real registers are uneven on all four, and Northgate's is no exception. Try the test yourself on four of its entries before reading on.

NFR-05 is what good looks like: a count, a period and a condition, so any access design either meets it or doesn't. The others show the common faults.

BR-07, "Staff at every company can work from home and customer sites on company devices", is a fair business wish with no measure, so two designers could both claim to meet it with very different results: which systems, from which places, with what experience?

SR-06 depends on a stated minimum for devices that isn't stated anywhere, which means it can't fail a test until someone writes it. SR-13, containment of a compromised account within 15 minutes at any hour, is measurable but leaves the key term open: contained means what, and who is awake to do it? The tabletop exercise in October, F-8, shows why that matters.

Measurability takes a few common forms, and naming the form helps you write the test. A threshold sets a number not to cross: no more than one prompt a day.

A binary states something that is either true or not: no permanent privileged role. A time bound sets a deadline for an event: containment within 15 minutes. A requirement that fits none of the three usually hasn't decided what it wants yet.

Ownership and source matter as much as wording. Every requirement in Northgate's register names a source, so you can go back to the incident, the interview or the obligation it came from and check whether it says what the source needed. The constraints don't name owners, which lesson 0.2 showed matters for CON-05.

Module 2's lab sharpens requirements like these. The habit to start now is to ask, before designing against a requirement, how you'd know you had met it.

Recording conflicts is a sign of a mature register, because the alternative is that each designer discovers them alone and settles them quietly.

Requirements conflict when meeting one fully makes another harder or impossible to meet. A recorded conflict is useful information about the register: it marks where a design will need judgment, and who will need to agree. Northgate has recorded the conflicts it knows about.

The figure shows where the pressure sits. BR-04 against SR-07 and SR-08 is the drawings question again, from lesson 0.2's risk appetite. SR-12, one SOC view across all three companies, pulls against both the SOC contract and the works council. The licensing ceiling, CON-01, pulls against three security requirements at once. Each line in the figure is labeled with the modules where that conflict is taken up.

Take an example from outside the case: a requirement that every laptop's disk is encrypted seems to conflict with one that IT can recover any laptop without its user, until escrowing each recovery key under control meets both. Most conflicts look harder than that one, and some are, but the first question is always the same: is there a design in which both requirements hold?

A conflict is resolved in one of three ways, and a design should say which. It is dissolved when a design is found that meets both requirements, which is the best outcome and usually takes precision. It is traded when one requirement gives way partly or for a period, with the owner of each agreeing.

It is escalated when the trade is beyond the accountable owner's authority, which, by the RACI, means the board. Each lab whose inject touches a conflict asks you to state which of the three your design does.

Interview notes are evidence of what people believe and want, and they're unreviewed: Marcus Webb typed them up the same day and the people quoted haven't checked them. That makes them valuable and unreliable at once. They tell you where the arguments are; they don't tell you who is right.

The most useful thing in a set of interviews is where they contradict each other, or contradict the documents, and Northgate's notes hold three that matter early.

The first is about tenancy. Phil Greaves says: "The simplest answer for Präzision is to bring them into our tenant. One directory, one set of policies. Jonas is good but he's one person." Katrin Hoffmann, about the same tenant, says: "I don't want to lose our tenant.

Jonas built what we have and it works. If something must move, tell me why, and tell me what my people will see on their screens, in German."

The second is about Systems. Dana Whitfield says: "Our MSP built us twelve Conditional Access policies. I'm told that covers what the assessment asks for. Don't change our tenant in any way that puts the assessment date at risk." Rachel Okafor sees the same tenant differently: "Präzision and Systems are the weak links.

Präzision has a former provider who still has Global Administrator. Systems has an MSP with the same. If either is compromised, the attacker is one guest invitation away from us."

The third is between a person and a document. Owen Pryce says: "My engineers share drawings with partners and customers every day. It's how we win work. Anonymous links work every time; the alternatives fail half the time because the partner's IT blocks something." Section 4 of the draft data classification policy says: "Restricted information must not be shared outside the group without the approval of Information Security."

None of these contradictions is resolved by deciding who is more senior. The first is a real design question about tenancy, which Module 4 asks you to answer with evidence from both companies.

The second is a claim about whether twelve MSP-built policies meet a defense customer's assessment, which the Systems tenant export and the customer's questionnaire let you test. The third is between an engineering director and a draft policy he refused to sign, which tells you the policy hasn't failed on its merits so much as on its consultation.

Read every interview note for three things: claims you can check against an export or a document, objections that may be unwritten requirements, and contradictions with someone else. Record each with the person's name and the file it came from, the habit from lesson 0.1.

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:

• 02-stakeholder-interviews.docx: each stakeholder's profile and interview notes, in their own words
• 03-requirements-register.xlsx: the requirements, their sources and owners, the conflicts and the RACI
• 10-policy-extracts.docx: the draft data classification policy quoted in the interview section