Every risk and control matrix has a column headed “control owner”, and in most organizations it is full of names. The trouble starts when you ask the people behind those names what they own. Some will describe the control accurately and show you its evidence. Some will say they perform it but someone else decides how it works. Some left the organization last spring. And a few will say they had no idea their name was there. A control nobody is accountable for decays quietly: it keeps running out of habit until the person doing it moves on, and then it simply stops, usually without anyone noticing until an auditor or an incident does.
This guide is about making ownership real. It separates the four roles that get confused, sets out what an owner is actually accountable for, explains how controls become orphans and how to find them with a simple analytic, gives an ownership register and a RACI for a control’s life cycle, covers the handover that keeps ownership intact through reorganizations, and shows how auditors test all of it. A worked example follows a regional bank that found 23 of its 212 key controls owned by the wrong people after a reorganization. It is written for managers who own controls and for the auditors and risk teams who test them; the site’s guide to the risk and control matrix template covers the matrix the owner column sits in.
In this guide
- Four roles that get confused
- What a control owner is accountable for
- How controls become orphans
- The ownership register
- Finding orphaned controls: a simple analytic
- Embedding ownership so it survives change
- A RACI for a control’s life cycle
- The handover checklist
- Ownership in small teams
- Ownership through shared services and outsourcing
- How auditors test ownership
- What good ownership looks like when the auditors arrive
- Worked example: a bank’s owner register after a reorganization
- Questions about control ownership
- Related guides
Four roles that get confused
Most ownership problems begin with one name doing the work of four roles, or four names each assuming someone else holds the important one. The COSO internal control framework puts the expectation plainly. Principle 3 asks management to establish structures, reporting lines and appropriate authorities and responsibilities; Principle 5 asks the organization to hold individuals accountable for their internal control responsibilities; and among the points of focus for Principle 12 is establishing responsibility and accountability for executing policies and procedures. None of that works unless the roles are distinct and each has a name. The site’s guide to COSO’s 17 principles covers the framework in full.
| Role | Accountable or responsible for | Typically | Evidence the role is real |
|---|---|---|---|
| Control owner | That the control is designed to address its risk, operates as designed, is evidenced, changes safely and is fixed when it fails | A manager with authority over the process and the people who run it | They can describe the control’s purpose, frequency, evidence and last failure without looking anything up |
| Control performer | Carrying out the control on each occasion, correctly and on time, and keeping the evidence | The person who does the work: a clerk, analyst, engineer or supervisor | The evidence of each operation carries their name and date |
| Reviewer or approver | Checking the performer’s work where the control includes a review step | A more senior person, independent of the performer | Review evidence showing what was checked, not only a signature |
| Monitor | Checking, from outside the process, that the control keeps working over time | Second-line risk or compliance, a quality team, or management through key indicators | Monitoring results, and the follow-up when something was found |
Two further roles sit around these four. The process owner is accountable for the process as a whole, of which the control is one step, and is often, but not always, the control owner too. The risk owner is accountable for the risk the control addresses, and in organizations with an enterprise risk framework may sit higher still. Where these are different people, the register should say so; where they are the same, it should say that too. The failure to avoid is the performer who is also the only named owner, with nobody above them accountable for whether the control is designed properly or survives their departure.
What a control owner is accountable for
Ownership is not the same as performing the control, and it is not a label. It is a set of accountabilities that last as long as the control exists. The list below is the one worth writing into an owner’s objectives, because it is also the list an auditor will test against when a control fails.
| Accountability | What it means in practice | What happens when nobody holds it |
|---|---|---|
| Design | The control addresses the risk it is meant to address, at a precision that would catch a meaningful error | A control that operates perfectly and catches nothing |
| Documentation | The control description says who does what, when, with what evidence, and what counts as an exception | Each performer does it differently; the auditors cannot test it |
| People | Performers and reviewers are trained, have the time, have backups, and are independent where they need to be | The control stops when one person is away |
| Operation and evidence | The control runs every time it should and leaves evidence that it did | A control that happened but cannot be shown to have happened |
| Change | Changes to the process, system or people are assessed for their effect on the control before they happen | A system upgrade that silently removes a control step |
| Exceptions and failures | Failures are noticed, escalated and fixed, and patterns are looked for | The same failure recurs until an auditor finds it |
| Remediation | Audit findings and self-identified issues are fixed, by a named date | Actions drift overdue with nobody to answer for them |
| Certification | Periodic confirmation that the control operated and what changed | Management’s assurance rests on assumption |
| Handover | When the owner changes, the control is handed over with its evidence and open issues | An orphaned control |
A useful test of whether someone really owns a control is to ask them three questions: what risk does it address, what did it catch in the last year, and what would happen if it stopped tomorrow? An owner answers all three without hesitation. A name in a column does not.
How controls become orphans
Controls rarely lose their owners in a single dramatic event. They lose them through ordinary change that nobody connected to the control register. The patterns below account for almost every orphaned control an auditor finds.
| Cause | What it looks like | How long it usually takes to surface |
|---|---|---|
| The owner leaves | The register still names them; the control runs on habit until the performer also moves | Months, often until the next audit |
| A reorganization | The process moves to a new team, the control stays with the old manager’s name, or falls between two teams | Immediately if a control stops; a year if it drifts |
| A role change | The owner is promoted and keeps the name on controls they no longer supervise | Until something fails |
| A system change | The control was a manual step the new system was supposed to replace, and did not | The first period after go-live |
| Outsourcing | The provider performs the control; nobody inside owns monitoring it | Until the provider’s assurance report shows an exception nobody reads |
| Ownership by committee or department | “Finance” or “the credit committee” is named as owner | Never, until someone asks who in finance |
| Ownership assigned to the wrong function | IT named as owner of a business control because it runs on a system | When the business rule changes and IT does not know |
The last two deserve emphasis because they are designed in, not drifted into. A committee cannot be held accountable in the way COSO’s Principle 5 intends; a named chair of that committee can. And a business control that runs in a system still belongs to the business: IT owns the change and access controls that keep the configuration reliable, which the site’s guide to IT general controls versus application controls explains, but the business decides what the configuration should enforce.
The ownership register
Most organizations already have the raw material for an ownership register in their risk and control matrix or governance system. What turns a matrix column into a register is three additions: the owner and performer recorded by employee identifier as well as name, so they can be matched to HR data; a backup for each; and the date ownership was last confirmed. The fields below are enough.
| Field | Why it is there |
|---|---|
| Control identifier and short description | Links to the risk and control matrix |
| Key or non-key | Key controls get the monthly check below; others can be reviewed less often |
| Owner: name, role, employee identifier | The identifier allows the match to the HR roster |
| Performer or performers, with identifiers | So departures and moves of performers are caught too |
| Reviewer, with identifier, where the control has a review step | To check independence from the performer |
| Backup performer | So the control survives leave and vacancies |
| Frequency and evidence location | So a new owner can find what has been kept |
| Systems and reports used | So system changes can be traced to the controls they affect |
| Date ownership last confirmed | A stale date is itself a warning |
| Open issues and actions | So they transfer with the control |
Keep the register where the controls already live, whether that is a governance system or a controlled spreadsheet, and make one person responsible for its upkeep, usually in the SOX program office, the risk function or the finance controls team. Ask each owner to confirm their entries at least once a year and whenever their role changes. The confirmation takes minutes and does something no analytic can: it makes the owner read, and agree to, what their name is attached to.
Finding orphaned controls: a simple analytic
Once owners and performers carry employee identifiers, a monthly match against the HR roster finds almost every orphan within weeks of it appearing. The match is simple enough to run in a spreadsheet; the value comes from running it every month and acting on what it finds. Internal audit can run the same match across the whole register in an afternoon, which is why it is one of the first analytics in many controls audits.
| Flag | How to detect it | What it usually means |
|---|---|---|
| Owner or performer has left | Identifier not on the active HR roster | An orphan; the control may already have stopped |
| Owner has moved | Owner’s department or cost center differs from the process’s | Ownership left behind after a role change or reorganization |
| Owner is on long-term leave | HR leave status | Nobody accountable in practice; check the backup |
| Performer is also the reviewer | Same identifier in both fields | No independent review, whatever the description says |
| One person owns far more controls than peers | Count of key controls per owner | Ownership by default; the owner cannot be accountable for all of them |
| No backup named | Empty backup field | The control stops when one person is away |
| Ownership not confirmed recently | Confirmation date older than the policy allows | A register nobody maintains |
| Owner is a contractor or a group mailbox | Worker type or identifier format | Accountability outside the employment relationship, or with nobody |
The most important flag is the first, and the most important response to it is not updating the register. It is checking whether the control operated since the person left. Orphaned controls are found in the register, but the risk is in the gap between the departure and the discovery.
Embedding ownership so it survives change
A register kept current by a monthly analytic catches orphans. Ownership that does not produce orphans in the first place comes from building it into the ordinary machinery of employment: what people are hired to do, what they are measured on, what they confirm, and what happens when they move.
- Role descriptions. Name control ownership in the role description of every manager who owns key controls, so it transfers with the role rather than the person.
- Objectives. Put the owned controls, and their audit and monitoring results, into the owner’s annual objectives. What is measured gets attention.
- Periodic certification. Ask owners to confirm, each quarter or half-year, that their key controls operated as designed, what changed, and what failed. In organizations subject to SOX, these sub-certifications support the chief executive’s and finance chief’s certifications; elsewhere they are simply good discipline. A certification that nobody can decline without consequence is a formality, so make exceptions easy to report.
- Onboarding for new owners. A new manager inheriting controls gets the register extract, the control descriptions, the evidence locations and the open issues in their first month, not when the auditors arrive.
- Handover as a condition of moving. No manager with key controls moves role or leaves without a completed handover to a named successor or interim owner.
- Change management. Every system change, reorganization or outsourcing proposal asks which controls it affects and who will own them afterwards.
Consequences matter in both directions. An owner whose controls fail repeatedly, with no action, should find it reflected in their objectives and review, because that is what accountability means under COSO’s Principle 5. An owner who reports a failure early and fixes it should find that recognized, not treated as a black mark, or the certification process will quickly learn to report nothing. The balance between the two decides whether owners tell you about problems or wait for the auditors to find them.
A RACI for a control’s life cycle
A RACI chart assigns each activity a Responsible party (who does the work), an Accountable party (who answers for it, and there should be only one), and parties to be Consulted or Informed. The chart below covers the life of a typical key control. Adjust the columns to your organization, but keep one rule: every row has exactly one A.
| Activity | Control owner | Performer | Reviewer | Process owner | Second line (risk or compliance) | Internal audit |
|---|---|---|---|---|---|---|
| Design the control against the risk | A | C | C | R | C | I (advice on request) |
| Document the control description | A | R | C | C | C | I |
| Perform the control each time | A | R | I | I | — | — |
| Review the performer’s work | A | I | R | I | — | — |
| Keep the evidence | A | R | R | I | — | — |
| Assess changes to process or system | A | C | C | R | C | I |
| Monitor that the control keeps working | I | — | — | C | A and R | I |
| Independent testing | C | C | C | I | I | A and R |
| Remediate failures and findings | A | R | C | C | C | I (then validates) |
| Certify operation periodically | A and R | C | C | I | I | I |
| Hand over on change of owner | A and R | I | I | C | I | I |
Two rows reflect the independence of the other lines. Second-line monitoring and internal audit’s testing are accountable to their own leadership, not to the control owner, and internal audit’s role in design is advisory only. The site’s guide to internal controls and the three lines explains why that separation matters.
The handover checklist
The handover is where ownership is most often lost, because it happens during the busiest moment in anyone’s working life: a move or a departure. A checklist kept short enough to complete in an hour makes it routine.
Control ownership handover
Controls transferred. List each control by identifier, with key or non-key status, frequency and performer.
Evidence. Where the evidence for each control is kept, and the most recent operation’s evidence, reviewed together.
Open issues. Every open audit action, self-identified issue and known weakness, with dates and status.
People. Performers, reviewers and backups, and any gap in cover.
Coming changes. System changes, reorganizations or vendor changes that will affect the controls.
Confirmation. Signed by the outgoing and incoming owner, dated, with the register updated the same day and the audit function and second line informed.
Ownership in small teams
Everything above assumes enough people to separate the roles. In a small organization, or a small team inside a large one, the owner, the performer and the reviewer may be the same two or three people, and pretending otherwise produces a register that nobody believes. The honest approach is to accept the overlap and add a check from outside it. A finance lead who owns and performs the bank reconciliation can have it reviewed monthly by the managing director, a board member or the external accountant. A single payroll administrator can have each run’s exception report reviewed by the owner of the business. Rotation of duties and mandatory leave, long established in banking, serve the same purpose: someone else does the work for a period, and anything that only works when one person is present comes to light.
Write the compensating arrangement into the register, with a name against it, and test it the same way you would test any control. What matters to an auditor in a small organization is not a perfect separation of roles, which the size makes impossible, but whether the organization has recognized where accountability overlaps and put a real check around it. The site’s guide to setting up internal audit in a small company covers the wider picture.
Ownership through shared services and outsourcing
Shared service centers and outsourced providers split ownership across an organizational boundary. The center performs the control, often for several business units; the business unit owns the risk and the outcome. Both sides tend to assume the other is accountable. The arrangement that works treats the shared service like an internal service provider. The center owns the design and operation of the controls it performs and reports on them, much as an external provider would through an assurance report. Each business unit names an owner for monitoring what it receives and for the complementary controls it must still operate itself, such as approving what it sends to the center and reviewing what comes back.
A written catalog of the controls the center performs, with owners on both sides and the reporting that connects them, turns a vague assumption into something testable. When a process is outsourced to a third party, the same logic applies with a contract in the middle, and the site’s guide to the Third-Party Topical Requirement sets out what internal audit will expect of the monitoring.
How auditors test ownership
Auditors rarely write a finding titled “control ownership”. They find its symptoms: a control that stopped when its performer left, a review performed by the person whose work it reviews, a certification program that has not reported an exception in three years. The procedures below are how they get there, and they are worth running on yourself before anyone else does.
| Procedure | What it can reveal |
|---|---|
| Match the register to the HR roster, as in the analytic above | Departed and moved owners, performer-reviewer overlaps, missing backups |
| Interview a sample of owners with three questions: what risk does it address, what did it catch last year, what would happen if it stopped | Names in a column rather than owners |
| For each flagged control, test whether it operated after the owner or performer changed | Controls that silently stopped |
| Compare control descriptions with how the control is actually performed | Drift that no owner noticed or approved |
| Read the certification history: how many exceptions were reported, and what happened to them | A certification process that is a formality |
| Sample people who moved or left in the period and look for a handover | Whether handovers happen or ownership is lost at every move |
| Check evidence during known absences of performers | Whether backups really operate |
A certification process with no exceptions over several years deserves particular attention. Controls fail sometimes in every organization; a record that says they never do usually means the certification is signed without looking. The control description examples guide shows the level of detail that makes a description testable, and the management review controls guide covers the reviewer role in depth.
What good ownership looks like when the auditors arrive
Auditors can usually tell within ten minutes whether a control has an owner. The owner of a well-run control explains what it is for and why it is designed the way it is, points to where the evidence is kept, mentions the failure it had last quarter and what was done about it, and knows which system changes are coming that might affect it. When the auditors find an exception, the owner wants to understand the cause, not to argue it away. A name in a column behaves differently: it defers to the performer, cannot find the evidence, and hears about the control’s last failure from the auditors.
The difference shows up in the report. Findings in areas with real owners tend to be about design choices and specific failures, with causes the owner helped identify and actions the owner can deliver. Findings in areas without them tend to be about the absence of anything to test, with causes that read “no one was responsible”, and actions that start by naming someone. The guides to being interviewed by internal audit and to working with internal audit between audits cover the owner’s side of those conversations.
Worked example: a bank’s owner register after a reorganization
Lakeshore Bancorp, the $9 billion regional bank used across this site, carried 212 key controls in its SOX program. In FY26 it merged its deposit operations and loan servicing teams into a single operations group, moving several managers and a few dozen staff. The control register, held in the bank’s governance system, recorded owners and performers by name only. Six months after the reorganization the SOX program office added employee identifiers and ran the first match against the HR roster.
| Flag | Key controls affected | What was found when the controls were checked |
|---|---|---|
| Owner had left the bank | 7 | Six controls still operating on habit; one monthly suspense account reconciliation not performed for two months after its performer transferred |
| Owner had moved to a role with no authority over the process | 16 | All operating, but with nobody accountable for design or changes |
| Performer also recorded as reviewer | 9 | In four, the reviewer had in practice been reviewing their own work since the reorganization |
| Owned by a committee | 4 | Committee minutes showed discussion but no one accountable for follow-up |
| No backup named | 31 | Evidence gaps in holiday periods for five of them |
Twenty-three of the 212 key controls, about one in nine, had owners who had left or moved. The missed suspense reconciliation caused no loss, but it was a control failure the external auditor would have found, and it was evaluated as a deficiency under the bank’s deficiency evaluation method. The fixes took a quarter: employee identifiers and backups for every key control, a monthly HR match run by the program office, named chairs replacing committees as owners, a handover checklist made a condition of any move for managers with key controls, and a quarterly sub-certification that asked owners to report exceptions rather than simply sign. A year later the monthly match was producing two or three flags at a time, each resolved within a month, and the certification recorded its first exceptions, which was a sign it had started to work.
Questions about control ownership
Can a committee own a control?
A committee can be the forum where a control operates, such as a credit committee approving large exposures, but accountability needs a person. Name the chair as owner, and make the secretary or another named person responsible for the evidence and follow-up.
Should IT own controls that run in a system?
IT owns the general controls that keep a system reliable: who can change it, how changes are tested and approved, who has privileged access. The business owns the rule the system enforces, such as a matching tolerance or an approval limit, because only the business can decide what that rule should be.
How many controls can one person own?
There is no fixed number. The test is whether the owner can answer the three questions for every control in their name. When one manager owns several times more key controls than peers, ownership has usually been assigned by default, and some of it should move closer to the processes involved.
Who owns a control performed by a service provider?
The provider performs it, but someone inside the organization must own the monitoring: reading the provider’s assurance reports, operating the complementary controls those reports assume, and acting on exceptions. The site’s guide to reviewing a SOC 1 report covers that monitoring role.
Should the owner also perform the control?
For a simple control in a small team, sometimes that is unavoidable. Where it happens, someone else should review or monitor it, because an owner who is also the only performer has nobody above them checking whether the control is designed properly or survives their absence.
What should happen when an owner goes on long leave?
Treat it as a temporary handover. Name an interim owner in the register for the period, walk them through the controls, evidence and open issues using the handover checklist, and hand back the same way on return. Leave is one of the commonest times for a key control to stop without anyone deciding that it should, because everyone assumes the backup has it covered.
Related guides
- Being audited? — every guide for auditees and management, by stage of the audit.
- Risk and control matrix template — the matrix the owner column belongs to.
- Control description examples — descriptions an owner can be held to.
- What is a control? — the foundations.
- Preventive, detective and corrective controls — the control taxonomy.
- COSO’s 17 principles — accountability in the framework.
- Internal controls and the three lines — who owns, who monitors, who assures.
- Segregation of duties — when performer and reviewer must differ.
- Management review controls — the reviewer’s role in depth.
- SOX 404 — certifications and management’s assessment.
- The RCSA process — owners assessing their own controls.
- Writing management action plans that close — when an owner has to answer a finding.
- Living with internal audit year-round — ownership between audits.
Leave a Reply