MSA0.7 Your Architecture Package

A configured tenant without documentation is a black box. A well-configured tenant without documentation is a fragile black box — one staff change, one audit, one incident, and nobody can explain why the controls exist, what they depend on, or what risk the organization accepted. The architecture package solves this by capturing everything a successor, auditor, or leader needs in one structured deliverable. This sub teaches you what the package contains, how each module feeds it, and what the assembled document enables that individual configurations cannot.

Estimated time: 20 minutes.

What a security architecture package is

A security architecture package is the complete documentation of an organization's security design decisions — the reasoning, the dependencies, the trade-offs, and the residual risks. It's the document that makes the difference between a tenant someone can maintain and a tenant someone has to reverse-engineer.

Microsoft's own Security Adoption Framework (SAF) positions the MCRA as a "starting template for a security architecture" — organizations use it to define a target state for cybersecurity capabilities. But the MCRA is a reference architecture, not your architecture. It shows what capabilities exist across the Microsoft stack. It doesn't show why your organization chose specific capabilities, what alternatives were rejected, what constraints shaped the design, or what risk was accepted. The architecture package fills that gap. It takes the MCRA's reference model and documents the specific decisions you made to implement it in your environment.

The Azure Well-Architected Framework describes the Architecture Decision Record as "one of the most important deliverables of a solution architect" and states that "your architecture is the accumulation of its decisions, so the ADR is effectively a record of how and why the system came to be its current shape." That principle applies directly to M365 security architecture. The tenant is the implementation. The package is the architecture. If you lose the package, the tenant becomes a collection of settings nobody can explain. If you lose the tenant, the package lets you rebuild it — every decision documented, every trade-off recorded, every exception explained.

The five components

1. Architecture Decision Records

The decision log — the core of the package. Every significant design choice gets a six-field ADR with evidence attachments, following the format you learned in MSA0.3. By course end, you'll have 30+ ADRs covering every layer of the M365 security stack.

What ADRs provide that the portal can't: the reasoning behind each configuration. A CA policy in the portal tells you that phishing-resistant MFA is required for the Finance persona group. The ADR tells you why passkeys were chosen over FIDO2 keys (procurement cost and timeline constraints), why the contractor population is excluded (unmanaged devices, remediation timeline in Q3 per ADR-MSA6-004), and what compensating controls apply during the gap period (session-proxied applications via Defender for Cloud Apps). Without the ADR, a successor looking at the CA policy sees a configuration. With it, they see a decision they can evaluate, maintain, and update when constraints change.

2. Decision matrices

Trade-off tables for design decisions with multiple viable options. When you choose an authentication method in MSA2, you evaluate six methods against five criteria. The decision matrix captures the full evaluation — not just the winner, but why every other option scored the way it did. This matters because constraints change. When the procurement budget is approved next quarter, the FIDO2 row in the matrix shows exactly how its score changes — and whether it should replace passkeys for specific persona groups.

The course produces approximately seven decision matrices: authentication method selection (MSA2), CA policy persona model (MSA3), data classification taxonomy (MSA5), DLP scope and channel coverage (MSA5), endpoint compliance configuration by platform (MSA6), Sentinel data tier assignment (MSA8), and detection rule prioritization by threat pattern (MSA9).

3. Risk register

The honesty document. Every control you don't implement, every exception you grant, every E3 limitation you can't work around gets an entry. Each entry captures: the gap (what's missing), the threat it leaves unaddressed (linked to the attack patterns from MSA0.4), the compensating control (what mitigates the gap today), the remediation timeline (when the gap will be closed), and the cross-reference to the ADR that documents the acceptance.

The risk register serves two audiences. The auditor uses it to confirm that gaps are acknowledged, compensated, and tracked — not hidden. The CISO uses it as the roadmap input for budget requests — gaps without timelines are permanent gaps, gaps with timelines and cost estimates are the prioritized improvement list that gets funded.

By course end, the register contains approximately 25 entries — each linked to a specific ADR, a specific threat pattern, and a specific remediation module.

4. Architecture diagrams

The visual layer. Each module produces at least one diagram — identity topology (MSA1), authentication flow (MSA2), CA policy evaluation chain (MSA3), privilege model (MSA4), data classification taxonomy (MSA5), endpoint trust chain (MSA6), email protection layers (MSA7), Sentinel workspace topology (MSA8), detection coverage map (MSA9), incident response flow (MSA10), XDR correlation architecture (MSA11), governance lifecycle (MSA12), and the complete capstone architecture (MSA14).

These aren't decorative summaries. They're the diagrams you present to different audiences. the CISO walks the board through the CA evaluation chain to explain how access decisions are made. the GRC analyst includes the data classification taxonomy in the ISO 27001 evidence pack. the security architect references the Sentinel workspace topology when onboarding new SOC analysts or when the managed SOC provider asks about data connector coverage.

5. Executive summary

The one-page document for the board. It translates the entire architecture into business language: what's protected, what's not yet protected, what the roadmap looks like, and what investment is needed to close the remaining gaps. You draft it in MSA13.5 using the risk register and ADR summaries, and finalise it in MSA14.4 after the architecture review.

The executive summary draws from all four other components. ADRs provide the decisions. Matrices provide the evaluation evidence. The risk register provides the gap analysis. Diagrams provide the visual anchors. The summary synthesises them into a document a non-technical board member reads in five minutes and understands the organization's security posture, the accepted risks, and the investment case.

How modules feed the package

Every module contributes specific components. Use this as a checklist — each module's artifact footer confirms which deliverables you've produced.

Module   ADRs   Matrices  Risk entries  Diagrams
------   ----   --------  ------------  --------
MSA0     0      0         0             0         (baseline + structure only)
MSA1     3–4    0         2–3           1
MSA2     3–4    1         2–3           1
MSA3     4–5    1         2–3           1
MSA4     3–4    0         2–3           1
MSA5     3–4    2         2–3           1
MSA6     3–4    1         2–3           1
MSA7     2–3    0         1–2           1
MSA8     3–4    1         2–3           1
MSA9     2–3    1         1–2           1
MSA10    2–3    0         1–2           1
MSA11    2–3    0         1–2           1
MSA12    2–3    0         1–2           1
MSA13    1–2    0         0             0         (+ exec summary draft)
MSA14    0      0         0             1         (+ final assembly)
------   ----   --------  ------------  --------
Total    ~35    ~7        ~25           ~14       + 1 executive summary

The package is the deliverable

This point reverses the assumption most security training makes. Most courses end with "your tenant is now configured." This course ends with "your architecture package is complete."

The tenant configuration is a byproduct of the architecture. If you lose the tenant — subscription expires, migration happens, disaster recovery rebuilds — the package lets you rebuild every configuration from the documented decisions. If the tenant survives but the package doesn't exist, you have a configured environment that nobody can maintain, explain, or confidently modify. One person leaves, and the next person starts guessing.

When you reach MSA14, you present the package as a coherent architecture. the CISO asks hard questions about trade-offs. the GRC analyst asks for ISO 27001 Annex A mapping. the IT Director asks about user impact. The auditor asks for evidence. The package answers all of them.

Create the folder structure

Set this up now. Every module's output goes into the corresponding folder.

NE-Architecture-Package/
├── 00-baseline/
│   ├── gap-assessment.md               ← from MSA0.5
│   └── threat-to-architecture-map.md   ← from MSA0.4
├── 01-identity/
│   ├── adrs/
│   ├── diagrams/
│   └── risk-entries/
├── 02-authentication/
│   ├── adrs/
│   ├── decision-matrices/
│   └── risk-entries/
├── 03-conditional-access/
├── 04-privileged-access/
├── 05-data-protection/
├── 06-endpoint-security/
├── 07-email-collaboration/
├── 08-sentinel-workspace/
├── 09-detection/
├── 10-incident-response/
├── 11-xdr-operations/
├── 12-governance/
├── 13-posture-compliance/
├── 14-capstone/
├── risk-register/
│   └── ne-risk-register.md             ← cumulative, updated each module
├── executive-summary/
│   └── ne-executive-summary.md         ← drafted MSA13, finalised MSA14
└── templates/
    ├── adr-template.md                 ← from MSA0.3
    ├── decision-matrix-template.md
    └── risk-entry-template.md

Start with 00-baseline/. Copy the gap assessment from MSA0.5 and the threat-to-architecture map from MSA0.4 into it. Copy the ADR template from MSA0.3 into templates/. That's three documents. Everything from MSA1 onward adds to this structure.

Before moving on, verify your understanding: Name the five components of the architecture package and explain in one sentence what each provides that the tenant configuration alone cannot. Explain why the architecture package — not the tenant configuration — is the primary deliverable. Give a specific scenario where the package is essential and the tenant alone is insufficient.

Reusable script — the commands from this sub assembled for operational use:

Your package has three documents in it already. Confirm each is in place before starting MSA1:

1. Gap assessment (00-baseline/gap-assessment.md) — NE's eight security gaps from MSA0.5, each mapped to a course module and a threat pattern.

2. Threat-to-architecture map (00-baseline/threat-to-architecture-map.md) — The four prevalent attack patterns from MSA0.4, each linked to architectural controls and the queries that test whether each control is active.

3. ADR template (templates/adr-template.md) — The six-field template with evidence slots from MSA0.3.

If you're applying this course to your own environment in parallel, create a second package folder with the same structure. Run the diagnostic queries from MSA0.1–0.4 against your own tenant and populate the baseline with your own gap assessment and threat map.