Ask ten entities for their list of critical or important functions and all ten will produce one. Ask why a particular function is on it, and the room goes quiet. The list is the easy artefact. The record of how each entry got there is the one that gets requested, and almost nobody has it.
Why the list alone is not evidence
A designation under Article 3(22) is a judgement: would disruption materially impair financial performance, or the soundness and continuity of services, or continued compliance with the conditions of authorisation. A judgement without recorded reasoning cannot be reviewed, cannot be challenged internally, and cannot be shown to have been applied consistently across the entity.
That last point is the one that bites. Two functions with similar profiles landing on opposite sides of the line is not a problem in itself, provided the difference is explained. Unexplained, it reads as an assessment applied selectively, and it invites a reviewer to test the rest of the list.
What the record has to contain
A decision record is not a document. It is a row per function, held wherever your assessment lives, with six things on it.
| Field | Why it is there |
|---|---|
| Function, as named in the mapping | Ties the decision to one identifiable thing, using the same vocabulary as the register |
| Answers to the three tests | Customers or market, regulatory breach, conditions of authorisation. Yes, no or not applicable, each with one line of reasoning |
| Evidence referenced | The tolerance and MTPD the answers rest on, pointing at the analysis rather than restating it |
| Outcome | Critical, important, or neither, with the threshold that was applied |
| Decided by, and when | Converts an analyst view into a governance decision |
| Review trigger | What would make this wrong: a new provider, a volume change, a regulatory change |
Six fields, one row. The record is deliberately smaller than the analysis behind it. Its job is to make the reasoning retrievable, not to repeat it.
Record the negatives too
The instinct is to document only the functions that made the list. That is exactly backwards. A record showing that a function was assessed and deliberately not designated, with the reasoning, is worth more than another row confirming something obvious. It demonstrates the test was applied across the estate rather than to a shortlist someone already believed in.
It also protects the budget. Every critical designation pulls its providers into stricter contractual requirements, exit planning and testing scope. Being able to show why a function sits outside the perimeter is what stops defensive over-designation from quietly doubling the cost of the programme.
Consistency is the thing being tested
Run one check before you consider the list finished: sort the functions by the tolerance behind them and look for inversions. A function with a tighter tolerance sitting below the line while a looser one sits above it is either an error or a decision that needs its reasoning written down. Inversions are what a reviewer finds quickly, because they need no knowledge of your business to spot.
The same check catches the other common defect, which is a designation made against the provider rather than the function. If the reasoning column says "because this is a major vendor", the test was not applied. Vendor size is not one of the three questions.
Keeping it alive
A decision record written once during an implementation project is a snapshot, and snapshots age badly. Three triggers should push a row back into review: a change to the function mapping, a material change to the tolerance behind it, and the annual framework review (Article 6(7)). Attaching the record to those triggers is what turns it from a project artefact into evidence of an ongoing process, which is the difference a supervisor is actually looking for.
The register is the downstream consumer. When a designation changes, the contracts that carry that function change scope with it, which is why the record and the register of information have to move together rather than being reconciled once a year in a panic.
Frequently asked questions
Does DORA require a decision record?
Not as a named artefact. It requires the designation itself and an ICT risk management framework that can be reviewed. In practice a reviewer asks how a designation was reached, and an entity that can answer in one row is in a materially better position than one that reconstructs the reasoning from memory.
Where should the record live?
Next to the assessment, not in a separate document. Anything that lives apart from the working data stops being updated. A column set on the same sheet as the impact analysis is usually enough.
How long should each entry be?
One line of reasoning per test. If a justification needs a paragraph, the underlying tolerance is probably not defined clearly enough, and that is the thing to fix rather than the wording.
Who signs it?
The same accountable owner who approved the tolerance, with the management body informed through the normal framework reporting. A designation signed only by the project team is a recommendation, not a decision.
