Build governance docs, risk register and compliance roadmap — Governance, Compliance & Career Readiness

This exercise produces the first of the capstone's four connected deliverables: the governance foundation the rest of the program will build on. Using the policy, standard, and procedure hierarchy from Module 1, you will draft the core governance documents this startup currently lacks, build a risk register tailored to its specific technology and customer base, and sequence a compliance roadmap that a real founder could credibly commit to funding.

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.

Drafting the Core Governance Documents

Draft an information security policy stating management's broad intent, an access control standard translating that intent into specific, measurable requirements such as mandatory multi-factor authentication for all administrative access, and a compliance roadmap sequencing work toward SOC 2 readiness over the coming twelve months of active operation, continued growth, and steady hiring. Keep the three documents distinct exactly as the hierarchy lesson described, since a startup this size will need to update its standards far more often than its policy as tooling changes.

Analogy🏏Cricket

🎬 Think of it like movies: a production keeps the screenplay, the shooting schedule, and the daily call sheet as three separate documents on purpose. The screenplay states the story's intent and rarely changes; the schedule translates it into concrete scenes; the call sheet is reissued almost every day as locations and weather shift. Keeping policy, standard, and procedure in three layers works identically — the policy holds management's broad intent, the standard sets measurable rules like mandatory MFA, and each flexes on its own clock. Merge them into one script and a single location change forces a full rewrite and re-approval. This reveals why distinct layers keep the frequent updates cheap.

Building a Context-Specific Risk Register

Build a risk register covering the specific risks implied by the startup's technology stack and customer base described in the brief, applying the same rigor as the Module 1 practice exercise but tailored closely to this company's actual context rather than a generic, reused template borrowed from somewhere else entirely.

Analogy🏏Cricket

💪 Think of it like fitness: a coach worth trusting doesn't hand every client the same photocopied workout — they assess this body's history, injuries, and goals before writing a single set, because a plan built for someone else quietly trains the wrong things. Building this risk register the same way means covering the risks that actually flow from this startup's stack and customer base, applying real rigor but never reaching for a generic template borrowed from another company. The movements are standard; the programming is specific. This reveals why a tailored register, not a reused one, is the only version that trains against the real weaknesses.

Because this startup stores customer financial data on a shared cloud account with no dedicated security hire, expect several risks to score in the high or critical band, and resist the temptation to soften scores just to make the initial picture look better than it honestly is.

Analogy🏏Cricket

♟️ Think of it like chess: an honest player analyzing a lost position doesn't quietly relabel a blunder as 'interesting' to feel better — they mark it as losing, because only an accurate evaluation reveals which threats to defend first. Scoring this register the same way means letting the shared cloud account, the absent security hire, and the exposed financial data land in the high or critical band where they belong, and refusing to soften the numbers just to make the opening look calmer than it is. A flattering evaluation loses the game slowly. This reveals why honest critical scores, not comfortable ones, are what guide the defense correctly.

text

Sample risk register entries for the capstone company

ID   Risk                                        Category    L  I  Score  Band
R1   No MFA enforced on cloud admin console       Technical   4  5  20     Critical
R2   Shared password vault, no individual accounts Operational 3  4  12     High
R3   Customer financial data lacks encryption at rest Technical 3  5  15    High
R4   Third-party analytics vendor never reviewed   Third-party 2  4  8      Medium

Sequencing a Realistic Compliance Roadmap

Your compliance roadmap should sequence remediation realistically, addressing the highest-risk gaps first and accounting for the limited security headcount typical of a company this size, producing a plan a real founder or CTO could credibly commit to funding, staffing, and executing on a realistic, clearly achievable schedule within the available budget. Resist sequencing purely by how easy a fix is to implement; a quick but low-impact fix should not jump the queue ahead of the critical MFA gap simply because it takes less engineering time.

Analogy🏏Cricket

🍳 Think of it like cooking: a chef plating a multi-course dinner sequences the kitchen by what the meal actually needs — the slow braise goes on first because it gates everything else, not because the garnish is quick and satisfying to finish. A realistic compliance roadmap works the same way: the critical MFA gap earns the first burner because it blocks the most, while a fast but low-impact fix must wait its turn rather than jump the queue just for being convenient. A founder funds the plan that respects the real order of operations. This reveals why sequencing by risk severity, not by ease of implementation, produces a roadmap someone will actually staff and pay for.

Governance documents (policy, standard, procedure) should stay in three distinct layers, matching the Module 1 hierarchy.
The risk register must reflect this specific company's technology and customer base, scored honestly even when the picture looks bad.
Several risks are expected to land in the high or critical band, given the company's lack of MFA and encryption at rest.
The compliance roadmap sequences remediation by actual risk severity, not by which fix is easiest to implement first.
A credible roadmap accounts for the startup's limited security headcount rather than assuming unlimited execution capacity.