Most organizations know which laws apply to them in broad terms. Very few can point to a single document that lists every obligation, who owns it, which control satisfies it, and the evidence that proves it. That document is the compliance register, and it is the difference between a compliance program you can demonstrate and one you merely hope is working. This guide explains what a compliance register is, the fields it needs, and exactly how to build one.
What You'll Learn
By the end of this guide you will understand what a compliance register is, which fields make it useful rather than decorative, how to build one in seven concrete steps, and how it connects to obligation mapping and your risk register so the three reinforce each other instead of duplicating work.
What a Compliance Register Is
A compliance register (also called a compliance obligations register or regulatory register) is a structured record of every legal, regulatory, contractual, and standards-based obligation an organization has to meet, together with the control, owner, evidence, and status for each one.
Think of it as the operational counterpart to a wall of legislation. A regulation tells you what the law requires. A compliance register tells you what your organization specifically must do about it, who is doing it, whether it is being done, and how you would prove it to an auditor or regulator. Without a register, compliance lives in people's heads, in scattered policies, and in email threads, which means it cannot be managed, reported on, or defended.
A good register answers four questions for any obligation at a glance:
- What do we have to do? The obligation, stated as a discrete requirement.
- Why do we have to do it? The source regulation, clause, or contract.
- Who is accountable? A named owner, not a department.
- How do we know it is happening? The control and the evidence.
Why a Compliance Register Matters
Organizations without a compliance register tend to share the same symptoms: obligations discovered only when a regulator asks about them, duplicated effort across teams reading the same statute, and no way to answer "are we compliant?" with anything more confident than "probably."
1. A single source of truth
The register pulls obligations from every applicable source into one place: data protection law, sector regulation, tax rules, contractual commitments, internal standards. Leadership stops relying on tribal knowledge and starts relying on a maintained record.
2. Demonstrable accountability
Every obligation has a named owner. When a control fails or a deadline slips, there is no ambiguity about who was responsible. This is the foundation of being able to assign compliance ownership credibly.
3. Audit and regulator readiness
Auditors and regulators do not just want to hear that you comply. They want to see it. A register that links each obligation to a control and to compliance evidence turns an anxious scramble into a routine export.
4. Prioritization and resourcing
Not all obligations carry equal consequence. A register lets you see which obligations are overdue, which are high-penalty, and where control coverage is thin, so effort flows to where it matters.
Want the full framework with worked examples?
Core Fields of a Compliance Register
A register is only as useful as its fields. Too few and it is a glorified to-do list. Too many and nobody keeps it current. The following set is the practical core that works for most organizations.
| Field | Purpose | Example |
|---|---|---|
| Obligation ID | Unique identifier for tracking and cross-referencing | OBL-2026-018 |
| Obligation | The discrete requirement stated in plain language | Notify the regulator of a reportable data breach within 72 hours |
| Source Regulation | The law, clause, standard, or contract it derives from | POPIA s22; GDPR Art. 33 |
| Owner | The named individual accountable for the obligation | Head of Information Security |
| Control | The process, policy, or system that satisfies the obligation | Incident response procedure IR-04 |
| Evidence | What proves the control is operating | Breach log, regulator notification records |
| Status | Current state of compliance | Compliant / Partial / Non-compliant / Not assessed |
| Due / Review Date | Next action deadline or reassessment date | 30 June 2026 |
| Frequency | How often the obligation recurs | Event-driven / Annual / Quarterly |
| Linked Risk | The risk register entry for non-compliance | R-2026-091 (Regulatory penalty) |
Pro Tip
Keep the obligation text in plain language, separate from the source citation. Auditors and regulators read the citation; the people who actually do the work read the plain-language obligation. Mixing the two into one cell slows both audiences down.
Step 1: Define Scope and Sources
Before listing a single obligation, decide what the register covers. A register that tries to capture everything at once usually captures nothing well. Establish boundaries:
- Entities and geographies: Which legal entities, countries, or branches are in scope?
- Obligation types: Statutory law only, or also contractual commitments, certifications, and internal standards?
- Source list: Build a list of the regulations and standards that apply, covering data protection, employment, tax, sector-specific licensing, anti-money-laundering, health and safety, and so on.
Document the source list explicitly. It becomes the input to regulatory obligation mapping, the next step that turns each source into discrete obligations.
Step 2: Extract Discrete Obligations
Regulations are written as continuous prose. A register needs atomic, actionable obligations. Work through each source and break it into individual "shall" statements, each one a single thing the organization must do, by whom, and by when. This is the heart of obligation mapping, covered in depth in our guide to regulatory obligation mapping.
From regulation to obligations
Source text: "A responsible party must secure the integrity and confidentiality of personal information by taking appropriate, reasonable technical and organisational measures, and must notify the Regulator and the data subject where there are reasonable grounds to believe personal information has been accessed by an unauthorised person."
Obligation 1: Implement and maintain technical and organisational security measures for personal information. (Control: ISMS; Owner: CISO)
Obligation 2: Notify the Regulator of a confirmed unauthorised-access breach. (Control: IR-04; Owner: Head of InfoSec)
Obligation 3: Notify affected data subjects of the breach. (Control: IR-04; Owner: DPO)
Step 3: Assign Owners and Controls
An obligation without an owner is an obligation nobody is doing. For each obligation, name a single accountable individual. A role title is acceptable, but a generic "Legal team" is not. Then link the obligation to the control that satisfies it.
Often a control already exists, and the register simply documents the link. Sometimes the mapping exposes an obligation with no control behind it. That is a gap, and it should flow into a compliance gap analysis for remediation rather than being quietly marked compliant.
Important
Do not assign ownership to whoever happens to be in the room. The owner must have the authority and the budget to actually maintain the control. Assigning an obligation to someone who cannot influence it creates the appearance of accountability without the substance.
Step 4: Capture Evidence and Set Status
For each obligation, record what evidence demonstrates the control is operating: logs, signed records, training completion reports, system configurations, or attestations. Then assign an honest status. A simple, consistent scale works best:
| Status | Meaning | Action |
|---|---|---|
| Compliant | Control exists, operates, and evidence is current | Monitor and review on schedule |
| Partial | Control exists but coverage or evidence is incomplete | Remediation action required |
| Non-compliant | No effective control, or the control has failed | Escalate and prioritize |
| Not assessed | Obligation logged but not yet evaluated | Schedule assessment |
The discipline of capturing evidence at this stage is what makes the register defensible later. For why this matters so much, see what compliance evidence is and why it matters.
Step 5: Add Due Dates and a Calendar
Many obligations recur: annual returns, quarterly reports, periodic training, licence renewals. Record a frequency and a next due date for each, and surface recurring deadlines through a compliance calendar so nothing falls through the cracks between reviews. Event-driven obligations such as breach notification get a trigger condition rather than a date, but they should still be tested periodically.
Step 6: Link to the Risk Register
The compliance register and the risk register are distinct but connected. Each significant obligation has a corresponding risk: the risk of failing to meet it. Linking the two means a non-compliant obligation automatically surfaces as a live risk with a likelihood, an impact, and a treatment plan. This relationship is explored further in our guide on how risk registers support compliance.
In practice, link by ID: obligation OBL-2026-018 references risk R-2026-091. When the obligation's status drops to non-compliant, the linked risk's residual rating should rise accordingly.
Step 7: Maintain and Report
A register built once and never touched is worse than none, because it creates false confidence. Maintenance has three rhythms:
- On change: When a law is amended or a new regulation takes effect, update the affected obligations promptly.
- On schedule: Review each obligation's status and evidence on its review cadence, with high-consequence obligations reviewed more often.
- On event: After an incident, audit finding, or near-miss, revisit the related obligations and controls.
Reporting closes the loop. Leadership and the board should receive a periodic compliance status summary drawn directly from the register. For the mechanics, see how to track and report compliance status and how to track compliance obligations over time.
Common Mistakes to Avoid
1. Treating it as a one-time project
A register compiled for an audit and then abandoned drifts out of date within months. Build maintenance cadences in from day one.
2. Logging laws instead of obligations
"We comply with POPIA" is not an obligation. It is a wish. Break each law into discrete, ownable obligations or the register cannot drive action.
3. Vague ownership
Assigning obligations to teams rather than named roles guarantees that everyone assumes someone else is handling it.
4. No evidence trail
A status of "compliant" with nothing behind it collapses the moment an auditor asks "show me." Evidence is the point, not an afterthought.
5. Disconnecting it from risk
When the compliance register and risk register live in separate worlds, non-compliance never surfaces as a managed risk, and remediation never gets prioritized.
Summary
- A compliance register records every obligation alongside its source, owner, control, evidence, status, and due dates
- It turns a wall of regulation into a managed, reportable, auditable list
- Build it in steps: define scope, extract obligations, assign owners and controls, capture evidence and status, add due dates, link to risk, and maintain
- It depends on obligation mapping for its inputs and feeds the risk register and gap analysis for outputs
- Maintenance and evidence are what make it credible, because a static register creates false confidence
Frequently Asked Questions
What is the difference between a compliance register and a risk register?
A compliance register lists the obligations you must meet and tracks whether you are meeting them. A risk register lists the risks you face and how you treat them. They overlap because failing an obligation is a risk, so best practice is to link the two by ID and let non-compliance surface automatically as a managed risk.
Can I build a compliance register in a spreadsheet?
Yes, and many organizations start there. A spreadsheet works for a small obligation set. As the register grows, the weaknesses show: no automated due-date reminders, no audit trail of who changed what, and difficulty linking obligations to controls, evidence, and risks. Dedicated compliance software solves these as the program matures.
How many obligations should a register contain?
It depends entirely on your regulatory footprint. A single-jurisdiction small business might have 30 to 60 obligations; a multinational in a regulated sector can have several hundred. The right number is however many discrete obligations actually apply, not an arbitrary target. Quality of decomposition matters more than count.
Who should own the compliance register overall?
The compliance officer or equivalent typically owns the register as a whole, meaning its structure, completeness, and reporting. Individual obligations, however, should be owned by the managers responsible for the relevant business areas. The compliance function curates and consolidates; ownership of doing the work is distributed. See how to assign compliance ownership.
How often should the register be reviewed?
High-consequence obligations should be reviewed quarterly or on every recurrence; lower-consequence ones at least annually. Beyond the calendar, review whenever a relevant law changes, a contract is signed, or an incident occurs. A compliance calendar helps surface these review points automatically.
Where does a compliance register get its content from?
Its inputs come from regulatory obligation mapping, the process of reading each applicable regulation and breaking it into discrete obligations. The register is essentially the durable, maintained output of that mapping exercise, enriched with owners, controls, evidence, and status.
Save this guide for later
Download the PDF version to read offline or share with your team.
