Most ISO 37301 implementations live or die by the quality of the obligation register. Auditors will spend more time in this single artefact than in any other part of the management system, because it is where they can quickly tell whether the compliance function actually understands what the organisation is bound by, or whether it has produced a document because the standard required one.
The two failure modes are equally common. The shallow register lists "GDPR" and "anti-money laundering regulations" as line items, with no breakdown of the actual obligations underneath. The bloated register has 2,400 rows of every clause of every regulation copy-pasted from a legal database, with no prioritisation, no ownership, and no link to controls. Neither is what the standard wants.
What an Obligation Actually Is
An obligation under ISO 37301 is not a regulation. It is a specific requirement that imposes an action, a prohibition, or a condition on the organisation. "GDPR" is not an obligation. "Notify the supervisory authority of a personal data breach within 72 hours of becoming aware" is. The granularity matters because obligations are what controls map to. You cannot control "GDPR." You can have a documented breach notification procedure that controls the 72-hour notification obligation.
The Fields That Matter
- Obligation ID — a stable identifier that survives renumbering
- Source — the specific law, regulation, contract, or standard the obligation comes from
- Article or section reference — auditors will check this
- Plain-language description — what the organisation must, must not, or may do
- Applicability — which entities, jurisdictions, or activities the obligation applies to
- Owner — a named role accountable for compliance with this obligation
- Linked controls — the controls or processes that achieve compliance
- Evidence type — what artefact demonstrates compliance during an audit
- Compliance status — current assessment, with date
- Review frequency — how often the obligation is checked for change
The applicability field is where most registers fail. Multinational organisations apply obligations universally when many only apply to specific entities or jurisdictions. The result: a US subsidiary is treated as if it must comply with German employment law, the German subsidiary is treated as if it must comply with the California Consumer Privacy Act, and the auditor sees that the register is not actually used to scope compliance work.
How to Build It Without Drowning
Start with categories, not individual obligations. Identify your obligation domains: privacy, anti-bribery, sanctions, employment, sector-specific regulation, contractual obligations, voluntary commitments. For each domain, identify the primary sources. Within each source, extract obligations at the level where they impose distinct actions. A regulation with 200 articles might produce 30–50 obligations once duplicates and non-applicable provisions are removed.
Prioritise. Not all obligations have equal weight. Rank them by likelihood and impact of non-compliance — financial penalties, regulatory action, reputational damage, operational consequence. The first iteration should focus on the high-priority obligations. Comprehensive coverage is a year-two goal, not a year-one requirement.
Keeping It Alive
A static register decays fast. Regulations change, new commitments are made, new entities are acquired. The standard expects a defined process for monitoring obligations and updating the register. In practice this means a documented intake process for regulatory changes (often subscribed via a horizon-scanning service), a quarterly review cadence for high-priority obligations, and annual review for the full register. The auditor will want to see evidence the process has been run, not just that it was documented.
A credible obligation register is the spine of an ISO 37301 management system. Get it right and the rest of the system has something to hang on. Get it wrong and you spend the implementation rebuilding it from the bottom up under audit pressure.