Regulations are written for lawyers and courts, not for the people who have to operationalize them. A single section of a data protection or financial services act can contain a dozen separate things your organization must actually do. Regulatory obligation mapping is the discipline of pulling those discrete obligations out of dense legal prose and connecting each one to a control, an owner, and a business unit. It is the foundation on which compliance registers, gap analyses, and audit readiness are built.
What You'll Learn
You will learn what obligation mapping is, how to decompose a regulation into discrete obligations, how to map each obligation to controls, owners, and business units, how to assemble a reusable obligation library, and how to keep that library current as laws change.
What Regulatory Obligation Mapping Is
Regulatory obligation mapping is the process of analyzing the laws, regulations, standards, and contracts that apply to an organization and translating them into a structured set of discrete, actionable obligations. Each obligation is linked to the control that satisfies it, the owner accountable for it, and the business unit where it lives.
The output is not a summary of the law. It is a working map: "This clause requires us to do X; the control that does X is Y; the person accountable is Z; it applies to business unit W." That map is what makes a regulation manageable instead of merely readable.
Obligation mapping sits upstream of almost everything else in a compliance program. It feeds the compliance register, it defines the baseline for a compliance gap analysis, and it determines what controls and evidence an auditor will expect to see.
Why Obligation Mapping Matters
1. It makes regulations actionable
"Comply with the Act" is not a task anyone can do. "Appoint an Information Officer, register them with the Regulator, and review the appointment annually" is. Mapping converts the former into the latter.
2. It exposes hidden obligations
Obligations hide in subordinate clauses, cross-references, and definitions. Systematic decomposition surfaces requirements that a casual reading misses, often the ones that later become findings.
3. It prevents duplicated and orphaned effort
When the same obligation appears in two regulations, mapping lets you satisfy both with one control. When an obligation has no control behind it, mapping makes that orphan visible.
4. It scales across change
A mapped obligation library means that when a law is amended, you change the affected obligations rather than re-reading the entire act from scratch.
Step 1: Decompose Regulations into Obligations
The core skill of mapping is decomposition: reading a provision and extracting each distinct "shall" or "must" into its own obligation. A good obligation is atomic (one requirement), actionable (it describes something a person can do), and attributable (someone can own it).
Decomposing one provision
Provision: "Every employer must conduct a risk assessment of the workplace, record the results, communicate the findings to affected employees, and review the assessment at least every two years or whenever conditions change materially."
Obligation A: Conduct a workplace risk assessment.
Obligation B: Record the assessment results.
Obligation C: Communicate findings to affected employees.
Obligation D: Review the assessment every two years or on material change.
One provision, four obligations, each with its own control, owner, and evidence. Treating it as a single obligation would mask three of the four requirements.
Pro Tip
Watch for "trigger words" that signal separate obligations: and, as well as, including, provided that, and any change of verb. Each usually marks the boundary of a new obligation hiding inside a long sentence.
Want the full framework with worked examples?
Step 2: Map Obligations to Controls, Owners, and Units
Once obligations are extracted, connect each to the operational reality of the organization. For every obligation, record:
- Control: The existing policy, process, or system that satisfies it (or "none" if there is a gap).
- Owner: The named role accountable for the obligation.
- Business unit: Where the obligation is actually performed.
- Evidence: What demonstrates the control operates.
This is also where one control may satisfy several obligations, and one obligation may rely on several controls. Capturing those many-to-many relationships honestly is what makes the map useful for both efficiency and audit.
An Example Obligation Mapping Table
A mapping table is the workhorse artifact. Here is a representative slice for a data protection regime:
| Obligation | Source | Control | Owner | Business Unit |
|---|---|---|---|---|
| Appoint and register an Information Officer | POPIA s55 | Governance policy GOV-02 | Company Secretary | Legal |
| Maintain records of processing activities | POPIA s17; GDPR Art. 30 | Data inventory register | Data Protection Officer | Compliance |
| Respond to data subject access requests within statutory timeframe | POPIA s23; GDPR Art. 15 | DSAR procedure DS-01 | DPO | Compliance |
| Notify the Regulator of a reportable breach | POPIA s22; GDPR Art. 33 | Incident response IR-04 | Head of InfoSec | IT Security |
| Obtain consent for direct marketing | POPIA s69 | Consent management platform | Marketing Director | Marketing |
Notice that one obligation, records of processing, is satisfied once but driven by two sources. That is the efficiency mapping delivers: satisfy overlapping requirements with a single control.
Step 3: Build an Obligation Library
An obligation library is the consolidated, reusable repository of all mapped obligations across every regulation. Where a single mapping exercise covers one law, the library spans all of them and becomes the master source from which compliance registers are populated.
A good library organizes obligations by regulatory domain (privacy, financial, employment, environmental), tags each with applicability criteria (which entities, which jurisdictions), and versions each obligation so historical states are preserved. This structure is what lets a global organization answer "which of our obligations apply to the Kenyan subsidiary?" in seconds rather than weeks.
Important
Do not let the library become a dumping ground of copied legal text. Each entry must be a decomposed, plain-language obligation with applicability tags. A library of pasted statutes is just the legislation again. It adds no operational value and nobody will use it.
Step 4: Keep the Map Current as Laws Change
Regulation is not static. Amendments, new regulations, regulator guidance, and court interpretations all change obligations. A mapping that is not maintained silently rots, and the gap between what the law now requires and what your register says becomes invisible risk.
Maintaining the map well means:
- Horizon scanning: Monitor the gazette, regulator publications, and reputable legal updates for changes affecting your domains.
- Impact assessment: When a change lands, identify which obligations it adds, amends, or removes. You assess the deltas, not the whole act.
- Versioning: Record the effective date of each change so you can prove what you were required to do at any point in time.
- Propagation: Push the change through to the compliance register and re-run a targeted gap analysis on affected obligations.
This is closely tied to how you track compliance obligations over their lifecycle.
Common Mistakes to Avoid
1. Mapping at the wrong altitude
Mapping a whole act to one obligation hides requirements; mapping every comma to a separate obligation creates noise. Aim for one obligation per distinct, ownable requirement.
2. Mapping to departments instead of roles
"Finance owns it" is not ownership. Map to a named role that can actually be held accountable.
3. Ignoring contractual and standards obligations
Statutory law is not the only source. Customer contracts, certifications, and internal standards generate binding obligations too.
4. Treating mapping as a one-off
A map produced once and shelved is obsolete within a regulatory cycle. Maintenance is part of the discipline, not an optional extra.
5. No traceability to source
If an obligation cannot be traced back to a specific clause, you cannot defend it, update it, or prove it was required. Always cite the source.
Summary
- Obligation mapping translates dense regulation into discrete, ownable obligations
- Decompose each provision into atomic obligations, then map each to a control, owner, and business unit
- A mapping table is the core artifact; an obligation library is the reusable repository across all regulations
- One control can satisfy multiple obligations, and overlapping sources can share a control
- Mapping must be maintained as laws change, with horizon scanning, versioning, and propagation keeping it alive
Frequently Asked Questions
How is obligation mapping different from a compliance register?
Mapping is the analytical process of breaking regulations into obligations and connecting them to controls and owners. The compliance register is the maintained record that results, enriched with status, evidence, and due dates. Mapping is the activity; the register is the durable output.
Who should perform obligation mapping?
Typically the compliance or legal function leads it, because interpreting regulation requires legal literacy. But mapping is best done collaboratively, with control and business-unit owners confirming which controls actually satisfy each obligation. A map built in legal isolation often misattributes controls.
How granular should each obligation be?
Each obligation should represent one distinct requirement that a single owner can be accountable for and a single control can satisfy. If you find yourself naming two owners or two controls for one obligation, it probably needs to be split.
Can one control satisfy multiple obligations?
Yes, and capturing that is one of mapping's biggest benefits. An incident response procedure might satisfy breach-notification obligations under several different regulations at once. Mapping the many-to-many relationship lets you maintain one control instead of duplicating effort per law.
How do I keep the obligation library current?
Run continuous horizon scanning for regulatory change, assess the impact of each change on specific obligations, version the affected entries with effective dates, and propagate updates into the compliance register. The goal is to change only the affected deltas, not re-map the entire law.
Does obligation mapping only cover statutory law?
No. Binding obligations also arise from customer and vendor contracts, certifications you hold (such as ISO standards), industry codes, and internal policies. A complete obligation library maps all of these sources, not just legislation, because all of them can generate findings or breaches.
Save this guide for later
Download the PDF version to read offline or share with your team.
