Risk Register 101: What, How and Why

Full disclosure up front: we build Risk Vault, an enterprise risk management platform, so we think about this stuff an unhealthy amount. But this post stands on its own — the product pitch doesn't show up until the end, and by then you'll know exactly what problem it solves.

(Quick terminology note: people say risk register and risk ledger interchangeably. Same thing. "Register" is the word you'll see in compliance frameworks; "ledger" just emphasizes that you keep updating it like bookkeeping, instead of writing it once for an audit and shoving it in a drawer.)

Now, the actual post.

---

Ask three executives at the same company what their biggest risks are, who owns them, and what's being done about them. You'll get three different answers and at least one "let me get back to you on that."

The information exists. It's just scattered across spreadsheets, Slack/Teams threads, and one person's memory. And that person is about to go on vacation.

A risk register fixes that. It's one of the simplest, highest-leverage practices in modern risk management — and increasingly, it's not optional.

So what even is it?

Think of it like a checkbook register, but for bad things that might happen. The accounting analogy is intentional: a financial ledger records every transaction so a business can state its position at any moment. A risk ledger does the same for threats and uncertainties, so at any moment, you can articulate your risk posture with evidence behind it.

Every risk gets written down, scored, assigned to a human, and tracked until it's fixed or someone officially decides to live with it. Each entry answers the same basic questions:

• What could go wrong?
• How bad is it? Both before you've done anything (inherent risk), and after (residual risk)
• What are we doing about it?
• Whose job is it?
• If we're accepting the risk, who signed off on that, and when?

That's it. It's not fancy. It's just the one place where the truth about your risks actually lives. A typical entry looks like:

Plot twist: almost no law actually says "risk register"

Here's the fun fact I want you to hold onto: go search the text of basically any major security or privacy law for the phrase "risk register." You'll come up empty almost every time.

What laws actually require is a documented, repeatable process: identify risks, assess them, deal with them, assign owners, keep evidence, review it all on a schedule. The law says "show your work." A risk register is simply how companies show it, because it's the most audit-friendly way to meet those duties.

Roughly:

So nobody's going to fine you for not having a file named "risk register." But if you can't produce risk assessments, owners, treatment decisions, and evidence on demand? That's when the trouble starts.

Why keep one? (Besides avoiding trouble)

1. One version of the truth. Security, legal, and compliance stop maintaining three conflicting lists, and you stop getting three different answers to the same question.
2. Somebody's actually on the hook. A department can't feel guilt. A named person can. Unowned risks are unmanaged risks.
3. You can prioritize. With consistent scoring, you spend limited budget on your biggest remaining risks instead of whatever screamed loudest this week.
4. Audits stop being terrifying. Instead of a quarterly scramble to reconstruct history, you just export the ledger.
5. You build actual institutional memory. Which fixes worked? Which "we'll live with it" decisions have been quietly aging for three years? The ledger remembers.
6. You make better decisions. A summarized ledger becomes board reporting, M&A due diligence material, and the input for calls like launching a product or deploying an AI system.
7. When something goes wrong, you're not starting from zero. You already know whether this was a known risk, how severe it was assessed to be, and which controls were supposed to catch it.

Who's making people do this?

The list keeps growing. Here's the tour.

Certifications — where most companies first meet the risk register

ISO 27001 is the big one, commercially. You literally cannot get certified without documented risk assessment (Clause 6.1.2) and a risk treatment plan (Clause 6.1.3), and auditors expect to see scenarios, scoring methodology, existing controls, residual risk, treatment decisions (mitigate, avoid, transfer, or accept), named owners, dates, evidence, and formal risk-acceptance sign-offs.

SOC 2 doesn't name a risk register either (and pedants will tell you it's technically an attestation, not a certification) but its Common Criteria expect you to identify, analyze, and manage risks relevant to your systems and commitments. Auditors routinely ask for exactly this artifact, and a mature evidence set includes the register plus vendor assessments, vulnerability records, and management-review evidence.

Beyond those: HITRUST is explicitly risk-based, PCI DSS requires formal risk analysis if you touch card data, and the ISO family keeps expanding:

One myth to bust while we're here: ISO 31000 is general risk-management guidance. You cannot get "ISO 31000 certified," and anyone selling you that is selling something that doesn't exist.

United States

• HIPAA — if you touch electronic health records, the Security Rule requires "an accurate and thorough assessment" of risks to ePHI. It never says "register," but skipping the risk analysis is one of the most common findings in federal enforcement actions.
• SEC cyber rules — public companies must disclose material incidents and describe their risk-assessment and management processes annually, including board oversight. Private company? Doesn't apply to you yet, but enterprise customers and future investors increasingly expect the same hygiene.
• State privacy laws like the CCPA/CPRA — require assessments for higher-risk processing (targeted ads, selling data, sensitive data, profiling with significant effects).
• Federal contractors — FISMA and the NIST Risk Management Framework flow down through contracts, and FedRAMP operationalizes it with POA&Ms, pretty much a risk register wearing a government-issue hat.
• Financial services — banks, broker-dealers, insurers, and fintechs face risk-management expectations from multiple regulators (see, e.g., NYDFS's cybersecurity rules). A formal register is standard expected evidence even when no rule uses the word.

Europe and the UK

• GDPR / UK GDPR — no general risk register requirement, but Article 35 requires a Data Protection Impact Assessment (DPIA) before high-risk processing. The best model: the DPIA is your per-project deep dive; the privacy risk register is the big picture across everything. And per ICO guidance, if high risk remains even after mitigation, you have to consult the regulator before you start.
• EU AI Act — this is as close as it gets to a legally mandated risk ledger. Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a risk-management system that's continuous and iterative across the system's entire lifecycle. Even if your AI isn't classified high-risk, keep structured records of how you decided that.
• DORA — EU financial entities have been under this since January 2025, and here's the rare thing: DORA literally requires a named register, the "Register of Information", covering all ICT third-party arrangements. One of the few places the actual word appears in law.
• NIS2 — cybersecurity risk management for "essential and important entities": risk analysis, incident handling, supply-chain security, MFA, training, the works. Doesn't name a register, but a current cyber-risk register is the clearest way to prove you have the program.
• The UK grab bag — no general rule for ordinary private companies, but listed companies, FCA/PRA-regulated firms, and pension trustees are all expected to manage risk formally. Even charity trustees get a risk register template from the Charity Commission, and law firms commonly keep one as evidence of meeting SRA expectations. When charity trustees are doing this, it's officially mainstream.

(One footnote for the hardware folks: EU product-safety and CE-marking rules require risk analysis too, but as per-product technical files, not as a company-wide register.)

How to start without making it a whole thing

1. Figure out where you'll maintain this information. While we're biased and believe Risk Vault is the best platform for it, if you're just starting a spreadsheet is fine too. Really.
2. Pick a scoring method (a simple 5×5 likelihood/impact grid works. NIST SP 800-30 is a good reference) and stay consistent so entries are comparable.
3. Review your risks regularly: at least quarterly, plus whenever something big changes, like a new system, new vendor, an incident, a new AI deployment.
4. Document risk acceptances explicitly: who, when, and why. An acceptance with no name attached becomes a surprise later.
5. Track residual risk, not just inherent risk. The gap between the two tells you whether your controls are earning their keep.

The part where spreadsheets go to die

Here's the honest arc every growing company goes through: the spreadsheet works great with fifteen risks and one person who cares. Then it becomes thirty risks across four teams, someone filters the wrong version before the board meeting, review dates quietly pass with no reminders, and an auditor asks for the history of a risk-acceptance decision made two reorgs ago, and there is no history, because spreadsheets don't keep one.

At that point, the ledger stops being a document and starts being an operational system. And operational systems need tooling. That's exactly why we built Risk Vault.

What Risk Vault does

Risk Vault is an enterprise risk management platform built around one idea: the risk ledger should be the living, auditable heart of your risk program — not a file someone updates the week before the audit.

In practice, that means:

• A single, centralized ledger — one source of truth for risks across security, privacy, compliance, operational, third-party, and AI risk, instead of parallel team-by-team lists.
• Structured scoring — inherent and residual risk, consistent methodologies, and risk-appetite context so entries are actually comparable.
• Named owners and accountability — every risk has a human, with statuses, due dates, and escalation when things stall. ("IT" is not an owner. Risk Vault won't let it be one.)
• Evidence attached where it belongs — each risk links to its controls, policies, test results, vendor assessments, incidents, and corrective actions, so audit prep is an export, not an archaeology project.
• Regulatory and framework mappings — risks can be mapped to the frameworks that ask about them: ISO 27001, SOC 2, HIPAA, PCI DSS, GDPR/DPIAs, DORA, NIS2, and EU AI Act Article 9 obligations.
• Formal risk-acceptance workflows — who accepted it, when, on what basis, and when it expires. No more aging mysteries.
• Immutable history and audit trail — every change tracked, so you can show regulators, auditors, or acquirers not just your risk posture today, but how it evolved.
• Review cadences that actually happen — scheduled and event-triggered reassessments, with board-ready reporting on top.
• Security and access controls — limit sensitive risks to authorized users, or control access by business unit. Use your own encryption key. Don't worry about other companies sharing the same database.

The regulatory requirements all emphasize the same thing: documented, ongoing risk management. Risk Vault is the "ongoing" part; it turns compliance from a point-in-time assessment into auditable operations.

The bottom line

The honest framing is this: laws, certifications, and enterprise buyers don't require a file. They require proof that you find risks, deal with them, own them, and keep at it. A maintained risk register is the standard way of doing and demonstrating all of that.

Start small, keep it current, and make it the one place where the truth about your risks lives. Your future self, the one in the middle of an audit, will send a thank-you note.

And if you'd rather not build that machinery out of a spreadsheet, come see what Risk Vault does.