0.1 The Architect's Role and the Course Method

Introduction

A security architect decides how an organization's controls fit together and records why, before anyone configures them. An engineer builds a control; an administrator runs it; an analyst watches what it reports. The architect is the person who can say which threat each control answers, which requirement it meets, what it costs, what it depends on, and what the organization accepted by not choosing the alternative.

In Microsoft 365 that work spans identity, devices, mail, collaboration, data, operations and recovery, across one tenant or several, and it ends in documents other people approve, build from and are audited against.

This course teaches that work on one organization, Northgate Group: three engineering and manufacturing companies in the UK, Germany and the US, joined by two acquisitions in 2026 and still running three Microsoft 365 tenants three different ways.

You join as its first Group Security Architect. Every module teaches a part of Microsoft 365 security architecture on its own terms, then hands you a requirement or an event at Northgate and asks for your design.

The loop in the figure is the course. Each module opens with an inject, teaches what you need to answer it, and closes with a lab that produces one deliverable. The deliverables accumulate into a portfolio, and the final modules assemble it into one group architecture and ask you to defend it.

Most Microsoft 365 tenants are configured one feature at a time. A policy is created because a project needed it, an exclusion is added because something broke, and a license is bought because a renewal offered it. Each change was reasonable on the day.

Taken together they're a configuration nobody designed, and the first person to ask "why is it like this?" gets no answer, because nobody ever wrote one down.

Architecture is the discipline that prevents that. It works at a level above configuration: which trust boundaries exist and why, which identities may cross them, which devices are trusted to hold which data, where evidence is kept and for how long, and which risks are accepted by whom. Configuration then implements those decisions, and anyone can check the implementation against them.

The architect's output is therefore a set of decisions with their reasons, in forms other people use:

• A requirements register, so every decision answers something the business or a regulator asked for.
• Decision records for each significant choice: the options considered, the one chosen, and its consequences.
• Diagrams that show trust boundaries, data flows and access paths, which prose describes badly.
• Designs precise enough to build from, and a roadmap that orders the work within a budget.

Those documents have different readers, and each reader needs something different from the same decision. A CISO reads for the risk accepted and who accepted it. An IT director reads for what his team has to build and run, and whether it fits the people he has.

A finance director reads for what it costs and whether anything is bought twice. An assessor reads for the evidence that the control exists and works. A decision written for only one of them gets stuck with the others, which is why the course asks you to write each deliverable for the person who will act on it.

Architecture also decides what not to build. Every design leaves some risks in place because removing them costs more than they're worth, or because a requirement pulls the other way. Those are accepted risks, and an accepted risk with a named owner and a review date is a decision. The same risk left in place because nobody noticed it is an exposure.

The role sits between the CISO, who owns the group's security risk, and the IT teams in each company, who build and run what is decided.

You join Northgate Group as Group Security Architect, a post created in October 2026 and reporting to Rachel Okafor, the group's CISO. The post exists because the group stopped being one company in 2026, and the security work that served one UK tenant doesn't stretch to three companies in three jurisdictions.

The post's terms fit in a few lines. You report to Rachel Okafor, CISO for the group. You work across all three companies, Northgate Engineering, Northgate Präzision and Northgate Systems.

You propose every architecture decision the course asks for, and you approve none on your own. Each kind of decision has an accountable owner, from Rachel Okafor for identity and access to David Thompson for licensing and spend, and lesson 0.3 sets out who that is for each.

A design that its owner can't sign is unfinished, so part of every lab is knowing whose agreement the design needs and what they will push back on.

The other line is the inheritance. Marcus Webb was Northgate Engineering's security architect until this month. He now runs the integration program for Präzision and hands you what he leaves: half a target identity design written before Northgate bought its US company, three decisions he wrote up that nobody signed, and a folder of notes that are honest about what he didn't finish.

He stays reachable and he can advise, but he can no longer approve anything. Treat his work as you'd treat any predecessor's: read it before you change it, keep what holds, and record why you change what doesn't.

Proposing a decision has a mechanical side that the labs follow. You write the decision record with the options you considered and the one you recommend, and you send it to the accountable owner with the people they must consult.

The owner signs it, sends it back with a question, or rejects it with a reason. Each outcome is recorded, because a decision whose approval nobody can show is, to an auditor, a decision nobody made. Marcus Webb's three unsigned records are what happens when that step stalls: correct analysis, no authority behind it, and nothing changed in the tenant.

Real architecture work arrives as a request or an incident, rarely as a blank page. The CISO wants a view of the estate; a customer sends a questionnaire; an audit finds a problem; something goes wrong at night. Each module of this course opens the same way, with an inject: a requirement or an event at Northgate that its lab asks you to answer.

The injects follow the blueprint's six phases, and their order is deliberate. Identity comes before access because an access policy is written against identities; access before data, because a label that encrypts a drawing is only as strong as the sign-in that opens it; operations late, because monitoring is designed for an architecture that already exists.

A design you make in Module 5 is an input to Modules 6, 7 and 22.

The first four open Phase 1. Module 1's inject is the CISO asking her new architect for a first view of the group: its trust boundaries, its components and three major risks. Module 2's is the board approving the Präzision integration program, which the architect turns into requirements and a first decision record.

In Module 3 the US customer's questionnaire asks for the group's Zero Trust target state and roadmap, and in Module 4 the question is one tenant or several for three companies, with the MSP still running Präzision's.

None of them is a request for a configuration. Each asks for a judgment the configuration will later implement: what the estate is, what it must achieve, what target it moves toward, and how the companies' tenants should relate. That's the order an engagement runs in, and skipping to configuration is how the estates you'll meet in this course came to be.

That makes the work cumulative in a way an exam question isn't. When Module 6 asks for a Conditional Access design, it must work with the identity design you made in Module 5, and when Module 22 asks for one group high-level design, it must hold every earlier decision together.

If an earlier decision turns out to be wrong, you change it and record why, which is what architects do with real estates.

Every inject is drawn from the case: an incident that happened, a finding someone reported, a requirement someone wrote, or a decision the board took. The case is set out across lessons 0.2 to 0.5, and lesson 0.5 sets out the incidents, findings and obligations most of them draw on.

A deliverable is the unit in which an architect's work leaves the architect's hands, so its shape matters as much as its content.

Each lab produces one deliverable, of the kind an architect hands over in practice: a working document an IT director could build from, a CISO could sign, or an assessor could test.

Module 1 produces a Security Architecture Overview, Module 2 a Requirements and Decision Pack, Module 3 a Zero Trust Target Architecture and Roadmap, and Module 4 a Tenant Architecture and Governance Design. Modules 5 to 21 each produce one design, from identity to recovery.

Each deliverable is provided as a formatted worked example in Word, Excel, draw.io or PowerPoint, with its structure in place and an example filled in from a part of the estate the lab doesn't ask you to design.

You replace the example with your own work. The examples show the standard expected without answering the lab, which the course keeps strictly: no lesson or worked example designs the thing its own lab asks for.

The portfolio is the sum of the deliverables. By Module 21 it holds a design for every layer of the group's Microsoft 365 estate. Module 22 asks you to assemble them into the Enterprise Security HLD and find where they disagree, Module 23 prices it against the CFO's ceiling in a Security Investment Analysis and 12-Month Roadmap, and Module 24 puts the portfolio in front of a design authority review.

Whatever the format, a deliverable worth keeping has the same properties. It carries a date and a version, because it will change. It leads with the decisions and puts the analysis behind them, because its readers act on decisions. It names an owner for every open item. And it states its assumptions, so the person who reads it in a year can tell which ones have since stopped holding.

Requirement IDs are how a reader finds their way around a deliverable without reading all of it.

A design is only as defensible as its links to what was asked. Northgate's requirements each carry an ID. BR- marks the 12 business requirements, written in the business's own words. SR- marks the 20 security requirements, stated as outcomes, never as products. NFR- marks the 10 non-functional requirements for availability, recovery, operability and usability, and CON- the 8 constraints the design must live within, such as budget and contracts.

Every lab names the IDs its deliverable must trace to, and every deliverable template carries columns for them.

The chain in the figure is what an assessor walks, in either direction. Forward, from a requirement: which risk does it guard, which decision answers it, which control implements the decision, and what evidence shows the control works?

Backward, from a control found in the tenant: which decision put it there, and which requirement does it serve? A control with no decision behind it is configuration nobody designed. A requirement with no control is a gap, and a control with no evidence can't yet be shown to work.

Take SR-03 as an example of a trace in the forward direction: no account holds a privileged role permanently except named emergency accounts. Its source is the internal audit's finding F-2. The risk it guards is the compromise of an account that holds standing control of a tenant.

Module 7 asks for the decision that answers it. The evidence that the answer worked would be the role assignment export: every Global Administrator assignment either time-bound or held by a named emergency account. Each link in that chain is a fact someone can check, which is what makes the design defensible.

Traceability also tells you when a requirement is wrong. If a requirement can't be traced to any risk, obligation or business need, it may not belong in the register; if a risk the board cares about has no requirement, the register is incomplete. Northgate's register has both kinds of fault, and finding them is part of the work.

You'll write the trace as you design, never at the end. A trace reconstructed after the fact tends to find that every decision was justified, because it is written by the person who already believes they were.

The course separates two kinds of activity, and they happen in different places.

Design work happens in the lesson and in your own files: requirements, threat models, diagrams, decision records, policy matrices and roadmaps. Everything you need for it is in the course, and every learner can complete all of it.

Implementation and validation activities happen in a Microsoft 365 tenant you control: a trial or developer tenant, or one you manage with approval to change it. They exist so you can see a setting do what a design claims, and they are written for any tenant. Northgate is never the place you act in; it's fiction, and its tenants exist only as the exports in the evidence pack.

Every implementation activity in the course is written so that you can judge its risk before you start. Three of its parts are about what the step touches: the least role that can do it, so you never practice with Global Administrator out of habit, the license the feature needs, and any cost beyond the license, such as storage or a trial that converts.

The other two are about getting out again and knowing what happened: the rollback with a way to confirm it worked, and the expected result, which also lets a learner without a tenant check their reasoning.

A typical module uses both. Module 6, for example, asks you to design Northgate's Conditional Access policies as a matrix of who, what, from where and under which conditions: design work, on the page. It then asks you to create one policy in your own tenant in report-only mode and read how a sign-in was evaluated against it: implementation work, which shows you whether the matrix says what you meant.

The design stands without the implementation. The implementation is how you find out whether you understood the setting. In a tenant you manage for an employer, run only the steps that read, unless you have approval for the change and a way to undo it.

If you don't have a tenant, you still complete each activity: read the steps, then check your reasoning against the stated expected result. You lose the experience of seeing the portal respond; you lose nothing the design work depends on. Lab Setup, in the course's resources, walks through building a tenant suitable for the course, with what each part costs.

The case comes with evidence, the way an engagement does: documents written by Northgate's people for their own purposes, exports taken from its tenants, and registers kept by teams who disagree. It's published as the evidence pack, 13 files that the course reads from start to finish, and lesson 0.5 goes through each.

The tenant exports are what Microsoft Graph returns, saved as JSON. This is the start of Northgate Systems' organization object, as Get-MgOrganization or a request to /organization returns it:

{
  "id": "b25c2d21-8e3a-47f3-a06c-7f9de6bc79f8",
  "displayName": "Northgate Systems Inc.",
  "countryLetterCode": "US",
  "createdDateTime": "2018-05-22T14:00:00Z",
  "onPremisesSyncEnabled": true,
  "verifiedDomains": [
    {
      "capabilities": "Email, OfficeCommunicationsOnlineService",
      "isDefault": true,
      "isInitial": false,
      "name": "ngsystems.example",
      "type": "Managed"
    },
    {
      "capabilities": "Email, OfficeCommunicationsOnlineService",
      "isDefault": false,
      "isInitial": true,
      "name": "ngsystems.onmicrosoft.com",
      "type": "Managed"
    }
  ]
}

Read it the way you'll read every file in the pack. The values are facts about the tenant on the day of the export, so the date matters: this export was taken on 1 October 2026, while Northgate's and Präzision's were taken in March and haven't been retaken. onPremisesSyncEnabled is true because Systems synchronizes identities from its own Active Directory; verifiedDomains lists the domains its mail and sign-ins use.

Nothing in the object says whether that's a good arrangement. That judgment is yours, and it starts in Module 1.

Three habits make the evidence trustworthy in your hands. Cite the file and the row or ID for every fact you use. Note the date of every export, since a configuration can change the day after it's read. Treat the documents' authors as sources with interests: a stakeholder's interview note is what they believe, which isn't always what the tenant shows.

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 board's priorities, the risk appetite and the role you join
• 03-requirements-register.xlsx: the requirement IDs every deliverable traces to
• 12-marcus-webb-handover-notes.docx: what your predecessor leaves, and why
• 13-tenant-exports.zip: the tenant exports, including Northgate Systems' organization object