Risk Register 101: What, How and Why

Full disclosure: we build RiskVault, an enterprise risk management platform. We spend a lot of time thinking about risk registers. This article is meant to be useful whether you use RiskVault, a spreadsheet, or something else entirely. We'll get to the product at the end.

One terminology note before we start: risk register and risk ledger are often used to mean the same thing. “Risk register” is the term you’ll see most often in standards and compliance programs. “Risk ledger” emphasizes something important: this should be a living record that changes as your business changes, not a document you update once a year for an audit.

---

If your CEO, CISO, and General Counsel were each asked the same three questions right now, would their answers match?

What are our biggest risks? Who owns them? What are we doing about them?

At many companies, the answer is no. Security has a spreadsheet. Legal has another one. A project team is tracking something in Jira. An important exception was approved in email six months ago. One person remembers why a risk was accepted, but nobody else does.

That works—until it doesn’t.

A risk register gives all of those decisions a home. It is a simple idea, but it becomes surprisingly valuable as a company grows: one place to record risks, assign accountability, track what is being done, and preserve the reasoning behind decisions over time.

And increasingly, customers, auditors, boards, regulators, and investors expect companies to be able to show exactly that.

What is a risk register?

A risk register is a structured record of the things that could materially hurt the business and what the organization is doing about them.

The accounting analogy is useful. A financial ledger gives you a current view of the company’s financial position because transactions are recorded as they happen. A risk ledger does something similar for uncertainty: it gives you a current view of your risk posture, along with the evidence and decisions behind it.

For each meaningful risk, you record the basics:

• What could go wrong?
• How serious is it? Both before controls (inherent risk) and after controls (residual risk)
• What are we doing about it?
• Who owns it?
• If we are accepting the risk, who approved that decision, when, and why?

That is the core of it. The value comes from keeping those answers consistent and current.

A typical risk entry might include:

The surprising part: most laws do not actually say “risk register”

Search the text of most major security or privacy laws for the phrase risk register and you usually will not find it.

What you will find are requirements to identify risks, assess them, implement controls, assign responsibility, document decisions, retain evidence, and review the process over time.

In other words, the requirement is usually not “maintain a file called a risk register.” The requirement is to be able to demonstrate a repeatable risk-management process.

A well-maintained register is one of the clearest ways to do that.

So the real risk is not that someone will ask, “Where is the file named risk-register.xlsx?”

The harder question is: Can you show what the risk was, how it was assessed, who owned it, what was done about it, and why the final decision was reasonable?

If those answers are scattered across inboxes and old spreadsheets, that becomes painful very quickly.

Why keep one if nobody explicitly requires it?

Because a useful risk register does much more than satisfy an auditor.

1. You get one version of the truth. Security, legal, compliance, operations, and leadership can work from the same record instead of maintaining separate lists that slowly drift apart.
2. Risks have real owners. “IT” or “the business” is not accountable. A named person is. If nobody owns a risk, it tends to become everybody’s problem later.
3. Prioritization gets easier. Consistent scoring helps teams spend time and budget on the most important remaining risks instead of whichever issue is loudest this week.
4. Audits become less disruptive. Instead of reconstructing months of decisions from email and meeting notes, you already have the history.
5. You preserve institutional memory. You can see which mitigations worked, which exceptions were approved, and which “temporary” risk acceptances have quietly been around for years.
6. Leadership gets better information. A summarized register can support board reporting, M&A due diligence, investment decisions, product launches, vendor decisions, and AI deployment reviews.
7. Incidents are easier to understand. When something goes wrong, you can quickly determine whether the risk was known, how it had been rated, and which controls were expected to reduce it.

A good register is not just a compliance artifact. It is a decision record.

Where the pressure comes from

For many companies, the first serious push toward a formal risk register comes from a certification, customer requirement, security review, or regulated market.

Certifications and assurance programs

ISO 27001 is one of the most common commercial drivers. Certification requires documented risk assessment (Clause 6.1.2) and risk treatment (Clause 6.1.3). In practice, auditors expect to see risk scenarios, a scoring methodology, existing controls, residual risk, treatment decisions, owners, dates, evidence, and formal acceptance where applicable.

SOC 2 does not require an artifact literally named “risk register” either—and technically it is an attestation, not a certification—but the Common Criteria expect organizations to identify, analyze, and manage risks relevant to their systems and commitments. A mature evidence set commonly includes a risk register alongside vendor assessments, vulnerability records, and management-review evidence.

Other frameworks push organizations in the same direction. HITRUST is explicitly risk-based. PCI DSS requires formal risk analysis in relevant cardholder-data environments. The ISO family also carries risk-management concepts into several domains:

One useful distinction: ISO 31000 is general risk-management guidance. It is not a certifiable management-system standard, so claims of being “ISO 31000 certified” should be treated carefully.

United States

• HIPAA — organizations that handle electronic protected health information must perform an “accurate and thorough assessment” of risks to ePHI under the Security Rule. The rule does not require something called a risk register, but documented risk analysis is fundamental to compliance.
• SEC cyber rules — public companies must disclose material cybersecurity incidents and describe their processes for assessing and managing cybersecurity risk, including board oversight. Private companies are outside the direct scope, but many face similar expectations from enterprise customers, investors, or prospective acquirers.
• State privacy laws such as the CCPA/CPRA — create risk-assessment obligations around certain higher-risk data-processing activities.
• Federal contractors — FISMA and the NIST Risk Management Framework influence requirements that flow through government contracts, while FedRAMP operationalizes risk tracking through artifacts such as POA&Ms.
• Financial services — banks, broker-dealers, insurers, and fintech companies face risk-management expectations from multiple regulators, including frameworks such as NYDFS cybersecurity requirements. Even where the word “register” is absent, formal risk records are standard evidence of a functioning program.

Europe and the UK

• GDPR / UK GDPR — there is no blanket requirement for a company-wide risk register, but Article 35 requires a Data Protection Impact Assessment (DPIA) before certain high-risk processing. A useful model is to treat the DPIA as the deep dive on a particular activity while the privacy risk register provides the broader view across the organization. Under ICO guidance, unresolved high risk can also trigger a requirement to consult the regulator before processing begins.
• EU AI Act — Article 9 requires providers of high-risk AI systems to establish, implement, document, and maintain a continuous and iterative risk-management system across the system lifecycle. Even when an AI system is not classified as high-risk, keeping structured records of the classification and reasoning can be valuable.
• DORA — EU financial entities have been subject to DORA since January 2025. DORA is unusual because it explicitly requires a named Register of Information covering ICT third-party arrangements.
• NIS2 — requires cybersecurity risk-management measures for covered “essential” and “important” entities, including areas such as risk analysis, incident handling, supply-chain security, authentication, and training. A current cybersecurity risk register is a practical way to connect those activities and demonstrate oversight.
• United Kingdom sector requirements — ordinary private companies do not face one universal risk-register rule, but listed companies, FCA/PRA-regulated firms, pension trustees, charities, and professional-services organizations often operate under formal risk-management expectations. The UK Charity Commission even provides risk-management guidance and templates, while law firms commonly use risk registers as part of governance and compliance.

One related point for hardware and product companies: EU product-safety and CE-marking regimes can require risk analysis as well, but those records generally live in product-specific technical documentation rather than a company-wide enterprise risk register.

How to start without turning it into a six-month project

A risk register does not need to begin as a major transformation initiative. The important thing is to start with a structure people will actually maintain.

1. Choose where the register will live. If you are just starting, a spreadsheet can be perfectly reasonable. We obviously believe RiskVault is a better long-term home once the process becomes operational, but the first goal is simply to create a reliable source of truth.
2. Pick a scoring method and use it consistently. A simple 5×5 likelihood/impact matrix is enough for many organizations. NIST SP 800-30 is a useful reference if you want a more formal approach.
3. Set a review cadence. Quarterly is a common baseline, but major events should trigger review too: a new system, a material vendor, an incident, an acquisition, a major product change, or a new AI deployment.
4. Document risk acceptance explicitly. Record who accepted the risk, when, why, and when the decision should be revisited. “We decided to live with it” is not very useful if nobody can later explain who “we” was.
5. Track residual risk, not just inherent risk. The difference between the two tells you whether your controls are actually changing your exposure.

The goal is not to build the perfect taxonomy on day one. The goal is to build a record people trust enough to use.

When the spreadsheet stops being enough

A spreadsheet is often the right place to start. It is familiar, flexible, and fast.

The problem appears later.

Fifteen risks become fifty. One team creates its own copy. Somebody sorts a column and forgets to expand the range. Review dates pass without anyone noticing. Supporting evidence lives somewhere else. A risk is accepted, the approver leaves the company, and two years later an auditor asks why the decision was made.

Now the register is no longer just a list. It is a workflow, a history, an accountability system, and a source of reporting.

That is the point where a spreadsheet starts asking people to do the work that software should be doing.

It is also the reason we built RiskVault.

What RiskVault does

RiskVault is an enterprise risk management platform designed around a simple principle: your risk register should be a living, auditable system of record, not a file that gets cleaned up the week before an audit.

That means giving teams the structure of a real risk-management process without burying them in process for its own sake:

• One centralized risk ledger — a common source of truth across cybersecurity, privacy, compliance, operational, third-party, strategic, and AI risk.
• Consistent scoring — inherent and residual risk, repeatable methodologies, and risk-appetite context so teams can compare risks meaningfully.
• Clear ownership — named individuals, statuses, due dates, and escalation. “IT” is a department, not an accountable owner.
• Evidence connected to the risk — controls, policies, test results, vendor assessments, incidents, corrective actions, and approvals stay attached to the decisions they support.
• Framework and regulatory mappings — risks can be connected to the standards and obligations that care about them, including ISO 27001, SOC 2, HIPAA, PCI DSS, GDPR/DPIAs, DORA, NIS2, and EU AI Act Article 9.
• Formal risk-acceptance workflows — capture who accepted the risk, on what basis, when it was approved, and when the decision expires or needs review.
• A complete audit trail — preserve changes over time so auditors, regulators, customers, boards, and acquirers can see not only the current posture but how it evolved.
• Reviews that actually happen — scheduled and event-driven reassessments, reminders, and reporting instead of calendar archaeology.
• Security and access controls — restrict sensitive risks to the right users or business units, support customer-controlled encryption keys, and keep tenant data appropriately isolated.

Most modern requirements share the same theme: risk management has to be documented and ongoing.

That last word matters. A one-time assessment can tell you what was true on the day it was written. A working risk program has to tell you what is true now, what changed, who made the decision, and what happens next.

That is the problem RiskVault is built to solve.

The bottom line

A risk register is not valuable because a law says you need a spreadsheet with that name. It is valuable because organizations are increasingly expected to show that they can identify meaningful risks, make decisions about them, assign ownership, preserve evidence, and keep the process current.

Start small. Keep the register useful. Review it when the business changes, not just when an audit appears on the calendar.

If you do that, the risk register becomes more than a compliance artifact. It becomes a record of how the company makes decisions under uncertainty.

And when a customer, auditor, board member, regulator, or acquirer asks, “How are you managing this risk?” you will have an answer you can actually show them.

If you would rather build that process on something more durable than a spreadsheet, take a look at RiskVault or contact us for a demo.