From Assessment to Accountability: A Risk Register That Actually Works

Organizations invest enormous effort in Security Assessment & Authorization. Controls are assessed, evidence is collected, findings are documented, residual risks are rated, and an authorization decision gets signed. Then, six months later, the same organizations struggle to answer five basic questions: Which risks are still open? Who is accountable for each one? What treatment is underway? Which risks were accepted, and by whom? Which need executive attention?

The problem is not the assessment. The problem is what happens after it — risks get buried in reports, spreadsheets and SharePoint folders — each one a competing version of the truth, each tracking remediation its own way — and quietly fade from view. The fix is a distinction simple enough to fit on one line:

Assessments identify risk. The risk register manages it.

That distinction — and the ownership model that makes it work — is how risk management works in CtrlFort.

Assessments Identify Risk — the Register Manages It#

An assessment answers what is the state of risk today: it evaluates control effectiveness, validates evidence, produces findings, and rates the residual risk that remains — the pipeline we walked in our residual risk model. It is deliberately a snapshot.

A register answers a different question — what risks are we actively managing? — and it never stops being updated: it tracks risks over time, assigns accountability, monitors treatment, records acceptance, and gives leadership a live view. It stays relevant for the life of the system, long after the report that found the risk has been filed.

Scroll sideways to see the full diagram →

This is not a distinction we invented. NIST's guidance on integrating cybersecurity into enterprise risk management is built around exactly this artifact:

[A risk register is] a repository of risk information including the data understood about risks over time. Typically, a risk register contains a description of the risk, the impact if the risk should occur, the probability of its occurrence, mitigation strategies, risk owners, and a ranking to identify higher priority risks.

NIST IR 8286 Rev. 1 — quoting OMB Circular A-11

The GC picture is consistent, with one telling gap. ITSP.10.033 requires organizations to respond to assessment findings in line with risk tolerance (RA-07, Risk response) and to track planned remediation in a plan of action and milestones (CA-05)³ — but the phrase "risk register" appears nowhere in the catalogue, or in ITSG-33. The register comes from the enterprise risk management side of the house: TBS's integrated risk management guidance names risk registers as a standard mechanism for communicating risk across a department, alongside the Corporate Risk Profile.⁶ The POA&M tracks one assessment's remediation; the register is where the organization's risks live.

Risks Come from More Than Assessments#

Many GRC platforms couple risk management tightly to assessments. In practice, risks originate everywhere: SA&As, Threat and Risk Assessments, Privacy Impact Assessments, Business Impact Analyses, architecture reviews, audits, security incidents, exception requests, project and management reviews — increasingly, AI-assisted analysis too.

An SA&A is one producer of risk information among many. The register is the authoritative repository that manages all of it, regardless of source — which is precisely the role NIST IR 8286 assigns it: "a formal communication vehicle for sharing and coordinating cybersecurity risk activities as an input to ERM decision makers."¹

The Ownership Model#

The most common cause of failed risk management is not bad ratings — it is unclear ownership. Organizations routinely blur three different responsibilities: being accountable for a risk, remediating a control, and approving acceptance. These belong to different roles, assigned separately.

Scroll sideways to see the full diagram →

The System Owner — owns the risk#

The System Owner is accountable for the business operation of a system or service — an Azure landing zone, an enterprise Kubernetes platform, a case management application, a Microsoft 365 environment. Typical owners: a Director of Cloud Services, a Manager of Platform Engineering, a Director of Business Applications. NIST SP 800-37 notes organizations may equally call this role a program manager or business/asset owner.²

The System Owner owns the business impact of a risk. They do not necessarily implement a single technical control — that is the next role's job.

The Control Owner — owns the control#

A Control Owner is responsible for implementing and maintaining a specific control: AC-02 account management, IA-02 identification and authentication (organizational users), AU-06 audit record review, analysis, and reporting, SC-07 boundary protection.³ Typical roles: IAM Manager, SOC Manager, Network Security Manager, Cloud Security Lead.

The Control Owner maintains the control, provides assessment evidence, participates in interviews, and leads remediation when the control falls short.

The Risk Approver — accepts what remains#

The Risk Approver is the executive empowered to formally accept a risk on behalf of the organization — required for significant risks and formal acceptance, optional for the routine ones the Business Risk Owner can manage alone. For authorization-driven risks this is the Authorizing Official; depending on the risk, it may instead be a CISO, CIO, Director General or executive sponsor. On the authorization path, NIST is unambiguous about how concentrated the responsibility is:

The authorizing official is the only organizational official who can accept the security and privacy risk to organizational operations, organizational assets, and individuals.

NIST SP 800-37 Rev. 2 — Appendix D

And it is non-delegable: the one activity an AO cannot hand to a designated representative is the authorization decision itself — the acceptance of risk.² ITSG-33 frames authorization the same way: an "official management decision by a senior organizational official" to explicitly accept the risk of relying on the system.⁵

Assign Ownership Early — and by Role#

The common mistake is assigning ownership at the end, when the report is being written and nobody wants their name on page 40. Ownership should be captured at the start:

1. Assessment planningCapture the System Owner and Authorizing Official (and Solution Owner, if any)
2. Control tailoringAssign a Control Owner to every selected control
3. Evidence collectionOwners already know what they are answering for
4. Risk determinationRated risks arrive with their accountability attached

And whenever possible, ownership should attach to a role, with an individual assigned beneath it:

Solutions, Systems, and Hierarchy#

Modern delivery rarely involves a single system. A Public Safety Case Management solution may span a case management application, an Azure landing zone, an AKS platform, Entra ID and a SIEM — five systems delivering one business capability. The ownership model has to follow that shape:

1. SolutionOne business capability — Solution Owner
2. SystemsPlatforms and applications — System Owners
3. ControlsSelected and tailored — Control Owners
4. FindingsPartially Met / Not Met, with evidence
5. RisksRated, promoted, and owned in the register

Where multiple systems deliver one capability, a Solution Owner — say, a Director General of Digital Transformation — provides enterprise-level accountability for risks that span systems. The assignment rules then become mechanical:

Two examples make the difference concrete. AKS administrators do not enforce MFA affects one platform: the Manager of Platform Engineering owns the risk, the IAM Manager owns the fix, the AO approves what is accepted. Enterprise identity service compromise threatens AKS, Azure, the applications and Microsoft 365 at once: accountability moves up to the Solution Owner — one named executive, not a working group — while the Identity Services Manager holds the Technical Owner role and the AO still approves what is accepted.

When a Risk Enters the Register#

Not every finding deserves a register entry, and a register full of trivia is how the important rows get ignored. The criterion is one sentence: if the organization must actively monitor or manage the risk, it belongs in the register. In practice that means residual risks rated Medium and above on the model's five-level scale, every accepted risk, everything with a remediation plan, and anything requiring executive visibility. Low and Very Low risks are usually managed through normal operations — recorded in the assessment, not promoted.

Accepted risks earn special emphasis: acceptance is a decision, not an archive event. An accepted risk stays in the register with its approver, rationale and review date, because the conditions under which it was accepted — the threat environment, the compensating controls, the business context — do not hold still.

What the Register Holds#

The temptation in any GRC platform is to capture everything. The better test is: does this field support a decision? CtrlFort's register splits the schema in two — a small required core every risk must carry, and optional depth added only where management needs it — and the result maps closely onto the template NIST IR 8286 recommends:¹

The treatment options are the catalogue's own: ITSP.10.033's RA-07 names mitigating, accepting with justification, sharing or transferring, and avoiding as the responses available once a finding is rated.³ Traceability, meanwhile, comes from structure rather than data entry: a risk promoted from an SA&A arrives linked to the assessment, finding and control that produced it, which is the difference between a risk statement and a rumour. For the deeper record — assumptions, decision history, indicators — NIST IR 8286 describes a risk detail record behind each register row, and notes it may live in a GRC application.¹

The Lifecycle — and a Defined Path to Closure#

A register only stays trustworthy if risks move through it under discipline. CtrlFort keeps the lifecycle to four stages:

1. OpenIdentified and entered in the register
2. In ProgressTreatment actively underway — say, Conditional Access policies being deployed
3. Accepted or MitigatedThe treatment decision, made by the accountable owner
4. ClosedOngoing management is no longer required

Two rules give the lifecycle its teeth. First, accepted risks remain active and visible — a legacy application that cannot support MFA, accepted until replacement, stays on the register in plain view rather than disappearing into a decision log. Second, closure is earned, not declared: a risk closes only when ongoing management is genuinely no longer required, through a deliberate gate —

1. Treatment complete?The plan actually finished, not merely scheduled
2. Evidence available?Proof the fix exists and operates
3. Business Risk Owner reviewThe accountable owner examines the evidence
4. Approved — or reopenedClosed with a reason, or sent back for more work

Every closure records a reason from a controlled list — remediated, system decommissioned, duplicate, merged with another risk, entered in error, or a documented other — along with the closure date and who closed it, ideally with the supporting evidence attached. And approval scales with severity: the Business Risk Owner can close Medium and Low risks on their own authority, while High and Very High risks need the Risk Approver's sign-off as well. A register whose closures are reasoned, dated, evidenced and signed is one an auditor can trust — and one a risk cannot quietly slip out of.

The One-Owner Rule#

If a single principle governs the CtrlFort register, it is this: every risk has exactly one accountable Business Risk Owner. Not a team. Not multiple people. Not shared ownership. One name.

The Technical Owner may drive remediation. The Authorizing Official may approve acceptance. But accountability for managing the risk belongs to a single business owner — which is also where TBS lands, directing organizations toward "specifying appropriate risk owners that have the accountability and authority to manage risks," backed by governance structures that support them.⁶ The chain runs all the way up: under the Framework for the Management of Risk, Deputy Heads are ultimately accountable for risk management in their organizations⁷ — an accountability that is only real if every risk beneath them resolves to a name.

How CtrlFort Runs It#

Everything above works on paper and in spreadsheets — until scale, staff turnover and quarterly cycles erode it. CtrlFort's register holds the model in place. Risks arrive from five sources, and every one of them produces the same Risk object, so the register never fragments by origin:

The creation rules stay short enough to memorize: any authorized user can raise a Manual risk; SA&A residual risks are promoted directly — rated by the deterministic model, and promotion carries the rating, rationale, finding, control and system links across, so nothing is retyped and nothing drifts; SOC, vulnerability and patch teams create risks when something needs ongoing management rather than a ticket; and every risk, whatever its source, gets exactly one Business Risk Owner. The matrix above supplies the default owners at creation — consistent by construction, and always correctable by a human where context demands it.

Two more properties come from the platform rather than the process. Traceability is structural: because assessments, findings, controls, systems and risks are linked objects in the assessment intelligence architecture, the walk from a register row back to source evidence is a click, not an archaeology project. And accountability stays human: the platform supplies defaults and records review dates so stale acceptances stay visible — but treatment decisions, acceptances and closures are made and signed by the people who hold the roles. Automation reduces the administrative overhead of governance; it does not become the governor.

Final Thoughts#

A risk register should be more than a list of risks. It is the operational bridge between assessment and remediation, findings and decisions, authorization and governance — between security work and business accountability. The ingredients are unglamorous and decisive: separate identification from management, assign ownership early and by role, resolve every risk to one accountable owner, and keep the trail from register row back to evidence unbroken.

Move the organization from documenting risk to managing it. That is where real risk management begins.

Frequently Asked Questions#

What is the difference between a POA&M and a risk register?#

Scope and lifespan. The plan of action and milestones (CA-05) is an assessment artifact: scoped to one system, driven by that assessment's findings, focused on remediation, and largely done when the milestones are. The register is organization-wide, takes risks from every source, records acceptance as well as remediation, and lives for as long as the risks do. The POA&M feeds the register; it does not replace it.

Do accepted risks stay in the register?#

Yes — permanently, until conditions change. Acceptance is a decision made under specific conditions: a threat environment, a set of compensating controls, a business context. The register keeps the acceptance with its approver, rationale and a review date, so that when the conditions move — a new campaign, a decommissioned safeguard, a reauthorization — the acceptance is re-examined rather than rediscovered.

Who owns the risk when the control belongs to another organization?#

The accountability does not travel with the control. If a shared-service provider runs the identity platform, their manager is the Technical Owner — but the Business Risk Owner remains the owner of the system or solution that bears the impact, because it is their service that goes down and their data that leaks. The split gets documented in the arrangement between the parties; what must never happen is the risk falling into the gap between them.

How many risks should a register hold?#

As many as the organization is genuinely managing — and no more. A useful smell test: if a majority of rows have not changed status, owner or review date in two cycles, the register has become an archive with a hopeful name. Keep Low-rated risks in the assessment record, promote what needs management, and close what is done.

What does the Authorizing Official actually do between authorizations?#

Under NIST SP 800-37, the AO is the only official who can accept security and privacy risk, and that acceptance cannot be delegated. Between authorization decisions, the register is what makes the responsibility continuous rather than ceremonial: it shows the AO the current risk posture, the acceptances approaching review, and the new risks queued for a decision — so the next authorization is a checkpoint, not a surprise.

Is the "authorizer" in ITSG-33 the same as NIST's "authorizing official"?#

Functionally, yes. ITSG-33 says the authorizer "assumes responsibility for relying on the information system and therefore accepts the risks associated with doing so"; SP 800-37's authorizing official is the only official who can accept such risk. The vocabulary differs, the accountability is the same — a GC program can use either label as long as exactly one senior official holds it.

References#

1. NIST IR 8286 Rev. 1 — Integrating Cybersecurity and Enterprise Risk Management (ERM) ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/ir/8286/r1/final
2. NIST SP 800-37 Rev. 2 — Risk Management Framework for Information Systems and Organizations ↩National Institute of Standards and Technology · https://csrc.nist.gov/pubs/sp/800/37/r2/final
3. ITSP.10.033 — Security and privacy controls and assurance activities catalogue ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033
4. Annex 2 — Information system security risk management activities (ITSG-33) ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-2-information-system-security-risk-management-activities-itsg-33
5. Annex 5 — Glossary (ITSG-33) ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-5-glossary-itsg-33
6. Guide to Integrated Risk Management ↩Treasury Board of Canada Secretariat · https://www.canada.ca/en/treasury-board-secretariat/corporate/risk-management/guide-integrated-risk-management.html
7. Framework for the Management of Risk ↩Treasury Board of Canada Secretariat · https://www.tbs-sct.canada.ca/pol/doc-eng.aspx?id=19422