ISO Compliance Insights & Best Practices

Compliance Obligations Register: A Clear Guide for ISO 37301

A compliance obligations register is the artifact ISO 37301 builds everything else on, and it is the one most organizations discover they do not really have. Clause 4.5 requires compliance obligations to be identified; clause 4.6 requires the compliance risks associated with them to be assessed. Both sit in the context clause — before leadership, before planning — because nothing downstream means anything until you know what actually binds you.

This guide covers what belongs in the register, the columns that make it usable, how the risk assessment attaches to it, and the maintenance that keeps it true.

Compliance obligations register: the columns and where ISO 37301 requires each — One row per obligation, with the risk assessment attached rather than kept separately.

What counts as a compliance obligation

Wider than most first drafts assume. A compliance obligations register should capture requirements the organization must comply with and those it chooses to comply with:

Law and regulation in every jurisdiction you operate in, including the ones you reach only through a subsidiary or a remote employee.
Permits, licences and authorizations, with their conditions — the conditions are where the enforceable detail lives.
Regulatory decisions, orders and undertakings given to a regulator.
Contractual commitments to customers and suppliers, including the compliance clauses nobody reads at signature.
Industry codes and standards you have adopted, and certification requirements you hold.
Voluntary commitments — public pledges, codes of conduct, group policies imposed by a parent.

The last category is the one that surprises people. A voluntary commitment, once made publicly, becomes a compliance obligation in the standard’s terms — and an auditor will ask how you assure it.

The columns a compliance obligations register needs

Column	What it holds, and why
Reference	A stable internal identifier, so other documents can cite the obligation
Source	The instrument and the specific article, clause or condition — not just its title
Requirement	What it obliges you to do, in your own words, at a level someone can act on
Jurisdiction and entity	Where and to which legal entity it applies — the column that stops a group register becoming fiction
Owner	The named role accountable for meeting it, in the business rather than in compliance
Controls and evidence	How it is met, and what you would show — the link to the policy, process or record
Compliance risk	Likelihood of failure and consequence if it fails, per clause 4.6
Status and last review	Whether it is currently met, when that was last established, and by whom

Two columns do the heavy lifting. Source has to be specific to the clause: “the GDPR” is not an obligation, “Article 30 — maintain records of processing activities” is, because only the second can be tested. And owner has to be a business role. A register where compliance owns every line records the compliance function’s workload, not the organization’s obligations.

Attaching the compliance risk assessment

Clause 4.6 asks for the compliance risks to be assessed — identifying them by relating obligations to activities, products, services and operations, and analysing their consequences and likelihood. The efficient way to satisfy it is to assess in the register rather than in a separate document, so each obligation carries its own risk position.

Three practices keep that honest:

Score consequence beyond the fine. Regulatory penalty is one axis; licence conditions, contract termination rights, director liability and the cost of remediation are others. Several obligations with modest fines carry existential consequences.
Score likelihood against the control, not the intention. The question is how likely you are to fail given how the process actually runs today — including how it runs when the person who normally does it is away.
Let the score drive the assurance plan. High-risk obligations get tested; low-risk ones get confirmed. If everything is monitored at the same frequency, the assessment is decorative.

Keeping the compliance obligations register true

A compliance obligations register decays faster than any other compliance artifact because the law moves without asking. Four habits keep it current:

Assign horizon scanning to a named role, with the sources it monitors listed. “We follow the regulators” is not a process.
Trigger a review on business change — a new market, product, channel, acquisition or material contract each create obligations, and all four are known in advance.
Record amendments rather than overwriting. When an obligation changes, the previous version and the date it changed are what let you explain a historical position.
Reconcile against the evidence annually. Walk a sample of rows to the artifact named in the evidence column. Rows that cannot be walked are the finding.

The register also feeds the rest of the management system: it scopes the compliance policy, drives the objectives, sets the internal audit programme and populates management review. Our guide to ISO 37301 and what a compliance management system must contain covers those connections, and where anti-bribery obligations are prominent the same register can carry them — see ISO 37001.

Frequently asked questions

Where does ISO 37301 require a compliance obligations register?
Clause 4.5 requires compliance obligations to be identified and clause 4.6 requires the associated compliance risks to be assessed. The standard does not mandate the word “register” — it mandates the outcome, and a register is how organizations achieve it.

Do voluntary commitments belong in it?
Yes. Requirements you choose to comply with sit alongside those you must comply with, and a public commitment you cannot evidence is a compliance risk of its own.

How detailed should each row be?
Specific enough to be testable. One row per discrete requirement beats one row per statute — otherwise the evidence column has to cover a dozen unrelated duties.

Can we merge it with the ISO 14001 or ISO 45001 legal register?
Often yes, and it saves duplication. Keep a column identifying which management system each obligation belongs to so the scopes stay legible at audit.

Who should own the register itself?
The compliance function maintains it; the business owns the lines. Conflating those is why registers go stale — the maintainer cannot know that a process changed.

Where this leaves you

Build the compliance obligations register before anything else in the management system, because clause 4.5 sits where it does for a reason. Cite sources at clause level, put a business owner on every line, assess the compliance risk in the register rather than beside it, and reconcile a sample to the evidence once a year. A register that is specific, owned and current makes the rest of ISO 37301 mostly mechanical; one that lists statutes without owners makes the whole system unauditable.

References

ISO 37301:2021 — Compliance management systems, including clause 4.5 compliance obligations and clause 4.6 compliance risk assessment.
ISO/TC 309 — the committee responsible for governance standards, including ISO 37301 and ISO 37001.