Risk Register vs Risk Log: What’s the Actual Difference?

On March 7, 2017, the Apache Software Foundation published CVE-2017-5638, a critical remote-code-execution flaw in the Struts web framework. The Department of Homeland Security US-CERT notified Equifax the next day. The Equifax security team logged the issue in its operational vulnerability tracking on March 9, 2017, but the threat never escalated to the enterprise risk register read by the board.

Attackers exploited the unpatched flaw between May 13 and July 30, 2017, exfiltrating data on 147 million US consumers. Equifax disclosed the breach on September 7, 2017. The FTC settlement of up to $700 million landed in 2019, and total breach-related costs crossed $1.4 billion. The risk register vs risk log distinction is the single most consequential definition in GRC that practitioners still get wrong.

The Practitioner Cheat Sheet on Risk Register vs Risk Log
The risk register vs risk log distinction is not academic. The risk register is forward-looking and lists what could happen at the enterprise level with owners, scores, controls, and treatment plans. The risk log is backward-looking and captures what already happened at the operational level, including near-misses, incidents, and losses that should feed back into the register.
On March 7, 2017, the Apache Software Foundation published CVE-2017-5638 for the Struts framework. The Equifax security team logged the vulnerability the next day after the DHS US-CERT notification, but the issue never escalated from the operational risk log to the enterprise risk register. From May 13 to July 30, 2017, attackers took 147 million records. The FTC settlement reached up to $700 million in 2019, with total costs above $1.4 billion.
ISO Guide 73:2009 defines a risk register as a record of information about identified risks. ISO 31000:2018 expects documentation of identified risks but does not mandate the word register. PMBOK 7th edition treats the risk register and the risk log as separate artifacts for projects. COSO ERM 2017 assumes enterprise-level risk registry as part of the framework.
The risk register vs risk log split shows up clearest in the row count. A mid-size US enterprise typically carries 30 to 150 risk register entries and 1,000+ risk log entries per year. Boards read the register quarterly; operations updates the log daily.
When a risk log entry crosses a defined trigger threshold (severity, frequency, novelty, regulatory exposure, board interest), it must promote to the risk register. A documented promotion path with named owner, due date, and audit trail is the single most overlooked control in the risk register vs risk log debate.
Standards alignment determines which tool is mandatory. ISO Guide 73 and COSO ERM 2017 require the risk register at the enterprise level. PMBOK and ITIL require the risk log at the operational and project level. NIST RMF SP 800-37 uses the POAM (Plan of Actions and Milestones), which sits between the two. Most US enterprises run all three.
The risk register vs risk log answer for any GRC team in 2026 is both. Build the risk register as the board-facing forward inventory. Build the risk log as the operational event capture. Wire a documented escalation path between them with thresholds, owners, and audit trail. The cases where companies lost the most money are the cases where the wire was missing.

This walkthrough draws the practical line between a risk register and a risk log, with definitions from ISO Guide 73, PMBOK 7th edition, and COSO ERM 2017, then shows the escalation wire every US enterprise needs to install between the two. Our key elements of a risk register guide anchors the register side.

What “Risk Register vs Risk Log” Actually Means in Practice

Several practitioners use the terms risk register and risk log interchangeably, and that confusion is the source of the breaches. The two artifacts carry different audiences, different cadences, different fields, and different owners. Treating them as synonyms is how operational issues stop short of the audit committee.

The risk register is the forward-looking enterprise inventory of what could happen. The risk log is the backward-looking operational record of what already happened. Both need to exist in any mature GRC stack. The connection between them is the escalation wire that promotes log entries into register entries when they cross defined thresholds.

The “Vs” Misleads, So Pin Down the Definitions of Register and Log

The phrase risk register vs risk log implies that practitioners pick one. In practice both exist side by side. The risk management lifecycle runs through identification, assessment, treatment, monitoring, and review. The register holds the program; the log feeds the program with evidence of what is actually happening on the ground.

Defining the Risk Register: The Enterprise Master Inventory

A risk register is the formal documented inventory of identified risks at a defined scope, usually the enterprise. Each row carries a risk description, a probability and impact score, an inherent risk rating, current controls, residual risk, treatment plan, named owner, and review date. The register lives at the board and audit committee level.

Mature risk registers carry between 30 and 150 entries at a US mid-size enterprise. Going larger than 150 means the register is operating at too granular a level and should split into business-unit sub-registers. Our how to conduct a risk assessment guide walks the methodology that produces a register at the right scope.

Standard Fields That Belong in a Risk Register

Eight fields show up in every credible risk register: risk ID, risk description, category, inherent likelihood and impact, current controls, residual likelihood and impact, treatment plan with owner and due date, and last review date. Sophisticated registers add control-effectiveness ratings, key risk indicators, and links to the operational risk log. Our key elements of a risk register page lays the field list out completely.

The register is also where the institution captures its risk appetite alongside each entry. Treatment options follow the four classic responses: avoid, transfer, mitigate, accept. The approaches and tools for risk identification guide anchors the upstream work, and the five steps of the risk management process sets the cadence.

ISO Guide 73 and the Risk Register Definition

ISO Guide 73:2009 (Risk Management Vocabulary) defines a risk register as a record of information about identified risks. The ISO 31000:2018 standard requires documentation of identified risks but stops short of mandating the term register. The result: any documented and reviewable risk inventory satisfies ISO 31000, and most US enterprises use the word register as the de facto label.

Defining the Risk Log: Where Issues First Get Captured

A risk log is the chronological operational record of what actually happened: near-misses, incidents, losses, control failures, audit findings, complaints, and process deviations. Each row carries an event ID, date, description, severity, root cause, immediate response, and status. The log lives at the operational, project, or process level and updates in real time.

Figure 1. Risk register vs risk log volume and cadence at a mid-size US enterprise; the log carries 10-20x more entries than the register.

PMBOK Origins of the Risk Log

The risk log emerged from the project management discipline. PMBOK 7th edition formalized both the risk register and the risk log as separate project artifacts. The project risk register lists threats and opportunities to project objectives. The project risk log captures events as they happen during execution and is updated by the project lead, not the risk function.

Risk Log Fields That Differ From the Register

The risk log carries fields the risk register does not need: event time stamp, immediate action taken, escalation contact, ticket reference, evidence attachments, and closure date. The log does not need likelihood scoring because the event already happened. The log severity is the impact at the moment of capture, not a forward-looking distribution.

US enterprises that run mature risk logs also capture root cause classification, near-miss flag, and a link to any related register entry. The near-miss flag is the most underused field in any risk log. Treating a near-miss as a fully realized event creates the data trail that triggers register promotion before the actual loss arrives.

Side-by-Side: Risk Register vs Risk Log in 8 Dimensions

Eight dimensions separate the risk register from the risk log in any GRC team that runs both. Each dimension produces a different design choice in the underlying spreadsheet, GRC platform, or SaaS tool. Confusing the dimensions is how an organization ends up with a register that reads like a log or a log that reads like a register.

Dimension	Risk Register	Risk Log
Time orientation	Forward-looking. What could happen.	Backward-looking. What already happened.
Primary owner	Risk function / CRO / Board.	Operations / Project lead / Process owner.
Update cadence	Quarterly with ad hoc updates after material events.	Real-time. Daily during incidents.
Lifecycle of an item	Identified, assessed, treated, monitored, retired.	Logged, triaged, responded, closed.
Scoring	Likelihood x impact. Inherent and residual.	Severity at the moment of the event. No likelihood.
Standards anchor	ISO Guide 73, ISO 31000, COSO ERM 2017.	PMBOK 7th, ITIL 4, ISO 27035.
Audit committee view	Top 10-20 risks reported quarterly.	Aggregated near-miss trends, monthly or quarterly.
Typical row count	30-150 enterprise-level items.	1,000+ entries per year at mid-size US firm.

When to Use a Risk Register, a Risk Log, or Both (Standards View)

The standards space settles the question of whether a US enterprise needs a risk register, a risk log, or both. The short answer is both, but the longer answer depends on which standards the institution claims to follow. The ISO 31000 vs COSO ERM framework comparison anchors the enterprise side.

Figure 2. Standards crosswalk for risk register vs risk log vs issue log. Required (navy), Mentioned (blue), Not addressed (white).

ISO 31000, COSO ERM, and the Risk Register Mandate

ISO Guide 73:2009 explicitly defines the risk register. ISO 31000:2018 requires documentation but does not name the register. COSO ERM 2017 expects an enterprise-level risk inventory that maps to strategy and performance, which most institutions implement as a register. Our importance of enterprise risk management page carries the case for the enterprise inventory.

PMBOK 7th and Project Risk Log Expectations

PMBOK 7th edition treats the project risk register and project risk log as distinct artifacts. ITIL 4 keeps the same split for service operations, where the configuration management database holds the forward inventory and the incident and problem logs hold the backward record. ISO 27035 defines the cybersecurity incident log as the central artifact for cyber response. Project and operational tracking always needs a log.

How a Risk Log Escalates Into the Risk Register

The most consequential design choice in any risk register vs risk log discussion is the escalation rule. The rule defines the point at which a log entry stops being an operational item and becomes an enterprise risk worthy of board attention. Without a documented rule, log entries get stuck in operational triage and the register stays stale.

Three-Step Escalation From Risk Log to Risk Register

Step one is detection: an event is logged with severity, root cause, and owner. Step two is pattern recognition: if three or more similar events occur in 90 days, or if a single event crosses a defined severity threshold, the owner files a register-promotion form. Step three is risk function review: the risk team validates the promotion, scores the new register entry, and reports the change to the audit committee.

Trigger Thresholds That Promote a Log Entry to the Register

Five trigger thresholds belong in every escalation policy. Financial impact above the materiality threshold (often 1% of net income). Regulatory exposure where reporting obligations apply. Novel attack vector or failure mode not yet on the register. Customer harm or public disclosure risk. Pattern of three or more linked log entries in 90 days. Our risk appetite statements examples page anchors the threshold work.

Worked Examples: Risk Register vs Risk Log at Two US Companies

Two cases illustrate how the risk register vs risk log split decides outcomes. The first is Equifax in 2017, a textbook escalation failure. The second is a mid-size US manufacturer that built the escalation wire after a 2023 near-miss and avoided a 2024 ransomware loss. Both show the same mechanic in opposite directions.

Figure 3. Five US-headline cases where a risk log existed but the enterprise risk register missed the item until after the loss.

Equifax 2017: Risk Log Caught It, Register Missed It

Apache disclosed CVE-2017-5638 on March 7, 2017. US-CERT notified Equifax on March 8, and the Equifax security team’s vulnerability log carried the entry from March 9. Internal scans on March 15 failed to find the affected systems.

The vulnerability did not promote from the operational log to the enterprise risk register, so the board never saw it on the quarterly read. Attackers exploited the unpatched flaw from May 13 to July 30, 2017. The escalation gap was a process gap, not a technology gap.

The cost: 147 million records, SEC charges against the former CIO, an FTC settlement of up to $700 million, total breach costs above $1.4 billion. The single missing control was a documented escalation rule moving the CVE from the vulnerability log into the enterprise risk register where the CISO and audit committee would have read it.

A Manufacturing CFO Reads Both Artifacts in One Tabletop

A $400 million US food-manufacturing company ran a tabletop exercise in Q1 2024 after three operator-error events appeared on the plant safety log in the prior 90 days. The risk function promoted the pattern to the enterprise risk register as a new entry: control failures driven by night-shift training gaps. The board funded a training program by Q2.

The same escalation discipline caught a separate risk vector months later. In Q3 2024, an unrelated supplier was hit with ransomware, which would have created a downstream supply disruption inside two weeks.

The CFO already had a vendor-concentration entry on the register, traced back to a log pattern from 2023, with a documented mitigation plan including a backup supplier and inventory buffer.

The loss was avoided because the register-promotion path worked. The 2023 near-miss in the operational log had triggered promotion to the register, the register had funded a mitigation plan, and the plan was ready when the 2024 event hit. Our operational risk management framework carries the same structure for any US enterprise.

Frequently Asked Questions About Risk Register vs Risk Log

What Is the Difference Between a Risk Register and a Risk Log?

A risk register is the forward-looking enterprise inventory of risks that could affect the institution, with owners, scores, controls, and treatments. A risk log is the backward-looking operational record of events that already happened, including near-misses, incidents, and losses. The register lives at the board level; the log lives at the operational level. They are connected by a documented escalation rule.

Is a Risk Log the Same as an Issue Log?

Risk log and issue log are close cousins but not identical artifacts. The risk log focuses on events with potential risk exposure such as near-misses, control failures, and suspicious activity. The issue log focuses on operational problems already affecting service delivery, typically ticket-style operational issues that need immediate fixing. PMBOK 7th edition keeps them separate for project work even when smaller institutions merge them in practice.

Do I Need Both a Risk Register and a Risk Log on the Same Project?

Yes, PMBOK 7th edition requires both artifacts at the project level for any non-trivial engagement. The project risk register identifies threats and opportunities to project scope, schedule, cost, and quality before execution starts. The project risk log captures events as they unfold during delivery and feeds both the closeout report and the lessons-learned database that informs the next project.

How Often Should a Risk Log Be Reviewed Against the Risk Register?

Monthly at the operational level and quarterly at the enterprise level. The operational review surfaces patterns of three or more similar log entries that should escalate. The quarterly review surfaces emerging risks the register does not yet name. Annual reviews are too infrequent for an active operational environment and miss the escalation window.

Which Standard Requires a Risk Register, ISO 31000 or COSO?

Both standards expect documented identified risks but differ on the explicit terminology. ISO Guide 73:2009 explicitly defines the risk register, while ISO 31000:2018 requires documentation without mandating the term. COSO ERM 2017 expects an enterprise risk inventory that institutions implement as a register, and most US enterprises follow both standards with one register satisfying both simultaneously.

Can a Risk Register Replace a Risk Log Entirely?

No, the register and the log serve different audiences and update at different cadences. A register updated daily becomes unwieldy for the board to read, while a log read by the board becomes meaningless because most log entries are operational noise. The right design keeps them separate with a documented escalation rule that promotes log entries upward when they cross defined thresholds.

What Columns Belong in a Risk Log vs a Risk Register?

The risk log needs: event ID, timestamp, description, severity, root cause, immediate action, owner, ticket reference, status, closure date. The risk register needs: risk ID, description, category, inherent and residual scores, current controls, treatment plan, owner, due date, review date. Roughly 50% of fields differ between the two artifacts because their purposes differ.

Who Owns the Risk Log vs the Risk Register?

The risk log is owned by the operational or process owner: plant manager, IT operations lead, project manager, branch manager. The risk register is owned by the risk function (CRO, head of ERM, or audit committee chair on smaller institutions). Both have a documented owner per entry, but the program-level ownership splits along operational versus enterprise lines.

Common Risk Register vs Risk Log Mistakes (Pitfalls Table)

Five patterns surface in OCC, SEC, and FRB findings when the risk register vs risk log distinction breaks down inside a US enterprise. The table captures the recurring miss, the root cause, and the remedy that closes the finding. Each pattern compounds faster at smaller institutions without a dedicated risk function.

Pitfall	Root Cause	Remedy
Risk register and risk log treated as synonyms	Inherited terminology from a prior GRC platform or audit firm	Adopt the ISO Guide 73 register definition; relabel the operational log; train every owner on the difference
No documented escalation rule from log to register	Risk function and operations report to different executives	Write a one-page escalation policy with five trigger thresholds; board-approve it; audit quarterly
Risk log entries closed before pattern recognition runs	Operational pressure to close tickets fast	Mandate 90-day pattern review on closed entries; tag for retention
Register entries never traced back to log evidence	Register written from a workshop, not from operational reality	Require every register entry to cite at least one supporting log entry or external authority
Both artifacts owned by the same person	Small risk team trying to cover both layers	Split ownership: log to process owner, register to risk function; both meet quarterly
Cyber risk log isolated from enterprise register	Cyber team operates as a silo separate from ERM	Crosswalk the cyber risk log to the enterprise register monthly; track promotion latency as a KRI
No audit trail on promotion from log to register	Promotion happens via email or hallway conversation	Build a register-promotion form with timestamp, approver, and rationale; retain for seven years

Looking Ahead: Risk Register vs Risk Log in 2026-2027

Three forces will reshape the risk register vs risk log distinction at US enterprises between 2026 and 2027. The first is AI-assisted pattern detection. GRC platforms now apply natural-language matching across operational logs to surface candidate register-promotion events, cutting the latency between log entry and register update from months to days.

The second force is regulatory disclosure. The SEC cybersecurity 8-K rule from December 2023 and the proposed SEC enterprise risk management disclosure rules raise the cost of a register that misses material risks visible in the log. Our guide to audit risk assessment anchors the audit-committee response.

The third force is third-party concentration. Verizon’s 2025 DBIR found third-party breaches at 30% of all incidents. Vendor risk logs are the fastest-growing operational artifact in any US enterprise, and the register-promotion path from vendor incident to enterprise risk is the new highest-payoff control. Our how to manage third party risk page pairs with the mitigate vendor risks playbook for the workflow.

The US enterprise that runs both artifacts with a documented escalation wire is the institution that absorbs all three forces with the smallest GRC rewrite. The register-vs-log distinction is the visible architecture. The discipline that connects them (documented thresholds, named owners, time-stamped promotions) carries the program forward into the post-disclosure era.

Next Steps After Your Risk Register vs Risk Log Audit

Risk Publishing helps US enterprises wire the escalation path between the operational risk log and the enterprise risk register, including the trigger thresholds the next audit committee will ask about.

Review the advisory services page to see how the engagement runs, and contact the practice when the register vs log audit is the next item on the GRC roadmap.