Ask a compliance team to show you their obligation register and you will usually be shown a spreadsheet with one row per instrument. Privacy Act 1988. APRA CPS 234. AML/CTF Act, Part A. Each row has an owner, a status, and a link to the legislation. It looks like a register. It is a reading list.
The test is not how it looks. The test is whether it can answer the question a regulator actually asks, which is never "which laws apply to you". It is some version of: show me this requirement, tell me who in your group carries it, and show me what stops it being breached.
A list of instruments cannot answer that, and no amount of tidying will make it able to. The problem is the unit.
The unit is the requirement, not the document
A regulation is a document. It contains dozens or hundreds of separate things the organisation must do, and they are not alike: some are continuous, some are triggered by an event, some fall due on a date, some apply to one subsidiary and not another. Recording the document as one row collapses all of that into a single status field, and a single status field on a hundred requirements is a status that means nothing.
One row per requirement is what makes the register work. It is more rows — often ten or twenty times more — and that is the cost. What it buys is that every row has exactly one answer to each of the questions that matter:
- Is this a thing we must do continuously, on an event, or by a date?
- Which of our legal entities carries it?
- Who owns it, in each of those entities?
- What covers it — which policy says so, which control enforces it?
- What happens if it is not met?
None of those have a single answer at the level of an instrument. All of them do at the level of a clause.
Applicability belongs to the entity, not the requirement
The second failure is subtler and more common in groups. A register with an "applicable: yes/no" column has decided that applicability is a property of the requirement. In a group with more than one regulated entity, it is not.
The same clause is frequently carried by four subsidiaries, of which two meet it with a shared group control, one has a local variation because its licence conditions differ, and one is out of scope because it does not conduct that activity. That is four different answers, four different owners, and four different pieces of evidence — against one requirement.
So the register needs two layers. The requirement is recorded once, with its text and its citation. Each entity that carries it gets its own row underneath: its own applicability decision with a reason, its own owner, its own mapping to policies and controls, and its own view of the risk that runs if it is not met.
Teams resist this because it multiplies the rows again. It is worth it for one reason: without it, the question "does this apply to us" has no truthful answer at group level, and every attempt to give one is a generalisation somebody will later have to defend.
A requirement with no source is not a requirement
Every row should cite where it came from: the instrument, the version, and the clause. Not a link to the regulator's landing page — the clause.
This sounds like bookkeeping. It is the thing that makes the register survive contact with the world, because regulations change, and when they do you need to know which rows are affected without rereading everything. A register that cites its sources by version can tell you that fourteen of your obligations sit in a standard that was amended last month, and which fourteen. A register that links to "the regulator's website" cannot tell you anything, and its owner finds out about the amendment when somebody reads a newsletter.
The corollary is the one most registers miss: a requirement can also come from somewhere other than a regulator. A contract with a client. A licence condition. An undertaking given to a supervisor. A rule the organisation wrote in one of its own policies and is now held to. These are all requirements the organisation carries, they all need an owner and a control, and there is no reason to keep them in four different places. One register, and a field that says where each row came from.
Coverage is a mapping, not a colour
The last failure is the traffic light. A register with a green/amber/red column per row is recording an opinion, and the opinion is usually the opinion of whoever last looked.
Coverage is a relationship: this requirement, in this entity, is met by this control and stated in this policy. Recorded that way, three useful things fall out on their own and need nobody's judgement:
- Gaps are requirements with no mapping. Not a colour somebody chose — an absence you can count.
- Orphan controls are controls that map to nothing, which usually means either the control is unnecessary or the requirement it serves was never written down.
- Blast radius, when a control fails: every requirement that leaned on it, in every entity, immediately.
And a gap should not be able to sit there quietly. Either it becomes work — an action with an owner and a date — or it is accepted deliberately: a reason, a second signature, and a review date after which it counts as outstanding again. "Known gap" as a permanent status is how a register becomes a document nobody believes.
What this costs
Honestly: more rows and more discipline, and a migration that is real work. A 150-row instrument list becomes a two-thousand-row register with an entity layer under it, and nobody enjoys the week that takes.
What you get is a register that answers questions instead of raising them. The requirement, who carries it, what covers it, what is not covered, and what is being done about that — without anybody having to assemble it first.
That is the whole difference, and it is decided by a choice made at the start, about what one row is.