The most common reason a compliance obligation slips through the cracks is not complexity or cost. It is that nobody was clearly responsible for it. When ownership is fuzzy, "everyone's job" quickly becomes no one's job. This guide shows you how to assign compliance ownership deliberately, document it so it survives staff changes, and handle the messy reality of obligations that span multiple departments.
What You'll Learn
By the end of this tutorial you will know why ownership matters, how to apply a RACI model to compliance, how to pick the right owner, the difference between being accountable and responsible, how to record ownership in your register, and how to handle shared or cross-functional obligations without gaps.
Why Compliance Ownership Matters
Compliance ownership is the act of naming a specific person who is answerable for whether a given obligation is met. It is not the same as doing the work. It is being on the hook for the outcome. Without it, three predictable failures occur.
Obligations go stale. A regulation changes, a control degrades, or evidence is never collected. Because no one is watching that specific obligation, the gap surfaces only during an audit, a complaint, or a regulatory inspection. By then it is a finding rather than a routine fix.
Accountability evaporates under pressure. When a regulator asks who is responsible for ensuring breach notifications go out within 72 hours, a confident, specific answer signals a mature programme. A pause and a round of finger-pointing signals the opposite.
Work is duplicated or dropped. Two teams each assume the other is handling a shared obligation, so it is either done twice or not at all. Clear ownership removes the ambiguity.
Ownership is the connective tissue that turns a static list of rules into a managed programme. It is what makes a compliance register actionable rather than decorative, and it underpins your ability to track and report compliance status with credibility.
Accountable vs Responsible
The single most important distinction in ownership is between accountable and responsible. Conflating the two is the root cause of most ownership confusion.
- Accountable: The one person who answers for the obligation being met. They own the outcome, sign off on it, and carry the consequences if it fails. There is exactly one accountable person per obligation.
- Responsible: The people who do the actual work, such as gathering evidence, running the control, and updating records. There can be several responsible people for a single obligation.
A useful test: the accountable person is who a regulator or your board would name if the obligation were breached. The responsible people are who they would interview to understand how the day-to-day work gets done.
Data Subject Access Requests
Obligation: Respond to data subject access requests within the statutory timeframe.
Accountable: Head of Privacy (one person, answers for it).
Responsible: Two privacy analysts who log requests, retrieve data, and draft responses.
If a request is missed, the Head of Privacy answers for it, even though they personally did none of the retrieval work. This separation keeps accountability clear without making one person do everything.
Want the full framework with worked examples?
A RACI Model for Compliance
RACI is the most practical framework for mapping ownership across a compliance obligation. It assigns four roles to each obligation:
| Role | Letter | Meaning | How Many |
|---|---|---|---|
| Responsible | R | Does the work to meet the obligation | One or more |
| Accountable | A | Answers for the outcome; signs off | Exactly one |
| Consulted | C | Provides input before decisions (two-way) | As needed |
| Informed | I | Kept up to date on status (one-way) | As needed |
Two rules of RACI for compliance are non-negotiable: every obligation has exactly one A, and every obligation has at least one R. If an obligation has two people marked Accountable, you have not assigned ownership. You have created an argument waiting to happen. If it has none, the obligation is orphaned.
Pro Tip
Build your RACI at the obligation level, not the regulation level. "POPIA" is too broad to assign to one person. "Appoint and register an Information Officer" or "maintain a record of processing activities" are discrete obligations that map cleanly to an owner. This is where good obligation mapping pays off.
A Worked RACI Row
| Obligation | Head of Privacy | IT Security Lead | Legal Counsel | CEO |
|---|---|---|---|---|
| Notify regulator of a reportable breach | A | R | C | I |
| Maintain encryption of personal data at rest | C | A / R | I | I |
| Approve the annual compliance plan | R | C | C | A |
Notice that the IT Security Lead can be both A and R for the encryption obligation. When the accountable person is also close enough to do the work, that is perfectly valid. The point is that each row has one and only one A.
Choosing the Right Owner
The right accountable owner is rarely the most senior person available. Seniority feels safe, but a CEO who "owns" 200 obligations cannot meaningfully watch any of them. Use these criteria to choose:
- Proximity: The owner should sit close to where the obligation actually operates. The person who runs the process is far more likely to notice when it drifts.
- Authority: They must have the budget, headcount, or decision rights to actually fix problems. Accountability without authority is a setup for failure.
- Capacity: A realistic number of obligations. Someone accountable for 40 obligations across five regulations will triage, and the low-visibility ones will lose.
- Continuity: Prefer a role over a named individual where possible (see below), so ownership survives turnover.
Own the Role, Name the Person
The most resilient pattern is to assign ownership to a role (Head of Finance, Information Officer, Facilities Manager) and then record the current incumbent's name alongside it. When someone leaves, you update one cell rather than re-deriving who owns what. This is also how you avoid the classic failure where a key employee resigns and an entire cluster of obligations silently loses its owner.
Important
Never assign an obligation to a committee or a department as the accountable party. "Owned by the Compliance Committee" or "owned by IT" means owned by no one. A committee can be Consulted or Informed, and a department can host the Responsible team, but the A must always resolve to a single named role.
Handling Shared and Cross-Functional Obligations
Some obligations genuinely span functions. Breach response touches IT, Legal, Privacy, and Communications; vendor due diligence touches Procurement, Security, and Legal. These are where ownership most often breaks down. Three techniques keep them clean.
1. Decompose Before You Assign
A "shared" obligation is usually several distinct obligations bundled together. Break breach response into "detect and contain the incident" (IT Security), "assess reportability and draft notification" (Privacy and Legal), and "communicate to affected parties" (Communications). Each sub-obligation now has a clean single owner, even though the overall process is collaborative.
2. Name a Single Accountable Owner for the End-to-End Outcome
Even after decomposing, name one person accountable for the obligation being met overall, typically the person who answers to the regulator for that domain. They coordinate the responsible parties but do not have to do every task. This prevents the "we each did our part but the whole thing still failed" outcome.
3. Use Consulted and Informed Deliberately
Most cross-functional friction is really a communication gap, not an ownership gap. Mark the parties who must give input as Consulted and those who only need awareness as Informed. This makes the hand-offs explicit so nothing falls between teams.
Vendor Risk: A Cross-Functional Obligation
Obligation: Ensure all third-party processors handling personal data have a signed data processing agreement and have passed a security review.
Decomposed and assigned:
Maintain the processor inventory: A = Procurement Manager.
Run the security review: A = IT Security Lead, C = Privacy.
Execute the data processing agreement: A = Legal Counsel.
Overall end-to-end accountability: A = Head of Privacy, who confirms no vendor goes live without all three steps complete.
Documenting Ownership in the Register
Ownership that lives only in someone's head is not ownership. It must be recorded in your compliance register so it is visible, reviewable, and defensible. At a minimum, capture these fields per obligation:
| Field | What It Records | Example |
|---|---|---|
| Accountable Owner (Role) | The role answerable for the outcome | Head of Privacy |
| Accountable Owner (Name) | Current incumbent of that role | T. Mokoena |
| Responsible Parties | Who does the work | Privacy analysts, IT Security |
| Consulted / Informed | Input and awareness stakeholders | Legal (C), CEO (I) |
| Date Assigned | When ownership was confirmed | 2026-02-12 |
| Acknowledged | Whether the owner accepted it | Yes |
The Acknowledged field matters more than it looks. Ownership that someone learns about for the first time during an audit is not real ownership. Have owners formally accept their obligations, whether by a sign-off, an email, or an in-app acknowledgement, so there is no dispute later about who agreed to what.
Keep an Audit Trail of Changes
When ownership transfers (a reorganisation, a resignation, a new hire), record who owned it before, who owns it now, and when the change took effect. This trail is invaluable when a finding relates to a period before the current owner took over, and it shows inspectors that your programme is actively managed. It pairs naturally with the evidence discipline described in compliance evidence.
Pro Tip
Run an "orphan check" every quarter: filter your register for any obligation with no accountable owner, no acknowledgement, or an owner whose role no longer exists. Orphaned obligations are where breaches hide. The same review cadence you use to track compliance obligations is the ideal moment to do this.
Common Mistakes to Avoid
1. Assigning Everything to the Compliance Officer
The compliance function should facilitate, monitor, and report, not own every obligation. When the compliance officer owns everything, the business disengages and treats compliance as someone else's problem. Ownership belongs in the business, close to the risk.
2. Two Accountable Owners
Splitting accountability between two people guarantees that when something fails, each will reasonably assume the other had it. One A per obligation, always.
3. Owner Without Authority
Naming a junior analyst accountable for an obligation they cannot fund or fix is accountability theatre. Match the level of the owner to the decision rights the obligation requires.
4. Set-and-Forget Ownership
Ownership assigned once and never reviewed drifts out of date as people move and roles change. Re-confirm ownership at least annually and after any reorganisation.
5. Unacknowledged Ownership
If owners never formally accepted their obligations, you do not have ownership. You have a list of names. Always capture acknowledgement.
Summary
- Compliance fails quietly when no one clearly owns an obligation; ownership is the connective tissue of a working programme.
- Distinguish accountable (one person, answers for the outcome) from responsible (the people who do the work).
- Use RACI at the obligation level: exactly one A, at least one R per obligation.
- Choose owners for proximity, authority, capacity, and continuity, not just seniority. Own the role, name the person.
- Decompose cross-functional obligations, then name a single end-to-end accountable owner to coordinate.
- Document ownership in the register with acknowledgement and an audit trail of changes, and run quarterly orphan checks.
Frequently Asked Questions
Can one person be both accountable and responsible for an obligation?
Yes. When the accountable owner is close enough to the work to do it themselves, marking them as both A and R is valid and common for smaller obligations. The rule that matters is one A per obligation, not that A and R must be different people.
Should I assign ownership to a person or a role?
Assign to a role and record the current incumbent's name alongside it. This way ownership survives staff turnover: when someone leaves, you update one cell rather than re-deriving who owns dozens of obligations. Never assign to a committee or department, which dilutes accountability to no one.
What if an obligation genuinely spans several departments?
Decompose the obligation into discrete sub-obligations, each with its own single owner, then name one person accountable for the end-to-end outcome to coordinate. Use the Consulted and Informed roles to make hand-offs between teams explicit so nothing falls between them.
How many obligations can one person realistically own?
There is no fixed number, but capacity is a real constraint. An owner with dozens of obligations across multiple regulations will inevitably triage, and the low-visibility ones suffer. If one person accumulates an unmanageable load, that is a signal to redistribute ownership closer to where each obligation operates.
Does the compliance officer own all compliance obligations?
No. The compliance function facilitates, monitors, and reports on the programme, but individual obligations should be owned by the business leaders closest to them. When the compliance officer owns everything, the business disengages. The compliance team owns the framework; the business owns the obligations.
How do I prove ownership to an auditor or regulator?
Show your compliance register with the accountable owner, responsible parties, the date ownership was assigned, and the owner's acknowledgement, plus an audit trail of any ownership changes. This demonstrates that ownership is deliberate, accepted, and actively maintained rather than assigned on paper only.
Save this guide for later
Download the PDF version to read offline or share with your team.
