Design Zero Trust architecture and incident response plan — Governance, Compliance & Career Readiness

This exercise produces the capstone's second deliverable: the architecture and response plan that address the risks named in your Module 6 risk register. Extending the architecture principles from Module 3, you will design a Zero Trust access model appropriate for this startup's actual workforce and technology stack, and pair it with an incident response plan sized realistically for a lean team without a dedicated security operations center.

Analogy🏏Cricket

💼 Think of it like business: GRC frameworks are the shared accounting standards of security. A company that reports earnings under a recognized standard lets investors, lenders, and regulators all read the same numbers the same way, instead of trusting a founder's hand-drawn chart. Adopting ISO 27001, SOC 2, or NIST CSF does the same for security posture, giving auditors, customers, and regulators one common language to judge maturity rather than each party inventing its own yardstick. This reveals that frameworks really sell trust: their product is a claim outsiders can verify without taking your word for it.

Designing the Zero Trust Access Model

Specify identity verification, device posture requirements, and clear segmentation between production and internal systems throughout the entire company environment, network, and cloud infrastructure, directly addressing R1 and R2 from your risk register by requiring individual, MFA-enforced accounts for every engineer with cloud console access.

Analogy🏏Cricket

💼 Think of it like business: when a company tightens who can sign off on spending, it doesn't just trust job titles — it verifies identity, checks the device the approval came from, and separates the people who touch production budgets from those who only see internal reports. Specifying the Zero Trust model works the same way, requiring identity verification, device posture, and clean segmentation, and directly closing R1 and R2 by giving every engineer an individual, MFA-enforced account for cloud console access. Access becomes a controlled process, not a standing assumption. This reveals why verified, segmented access is the operational spine that the rest of the design hangs on.

Because this company has no dedicated identity team, favor a managed identity provider over a custom-built solution, since the operational burden of maintaining custom authentication infrastructure would itself become a new risk this lean team cannot realistically support.

Analogy🏏Cricket

⚽ Think of it like sports: a small club without a full medical department doesn't build its own sports-science lab from scratch — it partners with an established provider, because running a half-staffed lab badly is more dangerous than outsourcing it well. Choosing a managed identity provider over a custom-built one follows the same logic: with no dedicated identity team, the operational burden of maintaining bespoke authentication would itself become a fresh risk this lean squad cannot cover. The managed option isn't the flashiest, but it is the one that actually stays maintained. This reveals why a managed provider beats a custom build for a team without the bench to support it.

Building an Incident Response Plan for a Lean Team

Pair this with an incident response plan covering detection, containment, eradication, recovery, and post-incident review, assigning clear roles and escalation paths appropriate for a lean team without a dedicated twenty-four-hour security operations center, since the plan must remain realistic for the company's actual resourcing, headcount, and available security budget overall.

Analogy🏏Cricket

🎮 Think of it like gaming: a well-drilled raid group agrees the wipe-recovery plan before the boss is ever pulled — who calls the retreat, who resurrects, who resets the encounter — so a sudden disaster runs on rehearsed steps instead of panic in voice chat. An incident response plan covering detection, containment, eradication, recovery, and post-incident review does exactly that, laying out roles and escalation for a lean team that has no twenty-four-hour operations center to fall back on. The plan is the strategy you agree while calm, not mid-wipe. This reveals why a staged, role-clear response plan keeps a small team functional when the fight goes wrong.

Name specific individuals by role — the on-call engineer, the founder as final decision-maker on customer communication — rather than leaving escalation vague, since a vague plan discovered mid-incident is functionally no plan at all.

Analogy🏏Cricket

🎵 Think of it like music: in a live band, everyone knows in advance who counts in the song, who takes the solo, and who signals the ending — leave those roles unassigned and the moment the tempo wobbles the whole piece collapses into guesswork on stage. Naming specific individuals in the response plan works the same way: the on-call engineer, the founder as final decision-maker on customer communication, each part assigned before the pressure ever hits. A cue figured out mid-song is a cue already missed. This reveals why a plan with named roles, not vague escalation, is what actually holds together the instant an incident begins.

Connecting Architecture Back to Risk

Your submission should explicitly connect architectural decisions back to specific risks identified in your Module 6 risk register, demonstrating that the design addresses real, prioritized threats rather than implementing controls purely for their own sake, for appearances, or simply to satisfy an auditor's checklist without any genuine underlying security benefit. If a proposed control does not map to a named risk in your register, that is a signal to either add the missing risk or reconsider whether the control actually belongs in this specific roadmap.

Analogy🏏Cricket

📷 Think of it like photography: every element a careful photographer leaves in the frame should serve the subject — if something sits in the shot for no reason, they either recompose to give it purpose or crop it out entirely. Connecting each architectural decision back to a named risk enforces the same discipline: a control that maps to a real, prioritized threat earns its place, while one that traces to nothing is a signal to either add the missing risk or cut the control. Nothing rides along in the composition unexamined. This reveals why every control, like every element in the frame, must justify itself against a named risk in the register.

The Zero Trust design should directly address specific named risks from the Module 6 risk register, especially R1 and R2.
A managed identity provider is preferable to a custom-built solution for a lean team without a dedicated identity function.
The incident response plan must name specific roles and individuals, not leave escalation paths vague or generic.
Plan sizing must remain realistic for the company's actual headcount and budget, not assume a full security operations center.
Every architectural decision should trace back to a specific, named risk rather than existing purely for appearances.