Obligations register vs risk register: how the two connect and why you need both

The short answer

An obligations register records what is required of you; a risk register records what could go wrong and how badly. They are different artefacts with different owners, different review cycles and different audiences, and they are joined by a single field: the obligation reference carried on each compliance risk.

Organisations frequently maintain one and assume it covers the other. It does not. A complete obligations register with no risk assessment cannot tell a board where to spend money. A rich risk register with no obligations register cannot tell an auditor whether every duty has been identified in the first place.

What each register actually records

The risk register is the artefact regulated entities are more often required to hold explicitly. APRA's CPS 220 risk management framework requires a documented framework covering material risks. Critical infrastructure responsible entities must maintain a risk management program under the Security of Critical Infrastructure Act. The internationally recognised reference is ISO 31000:2018 Risk management — Guidelines, which is paywalled and cited here by name only.

Where the two registers join

The join is a field, not a merge. Each compliance risk on the risk register carries one or more obligation IDs drawn from the obligations register. That single link produces four capabilities that neither register delivers alone:

1. Coverage testing. Sort the obligations register by whether any risk references it. Rows with no linked risk are either genuinely low-consequence or have never been assessed. Both answers are useful; only one is acceptable undocumented.
2. Prioritised assurance. The monitoring plan tests controls in residual-risk order, not alphabetical order.
3. Consequence realism. Statutory maximum penalties, licence conditions and remediation costs give the consequence axis a defensible basis rather than a subjective rating. The penalty estimator draws maximum penalty ranges from the Rules Mate corpus for that purpose.
4. Incident traceability. When an event is logged, it cites an obligation ID and a risk ID, so the register can be read for trends.

Keep the registers in separate tabs or tables with a shared key. Merging them into one giant sheet reliably produces a document nobody maintains.

A worked example: one obligation, three risks

Take a single obligation: notifying the Office of the Australian Information Commissioner of an eligible data breach under the notifiable data breach scheme. On the obligations register, that is one row with an owner, a control (the incident response plan), an evidence type (the statement lodged) and an event-driven frequency.

On the risk register, the same obligation sits behind at least three distinct risks:

One obligation, three separate exposures, three different controls, three different owners. That is the work the risk register does and the obligations register cannot. The notifiable data breach walkthrough covers the notification mechanics; the NDB timer tracks the assessment clock.

Who owns which register

Ownership should be split, because the two registers answer to different people.

• Obligations register — owned by the compliance function (or the CFO, company secretary or GM in a smaller business). Its audience is assurance: internal audit, external auditors, regulators.
• Risk register — owned by the risk function where one exists, otherwise the executive team collectively, with a named risk owner on each line. Its audience is the board and, indirectly, insurers.
• Both report into the same governance forum. In an SMB that is usually the board itself; in a larger entity it may split between an audit committee and a risk committee.

Where a single person owns both, keep the review meetings separate. A combined meeting reliably becomes a compliance meeting, and the risk conversation is the one that gets dropped.

Row-level ownership differs too, and the difference is worth stating explicitly in the policy. On the obligations register, the owner is the role that performs the control — payroll for withholding and reporting, operations for licensing and safety, technology for access management. On the risk register, the owner is the role that carries the exposure and can authorise spending to reduce it, which is usually more senior. The same obligation can therefore have a junior control owner and a senior risk owner, and that is correct rather than an inconsistency to be tidied away. Problems appear when the two are forced to match: either the control owner is given an exposure they cannot fund, or the executive is recorded as performing a control they have never touched.

One further distinction matters at review time. An obligations register row closes only when the obligation ceases to apply — the licence is surrendered, the threshold is no longer met, the contract ends. A risk line is never closed on that basis; it is re-rated as controls change, and retired only when the underlying activity stops. Registers that use the same closure logic for both end up either deleting risks that still exist or carrying obligations that lapsed years earlier.

Reporting drawn from both

A board pack should draw from both registers, and the difference between the two views is the point:

• From the obligations register: new or amended obligations assessed this period, open gaps with owners and target dates, upcoming lodgements, attestation status.
• From the risk register: movement in residual ratings, risks outside appetite, control failures identified by testing, and emerging risks not yet mapped to an obligation.

The second list is where new regulation shows up before it becomes law. An emerging risk with no obligation ID is often the earliest signal that a proposed regime — labelled clearly as proposed and not yet legislated — needs monitoring. Board reporting structure is covered in board and committee compliance reporting.

What breaks when you keep only one

Obligations register only. Everything looks equally important. Controls are built to the same standard for a $500 late-lodgement exposure and a licence-threatening one. Assurance testing is alphabetical. The board receives a compliance status list with no sense of exposure, and directors cannot discharge the duty to inform themselves in any meaningful way.

Risk register only. The register reflects what management already knows about. Unidentified obligations produce no risk lines, because nobody assessed them. This is the classic pattern behind threshold-triggered failures — an entity crosses a revenue, headcount or emissions threshold, a new regime switches on, and it appears in neither register because the trigger was never mapped. The obligation finder and the Compliance Fingerprint exist to surface exactly those triggers.

Both, but unlinked. The most common state. Both artefacts exist, both are reviewed, and neither can answer "which of our obligations carries the highest residual risk". Adding the obligation ID field to the risk register is a single afternoon of work and is the highest-return maintenance task in most compliance programs.