Practice — build a risk register for a sample SaaS company — Governance, Compliance & Career Readiness

This hands-on exercise brings Module 1 together. You will construct a working risk register for a hypothetical multi-tenant SaaS company handling customer financial data, applying the methodology from earlier lessons rather than just reading about it. The goal is not a perfect document but a repeatable habit: identify realistic risks, score them consistently, assign clear ownership, and make the result readable to someone who was not in the room.

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.

The Target Company

The scenario company is a 60-person SaaS startup processing customer invoicing and payment data, hosted on a major cloud provider, using several third-party vendors for analytics and customer support tooling, and preparing to sell to larger enterprise customers who will demand a completed risk register as part of due diligence. Treat these constraints as fixed, exactly as a real compliance officer would inherit them on their first day.

Analogy🏏Cricket

✈️ Think of it like travel: a good itinerary starts by accepting the fixed facts of the trip, the dates, the budget, and the passport you actually hold, instead of planning for a journey you wish you were taking. The scenario here is just as fixed: a 60-person SaaS firm handling payment data, on one cloud, using analytics and support vendors, and chasing enterprise deals that demand a completed register. Treat these as givens, exactly as a real compliance officer inherits them on day one. This reveals that useful planning begins by working with the constraints you are handed, not the ones you would prefer.

Step 1 — Identify Risks Across Categories

List a realistic set of risks spanning technical, third-party, and operational categories, since a register limited to one category rarely reflects how real organizations are actually exposed. Technical risks might include an unpatched dependency or a misconfigured storage bucket; third-party risks might include a vendor breach exposing shared customer data; operational risks might include a departing employee retaining access after their last day.

Analogy🏏Cricket

🎬 Think of it like movies: a screenwriter can't build tension from a single kind of threat, because a good script layers the external danger, the betrayal from within, and the quiet operational failure that undoes everyone. A risk register needs the same range: technical risks like an unpatched dependency or exposed storage bucket, third-party risks like a vendor breach of shared data, and operational risks like a departing employee keeping access. A register stuck in one category reads as flat as a one-note plot. This reveals that real exposure, like real drama, comes from several directions at once.

Step 2 — Score Likelihood and Impact

For each risk, assign a likelihood and impact rating using the 5x5 matrix introduced earlier in this module, then calculate an overall risk score, and translate it into a priority band such as low, medium, high, or critical. This forces the same prioritization discipline a real compliance officer must apply under limited time and budget, rather than treating every risk as equally urgent.

Analogy🏏Cricket

🎮 Think of it like gaming: a raid leader assigns each incoming threat a priority by combining how often it fires with how hard it hits, so a frequent chip-damage attack and a rare wipe mechanic get very different responses. Scoring each risk on the 5x5 matrix does the same, multiplying likelihood by impact into a number that sorts everything into low, medium, high, or critical. That forces the prioritization a real compliance officer lives with under limited time and budget, instead of treating every risk as equally urgent. This reveals that a score is really a decision about where scarce effort goes first.

text

Sample partial risk register (fill in the rest yourself)

ID   Risk                                  Category    L  I  Score  Band
R1   Unpatched dependency in prod service  Technical   3  4  12     High
R2   Vendor (support tool) data breach     Third-party 2  4  8      Medium
R3   Ex-employee retains access post-exit  Operational 2  3  6      Medium
R4   Misconfigured storage bucket exposed  Technical   2  5  10     High

Step 3 — Assign Treatment and Ownership

For each risk, record a treatment decision — accept, mitigate, transfer, or avoid — along with a named owner and a target remediation date, mirroring exactly what the risk register lesson described as the living record's core fields. A risk with no owner and no date is not really being managed; it is only being observed, and auditors are quick to notice the difference.

Analogy🏏Cricket

⚽ Think of it like sports: a coach's game plan isn't complete until every marked opponent has a named defender assigned and a clear instruction to press, contain, or drop off. A tactic with no player attached is just a wish shouted from the touchline. Each risk needs the same: a treatment decision to accept, mitigate, transfer, or avoid, plus a named owner and a target date. A risk with no owner and no deadline isn't being managed, only observed, and auditors spot that gap fast. This reveals that accountability, not intention, is what separates a real plan from a hopeful one.

text

Sample treatment assignment for the register above

ID   Treatment   Owner              Target date
R1   Mitigate    Eng Lead           2 weeks
R2   Mitigate    Procurement        Next vendor review cycle
R3   Mitigate    IT Security        Immediate (this sprint)
R4   Mitigate    Cloud/Infra Owner  1 week

Step 4 — Make It Evidence-Ready

The completed register should read as evidence-ready, meaning a reviewer unfamiliar with the company could understand each risk's business context, current status, and next action without additional explanation. This is the same standard auditors and boards apply, and reaching it in a practice exercise builds the exact habit needed for a real engagement.

Analogy🏏Cricket

🏏 Building this register is like preparing a full team dossier before a big series: every opposition batsman's weakness noted, rated, and paired with a specific bowling plan and a fielder named to execute it. A dossier that says only "watch out for their opener" with no plan is useless under pressure; one that says exactly who bowls what, to which field, and when, is what a real captain can act on without further explanation. The same holds for a risk register, where an entry naming the risk, its score, its owner, and its next action lets a board act at once. This reveals that evidence-readiness is really writing so a stranger can act without asking you a thing.

A realistic risk register spans technical, third-party, and operational categories, not just one.
Every risk gets a likelihood and impact score converted into a priority band using a consistent matrix.
Each risk needs a named owner, a treatment decision, and a target remediation date to be truly managed.
An evidence-ready register is understandable to a reviewer with no prior context on the company.
This is the same standard real auditors and boards expect from a functioning risk program.