Most Risk Registers Are Really Accountability Registers

Most Risk Registers Are Really Accountability Registers

By

Kimly Hong

Every unresolved risk eventually tells you something about how your organization makes decisions.

Picture a risk register with one hundred open items. Some have been there for weeks. Others for eighteen months. One has changed owners three times. Another has a remediation date that has moved every quarter. A few carry the treatment designation “accepted,” although no one can identify who made that decision or when. One entry belongs to a vendor. Another supposedly belongs to Technology, Security, and the business line simultaneously.

The interesting question is not whether those items represent risk. The interesting question is what the register is actually measuring.

On paper, it measures security exposure. Operationally, it records who owns problems, who has authority to resolve them, which deadlines carry consequences, and which organizational boundaries create enough ambiguity that accountability never lands anywhere specific. A risk register becomes an accountability register the moment an identified risk requires someone to own, treat, accept, escalate, or defer it. Every open item contains two stories. One describes the exposure. The other describes what the organization has done about that exposure. Over time, the second story becomes more revealing than the first.

The fields in a standard risk entry capture description, likelihood, impact, severity, controls, and treatment plan. Those fields describe the security problem. Once the entry exists, a different set of variables determines what happens next, and almost none of them appear in the record. Does one person own this, or does the named owner hold authority in name only? What happens when the target date passes? Who challenges the treatment decision, and can the owner defer remediation indefinitely without consequence? Severity helps explain why a risk matters. Governance largely determines how long it remains unresolved.

Risk age is governance telemetry. It does not simply measure elapsed time. It measures how efficiently an organization converts awareness into action. When risks age without resolution, technical complexity is only one possible explanation. Ownership disputes, budget boundaries, vendor dependencies, competing priorities, and insufficient decision authority can be equally important. Risk age demands diagnosis. The range of honest answers to the question “why has this remained open?” tells you more about an organization’s governance than any framework assessment would.

Equifax: Accountability Failing at Ownership

In 2017, Equifax suffered a breach that exposed personal data belonging to approximately 147 million Americans. The technical mechanism was an unpatched Apache Struts vulnerability available for two months before attackers exploited it. The congressional investigation that followed examined more than 122,000 pages of documents. The House Oversight Committee concluded that Equifax had failed to implement clear lines of authority within its internal IT management structure, creating an execution gap between policy development and operations.

The detail that receives less attention than it deserves: Equifax had a patch management policy. The policy defined responsibilities across multiple roles. Congressional investigators found, however, that the policy defined those roles without designating the people actually responsible for filling them. Patch scanning was handled centrally. Remediation was handled regionally. No mechanism existed to verify that patches had been applied, and no follow-up audit had been conducted after a 2015 review identified related concerns. The committee described the result as an honor system.

That is an accountability structure failure expressed through patch management. The organization had documented responsibility without producing accountable ownership. An organization that reads Equifax as a patching lesson implements better patch management. An organization that reads it as an accountability lesson asks a harder question: does every material item have a named individual who must answer for it, or a role category serving as a routing label? A department cannot personally answer for a missed remediation commitment, approve an exception, or defend a risk-acceptance decision. Accountability requires a person, authority appropriate to the risk, and a consequence structure that makes inaction visible.

Capital One: Accountability Failing Through Escalation

Capital One’s 2019 breach exposed information associated with more than 100 million individuals after an attacker gained access to data stored in its cloud environment. The OCC fined Capital One eighty million dollars. The enforcement action centered not on the breach but on the governance failures that allowed the conditions to persist.

The OCC found that Capital One had failed to establish effective risk assessment processes before migrating to the cloud beginning in 2015. Internal audit had not properly assessed the cloud environment and had not effectively reported weaknesses to the Audit Committee. For concerns that internal audit did raise, the board failed to take effective action to hold management accountable. Capital One neither admitted nor denied those specific findings.

What the OCC described was a complete accountability chain: technical environment, risk management, internal audit, management, and board oversight. Risk information existed somewhere in that chain. What the governance structure failed to do was convert that information into obligation at each level where it was received.

A risk entry can record that a finding was escalated. It cannot record that the escalation produced a decision with named accountability and a consequence for non-action. Escalation is not governance merely because information moved upward. Governance occurs when escalation produces a decision, assigns accountability, or triggers a defined consequence. Without that, the organization has built a routing mechanism, not an accountability mechanism. A deadline without a consequence is a date. If remediation timelines can move without triggering a mandatory response, the register records unresolved organizational decisions. The information exists. The accountability mechanism does not.

Morgan Stanley: Accountability Failing Across an Organizational Boundary

In 2020, the OCC assessed a sixty million dollar civil money penalty against Morgan Stanley Bank and Morgan Stanley Private Bank for failures in overseeing the decommissioning of two wealth management data center facilities in 2016. The OCC found that Morgan Stanley failed to effectively assess or address the risks associated with decommissioning its hardware. It failed to adequately assess the risk of subcontracting the work, exercise due diligence in selecting and monitoring the vendor, and maintain an appropriate inventory of customer data on the decommissioned hardware. Similar vendor management deficiencies appeared again during 2019 decommissioning activity, three years after the original failure.

Operational work can cross an organizational boundary. Accountability for the resulting risk cannot. The vendor relationship did not transfer Morgan Stanley’s obligation to know what customer data was on the hardware, to verify the destruction methodology, or to confirm the work was performed as contracted. Those obligations remained with the institution regardless of which entity performed the physical task.

Third-party risks concentrate this problem because the organizational dynamics that make internal accountability difficult become more complex when a boundary exists between the institution and the party doing the work. Inside an organization, contested ownership has an escalation path through shared management. Across a vendor boundary, the accountability structure must be built into the contractual and oversight relationship before the work begins. Once the hardware has moved, the opportunity to verify and correct has closed.

The 2019 recurrence is the detail that makes this case instructive. An organization that treats a third-party failure as an isolated operational incident implements process corrections for that situation. An organization that treats it as an accountability signal asks why the governance structure that should have surfaced the 2016 failure did not prevent a structurally identical failure three years later. That recurrence is exactly the kind of signal a mature risk program should be capable of surfacing through its register, remediation history, and governance records.

What the Register Is Actually Telling You

Equifax shows accountability failing at ownership. Capital One shows it failing through escalation and oversight. Morgan Stanley shows it becoming diffuse across an organizational boundary. Those are not three famous breach examples inserted into an article for credibility. They are three different failure modes of the same accountability problem.

The pattern appears across institutional settings at every scale. Risk existed. Documentation existed. Some form of governance structure existed. The failure appeared in the space between what the documentation recorded and what the accountability structure produced.

When risks age without resolution, the entries worth examining share recognizable characteristics. Ownership is contested. Remediation crosses a budget boundary the named owner does not control. Carrying the risk is organizationally easier than building the business case to address it. Those entries demonstrate that the register is doing exactly what it should: exposing where governance is breaking down. The problem is treating it as the output when it is the input to a harder conversation about whether the accountability structure behind each entry is functional.

Most organizations analyze the contents of the register. Mature organizations also analyze the behavior of the register itself. Ownership churn, remediation-date movement, aging by business unit, repeat exceptions, risk acceptance decisions without expiration dates, dependencies repeatedly blocking closure, escalations that produced no documented decision: these are not additional risk scores. They are signals about the organization’s capacity to govern risk. That behavioral layer sits inside every risk register that has been running long enough to accumulate history.

A mature organization manages the risks in its register and the behavior of the register itself.

Read the Register Like an Organizational Psychologist

The next time your risk committee reviews the register, resist the temptation to start with severity scores. Ask different questions instead.

Which risks have changed owners repeatedly? Which remediation dates move every quarter? Which accepted risks have no expiration date? Which third-party risks have remained open across multiple contract renewals? Which business units consistently close findings, and which accumulate them? Which escalations resulted in documented decisions, and which disappeared into governance meetings?

Those patterns reveal something likelihood and impact scores cannot. They reveal how your organization makes decisions under pressure.

Every material risk needs a named individual with enough authority to drive treatment, escalate barriers, or obtain a decision from someone who can. Accountability is not ownership alone. It is ownership combined with authority, decision rights, and a consequence structure that makes inaction visible. Organizations that address the recommendation by putting names into a spreadsheet have not solved the problem. They have created a new entry for the accountability register.

Risk acceptance decisions need a named executive, a documented rationale, and an expiration date. Escalation paths need defined triggers so that aging past a threshold produces a mandatory governance response, not a calendar reminder. Third-party risk entries need an internal owner who remains accountable for oversight regardless of which vendor performs the work.

Organizations that learn to read accountability patterns earlier make better remediation decisions, allocate resources more effectively, escalate the right problems sooner, and reduce the number of risks that become long-lived exceptions.

If you find yourself debating whether a risk is High or Critical while no one can identify who owns the next action, you have already learned something more important than the score. You have found an accountability problem. Fix that first.

Organizations rarely lose control of risk because they failed to identify it. They lose control because awareness never became accountability, accountability never became action, and action never became governance.

A risk register tells you what could go wrong. Its history tells you whether your organization knows how to respond once it does.

About the Author

Kimly Hong is a Principal Cybersecurity and GRC Consultant with more than ten years of experience building enterprise security programs across regulated financial services, hospitality, and technology environments. Her work spans governance, risk, and compliance program design, third-party risk management, access governance, and incident response readiness. She has built these programs from the ground up across complex, multi-region environments and currently consults across financial services, SaaS, and retail organizations. Connect on LinkedIn to continue the conversation.

Kimly Hong

Kimly Hong, MBA,CSM is an accomplished cybersecurity program manager with expertise in the adoption and implementation of cybersecurity frameworks, risk management, and compliance. She has led security initiatives for Fortune 500 companies and global enterprises, overseeing security awareness programs and regulatory compliance strategies. Her leadership and hands-on approach make her a trusted partner in navigating complex cybersecurity challenges. She holds degrees from Bryant University and Husson University. Connect with her on LinkedIn.

Share Post :

Newslater

Get Our Latest Updated

Lorem ipsum dolor sit amet consectetur adipiscing elit.

Scroll to Top