Most security teams can name the frameworks they are certified against but cannot show, on one page, every law, regulation and contract clause that binds them, who owns each one and which control proves it is met. That gap is what an obligations register closes. This template gives [Organisation] a ready-to-use register: the fields, how to break a law into testable obligations, worked example rows, and the rules for keeping it current. It is for GRC, compliance, legal and security teams, and it fits any management system that needs a record of legal, statutory, regulatory and contractual requirements, such as ISO/IEC 27001 or ISO 37301, or the NIST CSF 2.0 outcome GV.OC-03. It complements the Control Mapping Guide, which maps controls between frameworks, and the Compliance Calendar Template, which schedules recurring tasks.
How to use this template
- One row per obligation, not per law. A law such as the GDPR becomes many rows: one for each duty you can assign, test and evidence. "Comply with GDPR" is not a row.
- Link, do not duplicate. The register points to controls, policies and evidence held elsewhere. It is an index, so keep it light enough to maintain.
- Columns marked Core are the minimum. Columns marked Recommended make the register useful for audits, board reporting and change tracking.
- Record applicability reasoning. When an obligation does not apply, keep the row and record why. Auditors and regulators ask about the laws you decided were out of scope.
- Replace the brackets. Text such as [Organisation], [Head of Compliance] and [quarterly] is a placeholder for your names and values.
- The example rows are illustrative. They show the level of detail expected. Confirm every citation against the official text before relying on it.
1. Purpose
This register is [Organisation]'s single record of the compliance obligations that apply to its information security, privacy and operational resilience. For each obligation it records the source, the specific requirement, whether and why it applies, the accountable owner, the controls that meet it, the evidence that proves it and its current status. It supports management review, internal and external audit, regulatory inspections and due diligence requests from customers.
2. Scope
- Mandatory obligations: laws, regulations, delegated and implementing acts, regulator rules, guidance the regulator treats as binding, and court or regulator orders that apply to [Organisation] in every jurisdiction where it operates, holds data or sells services.
- Contractual obligations: security and privacy clauses in customer contracts, data processing agreements, card scheme and payment rules, insurance policy conditions and supplier agreements where [Organisation] gives commitments.
- Voluntary commitments: certifications [Organisation] holds or has committed to (for example ISO/IEC 27001, SOC 2), industry codes and public statements such as published security pages.
- Out of scope: obligations with no security, privacy or resilience component (for example tax filing), which belong in the wider legal register held by [Legal].
3. Definitions
- Compliance obligation: a requirement [Organisation] must meet, or a commitment it has chosen to meet. Treating voluntary commitments as obligations is our recommendation, so that they are owned and evidenced in the same way.
- Source: the instrument the obligation comes from (law, regulation, standard, contract), with article or clause reference.
- Applicability: the documented decision that the obligation applies, partly applies or does not apply, with the reason.
- Control: a policy, process or technical measure in the control library that meets the obligation in whole or in part.
- Evidence: a record that shows the control operated as designed during a stated period.
- Obligation owner: the named role accountable for the obligation being met. Control owners may differ.
4. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [Head of Compliance] (register owner) | Maintains the register, runs the review cycle, reports status to [Risk Committee] |
| [Legal] | Identifies new and changed laws and contracts, confirms applicability decisions and interpretation |
| Obligation owners | Accountable for each obligation being met; approve the control mapping and status |
| Control owners | Operate controls and supply evidence on the agreed schedule |
| [CISO] and [DPO] | Advise on security and privacy obligations; own the controls in their domains |
| [Procurement] and [Sales Operations] | Send new contractual security commitments to the register owner before signature |
| [Internal Audit] | Tests a sample of rows each year for accuracy and evidence quality |
5. Register fields
| Field | Status | What to record |
|---|---|---|
| Obligation ID | Core | Stable unique ID, for example OBL-EU-GDPR-032-01. Never reuse IDs. |
| Source type | Core | Law, regulation, regulator rule, standard, contract, voluntary commitment |
| Source and reference | Core | Instrument name and article, clause or section, with a link to the official text |
| Jurisdiction or counterparty | Core | Country or region for laws; customer or scheme name for contracts |
| Requirement summary | Core | One testable sentence in plain language: who must do what, by when |
| Applicability | Core | Applies, partly applies or does not apply, with the reason and the date decided |
| Business scope | Recommended | Entities, services, systems or data sets the obligation covers |
| Obligation owner | Core | A named role, not a team |
| Mapped controls | Core | Control IDs from the control library, and whether each fully or partly meets the obligation |
| Evidence | Core | Evidence type, location and collection frequency |
| Deadlines and frequencies | Recommended | Fixed time limits in the source (for example notification windows, review cycles); feed these into the compliance calendar |
| Compliance status | Core | Met, partly met, not met, not yet assessed; with the date and the basis of the assessment |
| Gap and action | Recommended | Remediation action, owner and target date, or a link to the risk register entry |
| Consequence of breach | Recommended | Penalty type or contractual remedy as stated in the source; leave blank rather than guess |
| Effective and change dates | Recommended | When the obligation took effect, and known future changes with dates |
| Last reviewed | Core | Date and reviewer |
6. Identifying and decomposing obligations
- Build the source list. List every jurisdiction where [Organisation] is established, has customers or processes data, then the sector regulators that supervise it. The Global Cybersecurity Regulatory Map is a starting point for laws; contract repositories and the sales pipeline are the source for commitments.
- Screen each source for applicability. Record the test the source sets (for example size thresholds, sector lists or data types) and the facts that meet or miss it.
- Decompose to testable duties. Break each applicable source into obligations a single owner can evidence. A reporting article usually becomes several rows: the detection trigger, each notification stage and the record keeping duty.
- Map to controls, not to frameworks. Point each obligation to controls in your own library. Where you already use a common control set, reuse its IDs. See the Control Mapping Guide.
- Agree evidence. For each mapped control, decide what record proves it and how often it is collected. See the Audit Evidence and Continuous Controls Monitoring Guide.
- Confirm with the owner. The obligation owner signs off the summary, mapping and status before the row is marked active.
7. Worked example rows
These rows are illustrative and abbreviated. They show depth, not a complete list for any law.
| ID | Source and reference | Requirement summary | Owner | Mapped controls | Evidence | Status |
|---|---|---|---|---|---|---|
| OBL-EU-GDPR-033-01 | GDPR Art. 33(1) | Notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware, unless unlikely to result in a risk | [DPO] | IR-03 breach assessment; IR-07 regulator notification | Breach register; notification records | Met (tested in [month] exercise) |
| OBL-EU-NIS2-023-01 | NIS2 Art. 23(4)(a), as transposed in [Member State] | Send an early warning to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident | [CISO] | IR-07 regulator notification | Incident tickets with time stamps | Partly met (24-hour route untested) |
| OBL-EU-DORA-RTS21-02 | Delegated Regulation (EU) 2024/1774 Art. 21 | Review access rights at least every 6 months for ICT systems supporting critical or important functions, including non-human accounts | [Head of IAM] | IAM-05 access review; IAM-09 service account review | Review campaign exports and revocation records | Not met (service accounts excluded) |
| OBL-CON-ACME-14-3 | Master services agreement with [Customer], clause 14.3 | Notify [Customer] of a security incident affecting its data within [48] hours | [Head of Customer Security] | IR-08 customer notification | Contract notification matrix; incident records | Met |
| OBL-VOL-ISO27001-01 | ISO/IEC 27001 certification commitment | Maintain certification scope and pass surveillance audits each year | [ISMS Manager] | GOV-02 ISMS management review | Certificate; audit reports | Met |
The contract row shows why contracts belong in the register: customer notification windows are often shorter than legal ones, and the incident team needs both in the same place. See the GDPR Compliance Checklist and the DORA ICT Risk Management Framework Guide for full obligation lists in those areas.
8. Change monitoring and review
- Horizon scanning: [Legal] monitors official journals, regulator publications and law firm updates [monthly] and logs each relevant change against the affected rows, with the effective date.
- Contract intake: no contract with non-standard security or privacy commitments is signed until the register owner has added or matched the obligation.
- Full review: every row is reviewed by its owner at least [annually]; rows with status "not met" or "partly met" are reviewed [quarterly].
- Event-driven review: after a significant incident, a new market or product, an acquisition, or a regulator finding, the affected rows are reviewed within [30 days].
- Retired obligations: when a law is repealed or a contract ends, mark the row retired with the date. Do not delete it; past compliance may still be examined.
9. Compliance
The register owner reports to [Risk Committee] [quarterly]: number of obligations by status, overdue actions, new and changed obligations, and rows not reviewed on schedule. Obligations marked "not met" are recorded in the risk register with an owner and treatment plan. Exceptions to this procedure are approved by [Head of Compliance] and recorded in the Security Exceptions and Risk Acceptance Guide.
Implementation guidance
The order below is NHI Mgmt Group's recommendation.
- Start with what is already tested. Seed the register from the laws and contracts behind your current audits and certifications, then widen. A partial register with real owners beats a complete one nobody maintains.
- Pick the tool you can sustain. A spreadsheet works up to a few hundred rows. Beyond that, or where many owners contribute evidence, a GRC platform with obligation, control and evidence objects saves effort. See the GRC Platform Buyer's Guide.
- Pilot on one regulation. Decompose one law end to end, map controls and collect evidence, then use it as the pattern for the rest.
- Wire deadlines into operations. Copy every fixed time limit into incident runbooks and the compliance calendar, so the register is not the only place they live.
- Test it. In tabletop exercises, ask the team to find every notification obligation for a given incident from the register alone.
Decision guidance
- Small organisations: keep the Core fields only and review annually; one owner may hold many rows.
- Regulated groups: add an entity column and keep one row per entity where obligations differ, because national transpositions and licences vary.
- Granularity: split a row when parts have different owners, deadlines or evidence; merge when they never differ.
Measures that show it works
- Percentage of applicable obligations with a named owner and at least one mapped control.
- Percentage of rows reviewed within their cycle.
- Number of "not met" obligations and median age of their actions.
- Time from a regulatory change being published to the affected rows being updated.
- Contracts signed with non-standard security clauses not yet in the register (target zero).
Framework mapping
| Framework | Where the register fits |
|---|---|
| NIST CSF 2.0 | GV.OC-03 legal, regulatory and contractual requirements are understood and managed; GV.OV-03 performance is evaluated |
| NIST SP 800-53 Rev 5 | PM-1 information security program plan; CA-2 control assessments |
| ISO/IEC 27001:2022 | Requirements of interested parties, and the control on legal, statutory, regulatory and contractual requirements; confirm clause and control numbers against your licensed copy. See the ISO 27001 Certification Guide. |
| ISO 37301:2021 | Compliance management system requirements, including identifying and maintaining compliance obligations |
Common failure patterns
- One row per law: "GDPR: compliant" cannot be owned or tested.
- Contracts left out: customer notification and audit clauses are missed until an incident.
- No applicability reasoning: out-of-scope decisions cannot be defended later.
- Status without evidence: "met" is recorded with no link to a record that proves it.
- Stale rows: amended or replaced laws stay in the register under their old text.
- People-only controls: access and authentication obligations mapped to user reviews only, leaving service accounts and API keys outside the evidence.
Related NHI Mgmt Group resources: Control Mapping Guide · Compliance Calendar Template · Audit Evidence and Continuous Controls Monitoring Guide · Audit, Assurance and Compliance Guide. This template summarises how to record compliance obligations and is not legal advice.