Quick Read
Clause 4.5 of ISO 37301 requires an organisation to systematically identify its compliance obligations, understand their implications for its activities, keep them documented and keep them current. It is the one major requirement with no real equivalent in ISO 37001, and it is the foundation on which everything else in the standard is built. Most organisations believe they already have one. What they usually have is a list of applicable laws maintained by the legal team. A list of laws cannot be risk-assessed, cannot be mapped to controls and cannot be owned. This paper explains what a register that survives a certification audit actually contains, how to build it, and how to keep it alive.
Executive Summary
You cannot manage obligations you have not identified. That sentence is so obvious that most organisations never test whether it is true of them. They assume that because the legal team tracks regulatory change, and because each business function knows the rules that apply to it, the organisation’s obligations are known. In practice the knowledge is fragmented, informal, held by individuals and impossible to audit.
ISO 37301 Clause 4.5 removes that assumption. It requires the organisation to identify its compliance obligations systematically, to determine how they apply to its activities, products and services, to maintain them as documented information, and to have processes to identify new and changed obligations so that the system stays current. Compliance obligations include both the requirements the organisation must comply with — laws, regulations, permits and licences, regulator orders and rules, court judgments, treaties — and the requirements it voluntarily chooses to comply with, such as contractual obligations, agreements with customers and public authorities, industry codes, adopted standards, its own policies and public commitments.
The register matters because every downstream requirement depends on it. The compliance risk assessment under Clause 4.6 assesses the risk of breaching obligations. Controls under Clause 8.2 exist to satisfy obligations. Indicators measure performance against obligations. A register that is incomplete, out of date or pitched at the wrong level of detail makes the entire system unreliable — and an auditor will find that quickly.
This paper sets out what Clause 4.5 requires, why the typical “law list” fails, the anatomy of an auditable register, a method for building it, how to keep it current, and what Speeki’s auditors test.
CORE ARGUMENT A law is not an obligation. An obligation is a specific requirement, owned by a named role, embedded in a defined process, and capable of being breached. Until the register reaches that level, it is a library catalogue, not the foundation of a management system. |
1. What Clause 4.5 Requires
Clause 4.5 is short, but each element carries weight. In substance, the organisation is required to:
Identify its compliance obligations systematically, including both mandatory requirements and voluntary commitments, arising from its activities, products and services.
Assess how those obligations affect its operations — which activities, processes and roles they touch.
Maintain the obligations as documented information, so that they can be referenced, reviewed and audited.
Keep them current through processes that identify new and changed obligations and evaluate their impact, so that the management system is updated when the obligations change.
Clause 4.5 does not stand alone. It is the input to Clause 4.6 (compliance risk assessment), it is engaged by Clause 6.3 (planning of changes) whenever a change in obligations requires a change to the system, and it is the reference point for Clause 8.2, which requires controls to manage the organisation’s compliance obligations and associated risks.
1.1 Why ISO 37001 users have not built this yet
Organisations certified to ISO 37001 often assume Clause 4.5 is familiar. It is not. In ISO 37001, the obligation is effectively given: do not bribe and do not be bribed, under the anti-bribery laws that apply. The work lies in the risk assessment and controls. ISO 37301 reverses the emphasis. Because the standard can cover any domain — data protection, sanctions, competition, product safety, environmental permits, financial services conduct rules, aviation or workplace safety — the organisation must first establish what it is actually obliged to do. For most ISO 37001-certified organisations this is the largest genuinely new piece of work in moving to ISO 37301.
AUDITOR’S VIEW When Speeki audits Clause 4.5, the first question is not “do you have a register?” but “show me how this obligation got into the register, who owns it, and what changed the last time the underlying law changed.” |
1.2 The 2024 climate amendment
In 2024 ISO amended ISO 37301, along with most management system standards, to require the organisation to determine whether climate change is a relevant issue when it establishes its context, and to recognise that interested parties may have climate-related requirements. For the register, the practical consequence is that climate-related disclosure laws, climate commitments made to customers or investors, and public net-zero pledges must be considered as candidate compliance obligations. Where the organisation concludes they are not relevant to the scope, that conclusion should be documented.
2. Why the Law List Fails
The most common artefact presented as an obligations register is a spreadsheet of applicable laws: the statute, the jurisdiction, perhaps a summary and the name of an internal lawyer. It fails for five reasons.
Failure | Why it matters |
|---|---|
Wrong unit of analysis | A single regulation may contain dozens of distinct requirements touching different functions. Listing the regulation tells no one what they must do, and cannot be risk-assessed or controlled. |
No ownership | The lawyer who monitors the regulation is rarely the person who must comply with it. Without an operational owner, no one is accountable for meeting the obligation day to day. |
No process link | If the obligation is not mapped to the process where it is met or breached, controls cannot be designed and evidence cannot be located. |
Mandatory requirements only | Voluntary commitments — customer codes, industry charters, public sustainability pledges, certification scheme rules — are compliance obligations once adopted. They are routinely omitted. |
Static | The list is refreshed annually. Regulatory change, new contracts, new markets and new products in between are not captured, so the register describes last year’s organisation. |
COMMON FINDING An organisation presents a register listing its national data protection law. Its marketing team runs campaigns in four further jurisdictions, its HR system is hosted offshore and it has signed customer data processing agreements with obligations stricter than the law. None of these appear. The register is accurate and almost useless. |
3. Anatomy of an Auditable Register
3.1 The four sources of obligations
ISO 37301 sorts compliance obligations into two classes: requirements the organisation must comply with, and requirements it voluntarily chooses to comply with. Annex A.4.5 places contractual arrangements, agreements with customers and public authorities, codes of practice and the organisation’s own policies in the second class — once the organisation has entered into or adopted them, they are compliance obligations. The four-source view below is a practical way to make sure neither class is missed. Most organisations cover the first source and neglect the others.
Source | Examples | Commonly missed |
|---|---|---|
Law and regulation | Statutes, regulations, regulator rules and guidance with binding effect, case law | Secondary rules, regulator guidance treated as binding in practice, extraterritorial laws |
Permits, licences and authorisations | Operating licences, environmental permits, regulatory approvals, certifications held | Conditions attached to licences; reporting deadlines in permits |
Contracts | Customer, supplier, financing and joint venture agreements; data processing agreements | Customer codes of conduct; audit rights; flow-down obligations; loan covenants with compliance terms |
Voluntary commitments | Industry codes, adopted standards, public pledges, membership rules, the organisation’s own policies | Public sustainability commitments; certification scheme rules; commitments made in tenders |
3.2 The minimum data fields
Annex A.4.5 recommends that, where appropriate, the organisation keeps a single register or log setting out all of its compliance obligations, with a process for updating it regularly, and that the register records for each obligation its impact, how it is managed, the controls linked to it and the risk assessment. It also recommends identifying obligations by department, function and type of activity, so that it is clear who is affected, and taking a risk-based approach that starts with the obligations most important to the business. The fields below build on that guidance.
Each register entry should describe one obligation at the level at which it can be owned, controlled and breached. The fields below are the minimum Speeki’s auditors expect to be able to trace.
Field | Content |
|---|---|
Obligation ID | Unique reference that persists through revisions |
Source | Instrument and specific provision (section, article, clause, condition) |
Type | Mandatory requirement or voluntary commitment |
Obligation statement | What the organisation must do or not do, in plain operational language |
Jurisdiction / applicability | Where and to which entities, sites or products it applies |
Activities and processes affected | The business processes in which the obligation is met or could be breached |
Operational owner | The role accountable for meeting the obligation day to day |
Subject-matter adviser | The role responsible for interpreting it and tracking change |
Linked risk(s) | Reference to the compliance risk assessment entries (Clause 4.6) |
Linked controls | Reference to the controls designed to satisfy it (Clause 8.2) |
Evidence of compliance | What records demonstrate it is being met |
Consequence of breach | Sanction, licence, contractual or reputational consequence — feeds risk scoring |
Change monitoring | How and by whom changes to the source are tracked |
Last reviewed / next review | Dates, and what triggered the last review |
3.3 The right level of granularity
Granularity is the hardest judgement. Too coarse and the register cannot drive controls; too fine and it becomes unmaintainable. A practical rule is that an entry should be split if different parts of it are owned by different roles, met in different processes, or carry materially different consequences of breach. An entry can be grouped if the same owner meets it through the same control with the same evidence.
Too coarse | About right | Too fine |
|---|---|---|
“Comply with the national data protection law” | “Respond to data subject access requests within the statutory deadline” — owner: privacy operations; process: DSAR handling | A separate entry for every sub-paragraph describing the content of a DSAR response |
“Comply with sanctions laws” | “Screen all new counterparties against applicable sanctions lists before onboarding” — owner: onboarding; process: customer and supplier onboarding | One entry per sanctions list |
“Comply with the operating licence” | “Submit the annual compliance return to the regulator by the licence deadline” — owner: regulatory affairs | Separate entries for each data field in the return |
4. Building the Register
Building a register from nothing is a substantial exercise, but it follows a repeatable sequence. The sequence below assumes the scope of the management system has been defined (see Paper 4).
Map activities first, not laws. List the organisation’s in-scope activities, products, services, sites and jurisdictions. Obligations attach to activities; starting from activities exposes obligations that a law-first approach misses.
Identify sources per activity. For each activity, identify the laws, permits, contracts and commitments that apply, using internal legal, external counsel, regulatory databases and industry bodies.
Decompose sources into obligations. Break each source into specific requirements at the granularity described above.
Assign ownership. For each obligation, agree an operational owner and a subject-matter adviser. Owners must accept the obligation explicitly; an obligation assigned without acceptance is not owned.
Map to processes and evidence. Record where each obligation is met and what evidence shows it.
Capture consequence. Record the consequence of breach; this is the most important input to risk scoring.
Validate with the business. Walk each function through its obligations. Missing obligations surface quickly when operators see the list.
Approve and baseline. Have the register approved through the compliance governance line and version-controlled.
TECHNOLOGY NOTE AI can now accelerate decomposition of regulatory texts and contracts into candidate obligations dramatically. It does not remove the need for human judgement on applicability, ownership and consequence. Auditors will ask how machine-generated entries were validated, and by whom. |
4.1 Leverage what already exists
Organisations rarely start from zero. ISO 37001 systems contain the anti-bribery obligations. ISO 14001 and ISO 45001 systems already require registers of compliance obligations and legal requirements. Information security and privacy programmes maintain their own registers. Contract management systems hold contractual obligations. The ISO 37301 register should integrate these rather than duplicate them, with a single structure and consistent fields across domains.
5. Keeping the Register Alive
A register is only as good as its last update. Clause 4.5 requires processes to identify new and changed obligations, and Clause 6.3 requires changes to the management system to be planned. The register therefore needs both scheduled review and event-driven triggers.
Trigger | Example | Who detects it |
|---|---|---|
Regulatory change | New regulation, amended rule, new regulator guidance, enforcement trend | Subject-matter advisers; regulatory monitoring service |
New market or jurisdiction | Entering a new country, launching online sales into a new region | Strategy, commercial, compliance function |
New product or service | A product subject to new safety or labelling rules | Product development gate |
New or amended contract | A major customer imposing a supplier code; a loan with compliance covenants | Legal and procurement contract workflow |
New commitment | A public pledge, a new certification, joining an industry initiative | Communications, sustainability, executive team |
Organisational change | Acquisition, restructuring, outsourcing a process | Corporate development; compliance function |
Incident or finding | A breach, regulator inquiry or audit finding that reveals an unrecognised obligation | Investigations, internal audit |
Each trigger must be wired to an existing business process — the product approval gate, the contract approval workflow, the acquisition checklist — so that obligation identification happens as part of normal work rather than relying on someone remembering to tell the compliance function.
THE CHANGE TEST An auditor will select a regulatory change from the last twelve months and ask the organisation to show when it was identified, how its impact was assessed, which register entries changed, which risks were re-scored and which controls were altered. Each missing step is evidence that the register is not alive. |
6. Implementation Roadmap
A first-generation register for a mid-sized multinational can be built in roughly a quarter if the work is sequenced properly. The sequence matters more than the speed: building the register before agreeing its data model is the most common source of rework.
Phase | Timing | Activities | Output |
|---|---|---|---|
1. Design | Weeks 1–3 | Agree the data model and granularity rule; confirm scope boundaries; decide where the register will live; nominate source owners for each obligation domain. | Register specification approved by the head of compliance |
2. Harvest | Weeks 3–7 | Collect what already exists: ISO 37001 legal registers, licence and permit lists, contract obligation trackers, privacy records of processing, regulatory-filing calendars, policy commitments. | Raw obligation inventory, de-duplicated |
3. Decompose | Weeks 6–10 | Break each source into discrete, breachable obligations; map each to activities, processes, locations and owning roles; record jurisdiction and source reference. | Draft register at operational granularity |
4. Validate | Weeks 9–11 | Owners confirm their obligations in workshops; legal confirms interpretation of high-consequence items; gaps identified against industry enforcement history. | Owner-confirmed register |
5. Connect | Weeks 10–13 | Link obligations to the compliance risk assessment and to existing controls; flag obligations with no control. | Register feeding Clauses 4.6 and 8.2 |
6. Maintain | Ongoing | Activate horizon scanning, change triggers and periodic owner attestation; report register changes to management review. | Living register with change log |
7. Common Failures
Beyond the structural weakness of the “law list”, registers that start well tend to decay. These are the failure patterns Speeki most often sees in the second and third year of a system.
Failure | Consequence | What a sound register does instead |
|---|---|---|
Horizon scanning feeds the legal team but not the register | New obligations are known about but never reach owners, risk assessment or controls. | Every regulatory change assessed as relevant produces a register entry, an owner notification and a risk reassessment trigger. |
Voluntary commitments left out | Public pledges, customer codes and industry standards create exposure that is never managed. | Treats commitments the organisation has chosen to adopt as compliance obligations once adopted. |
Owners are departments, not roles | No individual can be asked whether the obligation is met. | Assigns each obligation to a named role, with a deputy. |
Contractual obligations ignored | Customer and financing contracts often impose the most specific, auditable compliance duties. | Includes recurring contractual compliance obligations above a defined materiality threshold. |
Register frozen at certification | The register describes the organisation as it was at Stage 2. | Maintains a change log and evidences review at planned intervals and on trigger events. |
One global entry for multi-jurisdiction obligations | Local variation, often where breaches actually happen, is invisible. | Records jurisdiction-specific variants where requirements materially differ. |
8. What Speeki’s Auditors Test
8.1 Document review
The register itself: granularity, completeness across the four sources, ownership and links to risks and controls.
The procedure for identifying and updating obligations, including triggers and responsibilities.
Evidence of review: version history, change log and approvals.
8.2 Completeness testing
Auditors independently identify obligations that should apply — from the organisation’s licences, its largest contracts, its public statements and the jurisdictions it operates in — and check whether they appear. Where Speeki has access to contract repositories or permit files, full-population comparison is possible: every licence condition or contract clause can be checked against the register, rather than a sample.
8.3 Interviews
Operational owners: “Which obligations do you own? How do you meet them? How would you know if you had breached one?”
Subject-matter advisers: “What changed in your area this year, and what did you do about it?”
Commercial and procurement: “When you sign a contract with compliance terms, how does the compliance function find out?”
Finding pattern | Typical grading |
|---|---|
No register, or a list of laws only, for the in-scope domain | Major nonconformity |
Register exists but no process to identify new or changed obligations | Major or minor, depending on evidence of change being missed |
Voluntary commitments or contractual obligations systematically omitted | Minor nonconformity |
Obligations without operational owners | Minor nonconformity |
Register not linked to risk assessment or controls | Minor nonconformity, often escalating at surveillance |
Grading is illustrative. Actual grading depends on the auditor’s evaluation of evidence and effect on the system.
Conclusion
The obligations register is the least glamorous element of a compliance management system and the most consequential. Every other element of ISO 37301 depends on it. A register at the wrong level, without owners or without a change process cannot support a risk assessment, cannot justify controls and cannot be audited.
The organisations that do this well treat the register as an operational asset rather than a legal library: obligations are written in operational language, owned by the people who meet them, connected to the processes where they are met, and updated automatically when the business changes. Once that foundation exists, the rest of the system has something real to manage.
About Speeki
Speeki is an accredited certification body operating across more than 100 countries, providing ISO management system certification, ESG and sustainability assurance, and executive education. Speeki provides no consulting of any kind. Our independence is structural, not a promise.
Speeki delivers its audits through AI working alongside a body of experts. Nicole, Speeki’s AI team member, works with our auditors to test full populations of evidence rather than samples, so that certification reflects how a management system actually performs, not how it looks on the day of the audit.
To learn more, see ISO 37301 certification with Speeki.
Related Reading
Paper 3 — Compliance Risk Assessment at the Obligation Level (Clause 4.6)
Building an Applicable Obligations Register That Survives an Audit — SPK DDMS2000:2026 Section 6.1
The Obligations Register and Why It Comes First — SPK CSMS1000:2026 Clause 6.1
This whitepaper provides general information on ISO 37301:2021 and does not reproduce the text of the standard. Organisations should refer to the published standard for its exact requirements.