Marcus Webb found out what an unowned risk costs on a Tuesday afternoon, three weeks before Larkspur Health Analytics' Stage 2 certification audit.
Marcus was the newly hired Head of Information Security at Larkspur, a 210-person healthtech company that processed claims data for regional insurers. Eighteen months earlier, during the initial risk assessment, someone had logged a risk called "unauthorized access via third-party API integrations" in the register. It had a plausible likelihood score, a plausible impact score, and a treatment plan that said, sensibly enough, "restrict and monitor API keys issued to integration partners." What it didn't have was a name next to "risk owner." The field said "IT / Security."
Nobody had pushed back on that at the time. It sounded like security's job — security teams manage keys, don't they? But "IT / Security" isn't a person. It isn't even a role with budget authority over the sixty-some third-party integrations Larkspur's product team had signed up in the two years since. The engineering director who actually controlled which partners got API access, what scopes those keys carried, and whether an integration got decommissioned when a partner's contract lapsed, had never been told he owned anything. He'd never seen the risk register. He'd never approved a treatment plan. He'd never been asked to accept — or reject — the residual risk.
In March, a mid-sized benefits administrator that Larkspur had stopped actively supporting eight months earlier still had a live API key with read access to claims records. Nobody had revoked it because revoking it wasn't on anyone's task list; the risk owner field said "IT / Security," and IT / Security had eleven other fires that quarter. The key leaked in a phishing incident at the partner's shop, and for six days an outside party had a working credential into Larkspur's claims API. Forensics, breach counsel, notification to 14,000 affected members, a renegotiated contract with the health plan that had been most exposed, and the three weeks Marcus spent rebuilding the risk register instead of preparing for audit: the incident cleared $340,000 before Larkspur's leadership stopped counting the soft costs.
The control gap wasn't the failure. Larkspur actually had a reasonable idea, on paper, of what needed to happen. The failure was that no accountable human being had the authority, the visibility, or the obligation to make it happen — and nobody had checked, until an auditor or an attacker eventually would.
This is the single most common way that ISO 27001 risk assessments fail in practice, and it rarely shows up as a missing document. It shows up as a name in a spreadsheet cell that describes a department instead of a person — or a name that belongs to someone who has responsibility for nothing more than writing the risk down.
Who this is for
This article is for the person building or fixing an ISO 27001 risk assessment process — a CISO, ISMS manager, GRC lead, or consultant — who has watched a risk owner field get filled in with a job title, a department, or "TBD" and knows that isn't going to survive an internal audit, let alone Stage 2. You'll walk away with a precise definition of what a risk owner is under Clause 6.1.2(c) and 6.1.3(f), a working distinction between risk owners, control owners, and action owners, a method for assigning ownership that doesn't default to "the CISO owns it," a RACI model you can adapt, and a governance rhythm that makes accountability real instead of decorative.
What Is a Risk Owner, Precisely?
ISO/IEC 27001:2022 uses the term "risk owner" in a specific, narrow way, and getting it right matters more than most organizations assume. Clause 6.1.2(c) requires that the risk assessment process "identify the risk owners" as part of identifying information security risks. Clause 6.1.3(f) goes further: it requires the organization to obtain risk owners' approval of the risk treatment plan and their acceptance of the residual risks.
Read those two requirements together and a definition falls out cleanly. A risk owner is a person — not a team, not a department, not a job function in the abstract — who has both:
Accountability for the risk: the outcome, good or bad, is attributed to them, and they cannot delegate that attribution away.
Authority to manage the risk: they can direct resources, approve or reject a treatment plan, accept residual exposure on the organization's behalf, and be reasonably expected to answer for that decision to leadership or an auditor.
Accountability without authority produces exactly what happened at Larkspur: a name that exists to be blamed but that had no actual lever to pull. Authority without accountability produces the opposite failure — someone who could act, but who nobody expects to, and who therefore doesn't. ISO 27001 requires both in the same person, which is precisely why the standard's authors chose the word "owner" instead of something softer like "responsible party" or "contact."
A useful gut check: if you can't complete the sentence "if this risk materializes, [name] will be asked why the treatment plan wasn't sufficient, and [name] is the one who could have said no to the risk in the first place," you haven't identified a risk owner. You've identified an interested bystander.
It's also worth being honest that ISO 27001 does not mandate that the risk owner be a security professional. In fact, in a mature ISMS, the risk owner is usually not from the security team. Risk owners are typically business or system owners — the person who runs the process, owns the budget, or is accountable for the asset the risk touches. Security's role is to facilitate the assessment, present options, and make sure the decision gets documented — not to be the default owner of every risk in the register. We come back to why that distinction matters in the section on the CISO-owns-everything anti-pattern below.
The standard itself doesn't define "control owner" or "action owner" as formal terms — those are practitioner vocabulary that has grown up around implementation, and you'll see them used slightly differently across consultancies. But the underlying distinction is real, it maps cleanly onto how auditors probe accountability, and conflating the three roles is exactly what produced Larkspur's six-day exposure window. It's worth defining all three precisely before you touch a RACI chart.
Risk Owner vs. Control Owner vs. Action Owner
Risk owner is the accountable decision-maker described above: the person who accepts or rejects residual risk and answers for that call.
Control owner is the person or role responsible for the ongoing operation of a specific safeguard — the Annex A control, or the combination of controls, that treats the risk. A control owner keeps a control running day to day: they own the firewall ruleset, the access review cadence, the encryption standard, the awareness training program. A single risk is often treated by several controls, each with its own control owner, all reporting up to one risk owner.
Action owner (sometimes called a "task owner" or "treatment action owner") is the person assigned a specific, time-bound implementation task inside a risk treatment plan — "migrate the legacy VPN to the new IdP by March 31," "complete the vendor's SOC 2 review by Q2." Action owners close out discrete to-do items. Once the action is done, the action owner's involvement typically ends; the control owner's does not, because the control needs to keep operating; and the risk owner's never ends, because they own the risk for as long as it exists in the register.
Using Larkspur's incident as the worked example:
Role | Who it was (or should have been) | What they were accountable for | What went wrong at Larkspur |
|---|---|---|---|
Risk owner | VP of Partner Integrations (should have been named; register said "IT / Security") | Deciding whether the residual exposure from third-party API access was acceptable; approving the treatment plan; answering for the decision | No named person — the role defaulted to a department, so no one felt the accountability |
Control owner | Identity and Access Management lead | Operating the key-issuance and key-revocation process; keeping the API gateway's access rules current | The process existed on paper but had no trigger tied to partner offboarding |
Action owner | Integrations engineer assigned the Q3 ticket "audit dormant partner API keys" | Completing a specific one-time cleanup task | The ticket was never created because no risk owner ever reviewed the treatment plan and demanded it |
That table is the entire failure in miniature: three different jobs, one person needed for each, zero people actually assigned. A mature ISMS keeps these roles distinct on paper even when, in a small organization, the same human sometimes fills two of them — which is a legitimate and common shortcut we'll cover later, but it should be a deliberate choice, not a default born of nobody asking the question.
Dimension | Risk Owner | Control Owner | Action Owner |
|---|---|---|---|
ISO 27001 clause basis | 6.1.2(c), 6.1.3(f) | Implied by control implementation (Clause 8, Annex A) | Implied by treatment plan execution (Clause 6.1.3, 8.3) |
Time horizon | Life of the risk (ongoing) | Life of the control (ongoing) | Duration of a single task (finite) |
Typical seniority | Business/process/system owner, department head, or executive | Team lead, engineering manager, IT operations | Individual contributor or analyst |
Core decision made | Accept, reduce, transfer, or avoid the risk; sign off on residual exposure | How the control is configured and operated day-to-day | None — executes an assigned task to completion |
What an auditor asks them | "Why is this residual risk acceptable to the business?" | "Show me evidence this control operated as designed this quarter." | "Show me this ticket is closed and the evidence attached." |
Failure mode if missing | Nobody can legitimately accept residual risk — audit nonconformity against 6.1.3(f) | Control decays silently; nobody notices drift | Treatment plan tasks stall indefinitely with no one to chase |
"The question I ask in every internal audit interview is the same: 'If this risk showed up on the front page tomorrow, whose name is in the box, and could they actually have stopped it?' Half the time the person in the box is the CISO, and the CISO didn't control the budget, the vendor relationship, or the business decision that created the exposure in the first place. That's not a risk owner. That's a scapegoat with a job title." — Priya Nandakumar, Director of Internal Audit, Council Bluffs Financial Group
The distinction matters most at the moment of residual risk acceptance. Clause 6.1.3(f) doesn't ask control owners or action owners to accept anything — it asks the risk owner, specifically, because acceptance is a business judgment about tolerable exposure, not a technical judgment about whether a control works. Confusing the two roles is how organizations end up with a security engineer "accepting" a risk they have no authority to accept on the company's behalf — a nonconformity waiting to be found.
Mapping the Accountability Chain
The relationship between the three roles, and where escalation goes when something breaks, is easiest to see as a flow rather than a table.
flowchart TD
A[Risk identified in risk assessment<br/>Clause 6.1.2c] --> B{Risk owner assigned<br/>by name, not department}
B --> C[Risk owner reviews options<br/>with security/GRC facilitation]
C --> D[Risk owner approves<br/>Risk Treatment Plan — 6.1.3f]
D --> E[Control owner(s) implement<br/>and operate safeguards]
D --> F[Action owner(s) complete<br/>specific treatment tasks]
E --> G{Control operating<br/>as designed?}
F --> H{Task completed<br/>on schedule?}
G -- No, control gap found --> I[Escalate to risk owner:<br/>re-assess residual risk]
H -- No, task overdue --> I
G -- Yes --> J[Residual risk accepted<br/>and documented by risk owner]
H -- Yes --> J
I --> K{Risk owner unavailable<br/>or unresponsive?}
K -- Yes --> L[Escalate to management review<br/>Clause 9.3 / ISMS steering committee]
K -- No --> D
J --> M[Logged in risk register<br/>with owner sign-off and date]The chain has exactly one node where the standard requires a named individual to make a judgment call: the risk owner box. Everything upstream (identification, analysis) is a process; everything downstream (implementation, monitoring) is delegated execution. The escalation path matters as much as the assignment — an owner who goes silent for two review cycles needs a defined route to management review, not an indefinite pause. We'll return to that escalation path when we cover holding owners accountable.
How to Assign Risk Owners Correctly
The practical question every ISMS manager eventually asks is "how do I actually decide who owns this?" The honest answer is: follow the authority, not the org chart, and definitely not the alphabet. The right owner is whoever already has the standing authority to make the trade-off the risk represents — spending money, changing a process, accepting a customer's displeasure, or telling a vendor no. If you have to invent authority for someone by giving them a new title, you've picked the wrong owner or you need to fix the actual decision rights first.
A pattern that works across most of the 200-plus organizations I've assessed is to assign ownership by the nature of the asset or process the risk attaches to, not by the type of threat. A ransomware risk against the finance system is owned by the finance systems owner, not by "the ransomware risk owner" — there's no such role, because ransomware is a threat vector, not an asset.
Risk category (example) | Typical correct risk owner | Why | Common wrong-owner default |
|---|---|---|---|
Risk to a specific business application (e.g., billing system) | Application/system business owner (often a department VP or director) | They control the budget, the roadmap, and the acceptable-downtime tolerance | IT operations manager (has authority over infra, not the business trade-off) |
Risk in a third-party/vendor relationship | Vendor relationship owner / procurement or business sponsor of that contract | They control renewal, scope, and contractual leverage | Security team (has no authority over the contract) |
Risk tied to a physical facility | Facilities manager or site director | They control physical access, budget for physical controls | Security team (rarely controls facilities budget) |
Risk tied to a business process (e.g., payroll, claims processing) | Process owner (department head running that process) | They understand acceptable disruption and can reprioritize staff | Whoever raised the risk during the workshop |
Risk tied to a shared platform (e.g., core network, identity provider) | IT/infrastructure director, or CTO for enterprise-wide platforms | Platform decisions genuinely sit with IT leadership here | An individual engineer with no budget authority |
Risk tied to regulatory/legal exposure (e.g., data residency) | General Counsel or Chief Compliance Officer | They own the legal risk tolerance and reporting obligations | Security team (advises, doesn't own the legal call) |
Enterprise-wide/strategic risk (e.g., overall cyber insurance posture) | CEO, COO, or a designated executive sponsor | The trade-off is a whole-of-business decision | Left unassigned as "the board" — too diffuse to be a person |
Two things to notice in that table. First, the security or GRC function almost never shows up as the correct owner — it shows up as facilitator, advisor, and secretariat for the decision, which is a different and equally important job. Second, "whoever raised the risk during the workshop" is a real anti-pattern: it's tempting to make the loudest voice in the risk assessment session the owner by default, but raising a concern and being accountable for managing it are different skills and often different people.
When you genuinely cannot map a risk to an existing role with real authority — which does happen, especially for novel risks like AI-model supply-chain exposure — that's a signal the organization has a gap in its accountability structure itself, not just its risk register. The fix in that case is to raise it to the ISMS steering committee or management review and get an owner designated, even if it means creating or reassigning a role, rather than leaving the field blank or defaulting to security.
The CISO-Owns-Everything Anti-Pattern
I want to spend real space on this because it's the single most common finding I write up in gap assessments, and it's almost always well-intentioned. A new CISO or ISMS manager inherits a risk register with forty open risks and forty blank owner fields. Under deadline pressure to close the gap before an audit, they do the fast thing: they put their own name in every box. The register looks complete. The auditor sees names, not blanks, and — if the auditor is inexperienced or rushed — might even accept it.
A good auditor won't. And more importantly, the organization shouldn't want them to, because CISO-owns-everything defeats the entire purpose of naming an owner. Here's what breaks:
Authority mismatch. The CISO typically cannot authorize a $2 million infrastructure replacement, unilaterally change a sales process, or decide a vendor relationship is worth the residual risk. When the CISO "accepts" that risk, it isn't really accepted by anyone with the standing to make the call — it's accepted on paper only.
Single point of failure. Forty or eighty risks funneled through one person's calendar means residual-risk review becomes a rubber stamp exercise done in bulk, once a year, rather than a considered judgment tied to how the business actually changed.
Perverse incentive for the auditor's next visit. Once an auditor notices the CISO owns 90% of the register, the natural follow-up question is "then who in the business actually decided this was acceptable?" If the answer is "nobody, really," that's a direct nonconformity against 6.1.3(f), not a stylistic quibble.
It quietly re-centralizes risk in security, which is exactly backwards. Information security risk is business risk that happens to route through technology. Treating it as security's risk to own reinforces the (wrong) idea that security is solely responsible for outcomes the rest of the business creates and controls.
"I inherited a risk register where I 'owned' sixty-one risks. I didn't control sixty-one budgets. I didn't control sixty-one departments. What I actually did was spend eighteen months reassigning ownership to the people who already had the authority, and our next audit cycle went from twelve findings to two." — Marcus Webb, Head of Information Security, Larkspur Health Analytics
The fix is not complicated, but it does take deliberate work: for every risk currently owned by security, ask "who in the business would have to approve spending money, changing a process, or accepting customer impact to treat this?" That person is the real owner. Reassigning takes a conversation and, often, an executive sponsor's nudge — but it's the single highest-leverage cleanup activity available to an ISMS manager inheriting a messy register. Our companion piece on the ISO 27001 risk assessment methodology covers where in the assessment workflow ownership should be assigned — ideally during risk identification, not bolted on afterward.
What a Risk Owner Is Actually Responsible For
Naming an owner is step one. The next mistake I see is treating the role as a one-time signature rather than an ongoing obligation, and nowhere is that more visible than in how an owner engages with the risk treatment plan itself — a document that exists specifically to capture their approval, not just the security team's proposed fix. A risk owner under ISO 27001 has four distinct responsibilities, and an internal audit interview script worth its salt will probe all four separately.
Responsibility | What it means in practice | Clause basis | Evidence an auditor will ask for |
|---|---|---|---|
Review the risk assessment | Confirm the likelihood/impact rating and the risk description reflect current reality, not a stale workshop from two years ago | 6.1.2 | Dated sign-off or comment trail on the risk register entry |
Approve the risk treatment plan | Formally agree that the proposed controls and actions are the right response — or send it back with changes | 6.1.3(f) | Signed/approved RTP with owner name and date |
Accept residual risk | Explicitly state that the risk remaining after treatment is within the organization's risk acceptance criteria | 6.1.3(f), tied to risk acceptance criteria | Documented acceptance statement, ideally referencing the defined criteria, not just a verbal "sounds fine" |
Monitor and re-evaluate | Watch for changes that alter the risk (new threat, new asset, control failure, business change) and trigger a re-assessment | 6.1.3, reinforced by Clause 9.1 monitoring | Evidence of periodic review — calendar invite, register update log, or management review minutes |
Two of those four are frequently skipped even in organizations that get the assignment right. "Review the risk assessment" often happens once, at intake, and never again — so a risk owner ends up accountable for a risk rating that's three reorganizations and one cloud migration out of date. "Monitor and re-evaluate" is the one that turns risk ownership from a paperwork exercise into genuine risk management; it's also the one that's hardest to evidence, because it's ongoing rather than a discrete artifact. The practical fix, covered in the governance section below, is to tie monitoring to a fixed calendar cadence rather than leaving it to the owner's initiative.
It's worth being explicit about what a risk owner is not responsible for, because over-scoping the role is almost as damaging as under-scoping it. A risk owner is not expected to personally implement controls, write procedures, run vulnerability scans, or manage day-to-day security operations — that's the control owner's job. Nor are they expected to have deep technical security expertise; they're expected to understand the business impact well enough to make an informed accept/reject decision, with security or GRC providing the technical translation. Demanding that every risk owner become a security expert is how organizations talk themselves back into the CISO-owns-everything trap, because "well, only security really understands this" becomes the excuse for reassigning ownership away from the business.
A Worked RACI Example
RACI charts (Responsible, Accountable, Consulted, Informed) map naturally onto the risk owner / control owner / action owner distinction, and building one is the fastest way to force clarity in a workshop setting. Below is a worked example for a single risk — "unpatched critical vulnerability on an internet-facing application server" — walked through its full lifecycle. Note there is exactly one "A" in every row: that's not a stylistic choice, it's the entire point of a RACI.
Activity | Risk Owner (App Business Owner) | Control Owner (Infrastructure Manager) | Action Owner (Patching Engineer) | Security/GRC Function | Executive Sponsor |
|---|---|---|---|---|---|
Identify and rate the risk | C | C | I | R | I |
Decide treatment approach (patch cadence, compensating controls) | A | R | C | C | I |
Approve the risk treatment plan | A | R | I | C | I |
Execute the patch within SLA | I | A | R | I | – |
Verify patch applied and effective | I | A | R | C | – |
Accept residual risk if full remediation isn't possible by deadline | A | C | I | C | I |
Monitor for recurrence / re-scan | I | A | R | C | – |
Report status at governance review | A | R | I | R | I |
Reading the "Accept residual risk" row is the clearest illustration of why this matters: the app business owner — not the infrastructure manager who actually operates the patching tooling, and not the security function that flagged the vulnerability — is the one who signs off that shipping late, or shipping with a compensating control instead of the patch, is acceptable. That's a judgment about business risk tolerance, and RACI forces the organization to admit whose judgment it actually is.
"We didn't have a real accountability problem until we tried to build the RACI. Everyone assumed someone else was the 'A' on residual risk acceptance. Once we forced a single accountable name into every row, three risks that had been sitting 'in progress' for over a year got resolved in six weeks, because someone finally owned the decision to say yes or no." — Elena Vasquez, Head of GRC, NorthPeak Insurance Group
Building this out for every risk in a register of a hundred-plus entries is more effort than most organizations will sustain line by line, and it doesn't need to be — a useful shortcut is to build the RACI once per risk category or asset type (matching the categories in the assignment table above), then apply the category-level RACI to each specific risk instance during intake. The risk register itself should carry, at minimum, the risk owner's name and the date of their last review as standing fields — the fuller RACI can live in a linked governance document rather than cluttering every register row.
Holding Owners Accountable: Governance, Reporting, and Escalation
Assigning ownership is the easy half. The harder, and more auditable, half is building a governance rhythm that makes accountability real rather than aspirational — because a risk owner who is never asked to report on their risk is functionally the same as no risk owner at all.
Three structural elements make this work in practice:
A standing reporting cadence. Every risk owner should know, in advance, when they'll be asked to report status — not be surprised by an email the week before an audit. Most organizations I've worked with settle on a tiered cadence: high and critical risks reviewed quarterly at minimum, sometimes monthly for anything tied to an active treatment plan with a deadline; medium risks reviewed at the standard semi-annual or annual risk assessment cycle; low risks reviewed annually unless something changes. The cadence itself should be documented in the risk management procedure, not left to individual owners' discretion.
A defined escalation path for unresponsive or absent owners. People change roles, leave the organization, or simply deprioritize a request that isn't urgent to them. The ISMS needs a documented answer to "what happens when a risk owner doesn't respond for two consecutive review cycles?" — typically escalation to that owner's manager, then to the ISMS steering committee or management review under Clause 9.3, with a hard deadline before the risk is flagged as a standing nonconformity risk in its own right. Leaving this undefined is how risks quietly age past their next review date with nobody accountable for the silence.
Visible reporting into management review. Clause 9.3 already requires top management to review the ISMS's performance, including the status of risk treatment. Feeding a simple, consistent risk-owner accountability summary into that review — how many risks are on schedule, how many are overdue, how many owners have gone unresponsive — turns a compliance formality into a genuine governance signal that leadership can act on.
Governance element | Cadence/trigger | Owner of the process | What "good" looks like |
|---|---|---|---|
Risk owner status report | Quarterly (high/critical), semi-annual (medium), annual (low) | GRC/ISMS manager, collecting from risk owners | Report submitted on time, referencing current risk register entry |
Treatment plan deadline check | At each plan's stated deadline | Action/control owner, escalated to risk owner if missed | Deadlines met, or a documented, owner-approved extension with rationale |
Escalation for unresponsive owner | Two missed reporting cycles | Risk owner's line manager, then ISMS steering committee | Escalation triggers automatically, isn't left to GRC's memory |
Management review input | Aligned to management review cycle (commonly quarterly or semi-annual) | Top management, per Clause 9.3 | Ownership status is a standing agenda item, not an afterthought |
Annual ownership re-validation | Once per year, or after major org change | ISMS manager | Every risk owner reconfirmed still holds the role and the authority it implies |
That last row deserves emphasis: reorganizations, role changes, and departures are the single biggest cause of risk ownership silently going stale. An annual sweep that simply asks "does this person still exist in this role, and do they still have the authority the register assumes they have?" catches the majority of drift before an auditor does.
"The finding I write up more than any other in Stage 2 audits isn't a missing control. It's a risk register where the named owner left the company fourteen months ago and nobody updated the field. The control might even still be working. But nobody can tell me who currently has the authority to say it's still an acceptable risk, and that's a direct gap against 6.1.3." — Sam Okafor, Lead Auditor, Veritas Assurance Partners
Small-Organization Realities
Everything above assumes an organization large enough to have a distinct business owner for every application, process, and vendor relationship. Plenty of ISO 27001 candidates don't look like that — a 40-person SaaS startup or a 90-person professional services firm often has the same person wearing the COO hat, the HR hat, and the de facto IT hat. The standard doesn't scale its expectations down for smaller organizations, but the implementation of risk ownership legitimately does.
The workable pattern in a small organization is role consolidation with documented rationale, not role elimination. A COO can legitimately be the risk owner for both "financial systems risk" and "HR data risk" if they genuinely hold decision authority over both areas — the key requirement is that the consolidation is a deliberate, documented choice, not a default because nobody thought about it. Where it breaks down is when the same person ends up as risk owner, control owner, and action owner for the same risk — at that point there's no functional separation between deciding a risk is acceptable and being the person whose own work created the exposure, which starts to look like the kind of conflict segregation of duties (Annex A control 5.3) exists to prevent. In a very small team, full separation may be impossible for every single risk; where it is, document the compensating control — commonly, an external advisor or a board member providing independent review of the highest-risk acceptances.
Organization size (approximate) | Realistic ownership model | Compensating practice |
|---|---|---|
Under 50 employees | Founder/COO or a small leadership team holds most risk ownership across categories | External vSCISO or advisor reviews and challenges acceptances quarterly |
50–250 employees | Department heads own risks in their domain; CEO/COO owns enterprise-wide and cross-cutting risks | ISMS manager facilitates and tracks; board or audit committee reviews annually |
250–1,000 employees | Business unit and system owners assigned per the categories above; dedicated GRC function facilitates | Quarterly governance reporting as described above becomes standard |
1,000+ employees | Fully distributed ownership model with formal RACI per risk category, tiered by business unit | Dedicated risk committee, integrated GRC tooling, and internal audit sampling ownership evidence each cycle |
The audit standard doesn't ask "how big is your company" — it asks "does the risk owner have the authority the role implies, and can you prove it." A ten-person company where the founder genuinely makes every relevant call and documents it well can pass with a simpler model than a thousand-person company that has diffused authority so far that nobody can answer for anything. Simplicity isn't the problem; unaccountable diffusion is.
Terminology: Risk Owner vs. Asset Owner vs. Process Owner vs. Data Owner
The ISMS glossary accumulates a set of "owner" terms that overlap in practice and cause real confusion in workshops, so it's worth disambiguating them once, cleanly, in one place.
Term | Defined by | Owns | Relationship to risk owner |
|---|---|---|---|
Risk owner | Clause 6.1.2(c)/6.1.3(f) | The accept/treat decision for a specific risk | The role this article is about |
Asset owner | Annex A control 5.9 (inventory of assets) context | A specific information asset — classification, handling rules, lifecycle | Often the same person as the risk owner for risks tied to that asset, but not automatically — an asset owner may lack authority over a related process risk |
Process owner | General management practice, not a defined ISO 27001 term | An end-to-end business process (e.g., onboarding, claims processing) | Frequently the correct risk owner for process-related risks; the terms are used almost interchangeably in many organizations |
Data owner / information owner | Often used interchangeably with asset owner in Annex A control 5.12 (classification) context | Data classification decisions, access-grant approvals for that data | A natural risk owner for data-related risks (e.g., unauthorized disclosure), assuming they hold real authority over access decisions |
Control owner | Practitioner term, not formally defined in the standard | Day-to-day operation of a specific safeguard | Distinct from risk owner — see comparison table above |
Action owner | Practitioner term, not formally defined in the standard | A single time-bound task | Distinct from risk owner — see comparison table above |
The practical rule of thumb: if two of these terms describe the same person for a given risk, that's fine and often efficient — just don't assume it by default. Confirm, in the register, which hat that person is wearing for that specific risk, because a person can be the correct asset owner and the wrong risk owner in the same breath (an application's technical asset owner, for instance, rarely has authority over the business decision to accept a compliance risk tied to that application). Our ISO 27001 glossary keeps the full set of these terms defined in one reference if your team needs a shared vocabulary before a workshop.
Common Mistakes in Assigning and Managing Risk Ownership
After reviewing risk registers across manufacturing, healthcare, financial services, and SaaS organizations, the same handful of mistakes recur so reliably that I now check for them by default in every gap assessment.
Mistake | Why it happens | What an auditor sees | The fix |
|---|---|---|---|
Owner field names a department, not a person | Feels safer/more permanent than naming an individual who might leave | A blank in practice — no one to interview | Always name a person by role title, with a documented succession rule if they leave |
CISO or security team owns most/all risks | Fastest way to fill blank fields under deadline pressure | Single point of failure; owner lacks authority over most rows | Reassign to the business owner with real authority; security facilitates instead |
Owner assigned but never asked to review or report | No governance cadence defined | Stale ratings, no evidence of ongoing engagement | Build the tiered reporting cadence described above into the ISMS calendar |
Risk owner conflated with control owner | Convenient shorthand in small teams; nobody separated the concepts | Same person "accepting" a risk their own technical work created | Keep the roles conceptually distinct even when held by the same person; document it |
Residual risk "accepted" verbally, never documented | Feels like unnecessary paperwork for an obvious decision | No evidence trail — direct nonconformity against 6.1.3(f) | Require a dated, written acceptance statement tied to defined risk acceptance criteria |
Ownership never revisited after a reorg | Nobody owns the meta-task of updating the register itself | Owner named has left or changed roles months ago | Annual ownership re-validation sweep, as described above |
Treatment plan approved by someone other than the risk owner | Whoever was in the room signed it to keep the project moving | Approval doesn't match the accountable name in the register | Route every RTP approval specifically to the named risk owner, no substitutes |
Ownership assigned at the workshop level, not the individual risk level | Faster to say "engineering owns all technical risks" | Too coarse — no one can answer for a specific risk's specific decision | Assign at the individual risk level, even if many risks share the same owner |
Every row in that table maps to a specific, findable audit trail gap — which is exactly why fixing them isn't just good practice, it's the difference between a clean Stage 2 and a stack of minor nonconformities that eat your certification timeline.
Mapping to the Standard: Clauses and Controls That Govern Ownership
It's easy to conflate clause numbers with Annex A control numbers when they're this close together, so it's worth laying the relevant references out side by side. Clause 5 and Annex A control 5.x are not the same numbering system — Clause 5 is a management-system clause every certified organization must satisfy; Annex A 5.x controls are candidate safeguards selected (or justifiably excluded) via the Statement of Applicability.
Reference | What it actually says | Relevance to risk ownership |
|---|---|---|
Clause 5.1 (Leadership and commitment) | Top management must ensure resources are available and roles are assigned for the ISMS | The mandate that ownership must be resourced, not just declared |
Clause 5.3 (Organizational roles, responsibilities and authorities) | Top management must assign and communicate responsibilities and authorities relevant to information security | The clause-level basis for the "authority" half of risk ownership |
Clause 6.1.2(c) | The risk assessment process must identify risk owners | The direct textual requirement to name owners |
Clause 6.1.3(f) | Risk owners must approve the risk treatment plan and accept residual risks | The direct textual requirement for approval and acceptance |
Annex A control 5.2 (Information security roles and responsibilities) | Roles and responsibilities for information security should be defined and allocated | The Annex A control most directly supporting a documented ownership structure — see our roles and responsibilities guide |
Annex A control 5.3 (Segregation of duties) | Conflicting duties and areas of responsibility should be segregated | The basis for keeping risk owner, control owner, and action owner functionally distinct |
Annex A control 5.4 (Management responsibilities) | Management should require personnel to apply information security in accordance with policy | Reinforces that risk owners' obligations are a management responsibility, not optional goodwill |
Treat this table as a quick reference rather than exhaustive legal parsing — but if an auditor asks you to justify why your ownership model looks the way it does, these are the exact references to point to. Our Clause 5 leadership guide goes deeper on the broader leadership obligations that risk ownership sits inside of.
Onboarding a New Risk Owner
Naming someone in the register is the start of the obligation, not the end of it, and a short onboarding step prevents most of the "nobody told me I owned this" complaints that surface at audit time.
Onboarding step | Purpose | Typical owner of this step |
|---|---|---|
Formal notification that they've been assigned as risk owner, in writing | Removes any ambiguity about whether the assignment "counts" | ISMS manager/GRC |
Walkthrough of the specific risk(s), current rating, and treatment status | Ensures the new owner isn't accepting or approving something they don't understand | ISMS manager/GRC, with security input |
Confirmation the owner has (or is granted) the authority the role implies | Prevents the accountability-without-authority failure mode | Owner's manager or executive sponsor |
Calendar entries for the standing reporting cadence | Makes the governance rhythm real from day one, not an afterthought | ISMS manager/GRC |
Access to the risk register entry and relevant risk acceptance criteria | Gives the owner the reference material needed to make an informed decision | ISMS manager/GRC |
Signed acknowledgment of the role (even a simple one-line email reply counts as evidence) | Creates the audit trail an assessor will look for | New risk owner |
Skipping this checklist is how organizations end up with technically-correct-on-paper ownership that falls apart the moment an auditor asks the named owner a direct question and gets a blank stare.
Case Study: Larkspur Health Analytics — From 61 Owners to a Working Model
Following the API key incident described at the start of this article, Marcus Webb ran a full ownership audit across Larkspur's 84-entry risk register. He found that 61 risks listed "IT / Security" or his own name as owner, 14 had no owner field populated at all, and only 9 had a named business owner outside of IT or security.
Over four months, Marcus's team worked through the register risk by risk, using the assignment logic from the table earlier in this piece — matching each risk to the business or system owner who actually held budget and process authority over it. Sixty-one reassignments later, the register looked structurally different: application risks sat with the relevant product VPs, vendor risks sat with the procurement and business sponsors of those contracts, and only eight enterprise-wide risks remained genuinely owned by the CISO function, each with an executive sponsor co-signing residual acceptance. Larkspur's Stage 2 audit, delayed six weeks by the incident, closed with two minor nonconformities — both related to reporting cadence documentation, neither related to ownership itself. The following year's surveillance audit found zero ownership-related findings, down from what would almost certainly have been a major nonconformity had the original register gone to audit unchanged.
Case Study: Bramwell Logistics — Owning Risk on the Plant Floor
Bramwell Logistics, a 480-employee freight and warehousing operator with six regional distribution centers, faced a different version of the same problem: its risk register was technically complete, with a named owner in every field, but nearly every physical and operational-technology risk across all six sites was owned by a single corporate IT director who had never visited four of the six facilities. When a forklift-tracking sensor network at one site was compromised through a default-credential vulnerability, the corporate IT director — who had "owned" the risk on paper — had no visibility into which local staff had installed the sensors, no relationship with the regional site's management, and no practical ability to direct a fix without going through three layers of approval he didn't control.
Bramwell's response, led by VP of Engineering Tom Reyes, was to redistribute physical and site-level operational risk ownership to the six regional site directors, who already held budget and staffing authority at their facilities, while keeping enterprise network architecture risk with corporate IT where authority genuinely sat. The company built a simple two-tier model: site directors own site-specific physical and OT risks; corporate IT and security own shared, cross-site infrastructure risks. Remediation time for site-level findings dropped from an average of 47 days to 12 days within two quarters, because the newly assigned owners could authorize local fixes without escalation. Bramwell's subsequent certification audit noted the two-tier ownership model by name as a strength in the audit report.
Case Study: Fenwick Cooperative Bank — Small Organization, Real Accountability
Fenwick Cooperative Bank, a 140-employee community financial institution pursuing ISO 27001 to support a core banking vendor's due-diligence requirements, worried early in its implementation that it simply didn't have enough distinct leadership roles to build a "proper" ownership model. COO Dana Whitfield ended up holding risk ownership for roughly 70% of the register's entries — spanning IT operations, HR data, and vendor management — because she was, genuinely, the one person with cross-functional authority over all three areas in an organization that size.
Rather than treat that concentration as a weakness to hide, Fenwick documented the rationale explicitly in its risk management procedure: which risks Dana owned and why, which risks were split out to the CEO (regulatory and strategic risk) and the IT manager (day-to-day technical control risk), and a compensating control — quarterly independent review of the highest-rated risk acceptances by a non-executive board member with a banking compliance background. The auditor's Stage 1 documentation review flagged the concentration for discussion but, seeing the documented rationale and the compensating board review, raised no nonconformity. Fenwick certified on schedule, and the board review practice has since become a standing feature of its governance rather than a one-time audit accommodation.
Case | Core problem | Fix applied | Quantified outcome |
|---|---|---|---|
Larkspur Health Analytics | 61 of 84 risks defaulted to security/CISO ownership | Reassigned ownership to actual business/system owners across 4 months | Stage 2 closed with 2 minor NCs (down from likely major NC); zero ownership findings the following year |
Bramwell Logistics | Single corporate owner for six sites' physical/OT risk, no local authority | Two-tier model: site directors own local risk, corporate IT owns shared infrastructure risk | Average remediation time dropped from 47 to 12 days within two quarters |
Fenwick Cooperative Bank | Small org, one person holding ~70% of ownership by necessity | Documented rationale + compensating independent board review of high-rated acceptances | Certified on schedule; zero nonconformities tied to ownership concentration |
"What changed at Fenwick wasn't that Dana suddenly owned less. It was that we could finally show, in writing, why she owned what she owned, and that someone independent of her day-to-day authority was checking the biggest calls. That documentation is what turned a potential finding into a non-issue." — internal ISMS consultant engaged on the Fenwick certification project
Red Flags: Signs Your Risk Ownership Program Won't Survive Audit
Before a Stage 1 or Stage 2 visit, it's worth running the register through a quick self-diagnostic. Any two or more of these present at once is a strong predictor of an ownership-related nonconformity.
Red flag | What it usually indicates |
|---|---|
More than 20% of risks owned by the security/GRC function itself | The CISO-owns-everything anti-pattern described above |
Any risk owner field populated with a department name instead of a person | No accountable individual actually exists for that risk |
No documented reporting cadence tied to risk severity | Ownership is decorative — no governance rhythm enforces it |
Risk owners who cannot describe, unprompted, the risk they own in an interview | Assignment happened without genuine engagement or handoff |
Residual risk acceptance recorded only as a verbal note or implied by inaction | No evidence trail for 6.1.3(f) — a near-certain nonconformity |
No process for reassigning ownership after a reorg or departure | Ownership silently decays over time |
Risk owner, control owner, and action owner are the same person for every high-severity risk with no compensating review | Segregation-of-duties concern under Annex A control 5.3 |
The Strategic Case: Ownership Is a Selling Point, Not Just an Audit Requirement
It's tempting to treat risk ownership as pure compliance overhead — one more field to populate before an auditor shows up. That framing undersells what a working ownership model actually does for the business. When a prospective enterprise customer's security team reviews your ISO 27001 certificate and asks a follow-up question — "who in your organization is accountable for the risk in this specific area of your product?" — a confident, specific answer closes deals faster than a vague one. Sales and customer-trust teams increasingly field exactly this question during vendor security reviews, and "our risk owners are named business leaders with real authority, reviewed quarterly, escalated through management review" is a materially stronger answer than "our security team handles that."
The same logic extends across frameworks: a SOC 2 audit examines control ownership and accountability with a similar lens, and NIST CSF's Govern function explicitly calls out risk management roles and responsibilities as a foundational outcome — meaning the ownership model you build for ISO 27001 is largely reusable collateral for other frameworks your customers or regulators may eventually ask about. Building it once, correctly, pays down that work across every future assessment rather than once per framework.
There's also a quieter internal benefit that outlasts any single audit cycle: organizations with genuine, named risk ownership make faster decisions during actual incidents, because the accountability structure that answers "who decides if we accept this exposure" already exists before the crisis, rather than getting improvised at 2 a.m. by whoever answers the phone. Larkspur's post-incident model didn't just satisfy an auditor — it meant the next vendor-related exposure his team found, eleven months later, got a documented accept/reject decision from the correct owner within 48 hours, not six months after the fact.
If your risk register currently reads like Larkspur's did — a wall of names that are really departments, or a CISO's name repeated sixty times — the fix described in this article is neither exotic nor expensive. It's a few weeks of conversations, one governance calendar, and the discipline to keep asking "who actually has the authority to decide this is acceptable" until the answer is a specific person every time.
If you're building or repairing this model and want a structured starting point, PentesterWorld's ISO 27001 Risk Register Template includes dedicated risk-owner, control-owner, and action-owner fields with built-in reporting-cadence tracking, and the accompanying Information Security Policy Template includes model language for Clause 5.3 roles and authorities that you can adapt directly. For hands-on practice assigning ownership inside a real treatment workflow, our Build a Sample Risk Treatment Plan lab walks through the exact approval and acceptance steps an auditor will look for, and the Complete ISO 27001 Implementation Guide eBook places risk ownership in the context of a full certification roadmap. If you're prepping your team for interview-style scrutiny on this exact topic, the Internal Audit Interview Question Script includes the pointed ownership questions auditors actually ask, so your named owners walk in ready rather than caught flat-footed.
Marcus Webb still keeps a printout of Larkspur's old risk register on his wall — the one with his own name in sixty-one owner fields. It's a reminder that a complete-looking spreadsheet and a genuinely accountable organization are two different things, and only one of them survives contact with an incident, an auditor, or a customer's toughest question.