Building a DORA Control Library in ServiceNow

Choosing the platform is the easy half. The question that decides whether a DORA programme succeeds is what you build inside it — and for firms that have landed on ServiceNow, the answer is a control library that maps each DORA obligation to a control, an owner and a piece of evidence, and can reproduce that chain when a supervisor asks. Buy the platform without designing that structure first and you get an expensive incident-ticketing system with a risk module bolted on.

Model the obligation, not the module

The common mistake is to configure ServiceNow around its out-of-the-box risk taxonomy and then try to fit DORA into it. The better sequence is the reverse: define the DORA control library on paper first — the obligations across the five pillars, the controls that satisfy each, the owner accountable, and the evidence that proves it — and then configure the platform to hold that model. The tool should encode your control framework, not impose its template on your regulation.

What the library actually needs to hold

• The Register of Information as a first-class object. DORA’s third-party register is a linked relational model, submitted in xBRL-CSV, not a flat list. Model it in ServiceNow as connected records — entities, providers, contractual arrangements, functions — so the annual submission is a report, not a rebuild.
• Incident classification wired to the reporting clock. DORA’s major-incident windows are tight. The library should classify incidents against DORA’s criteria and drive the reporting timeline, not leave it to a human reading a policy under pressure.
• Controls linked to evidence and test dates. A supervisor asks to see a control operating and when it was last tested. Store the test results and dates against each control, not just the policy document.
• Third-party and concentration mapping. Link providers to the functions they support so concentration risk and exit dependencies are queryable, including the fourth parties.

Where implementations go wrong

Two failures recur. The first is over-customisation — bending the platform so far that every upgrade becomes a project and the configuration ossifies a bad process. The second is treating the build as a technical task handed to a ServiceNow administrator, when the value depends on someone who can read a DORA article and design the control that satisfies it. The library is a regulatory artefact that happens to live in software; it should be built by someone fluent in both.

Done well, the control library turns DORA from an annual scramble into a system of record a supervisor can inspect on demand. That, not the licence, is the outcome worth paying for.

Who this is for

This reading is for:

• Firms that have chosen ServiceNow IRM and now have to operationalise DORA
• GRC and risk teams turning a platform licence into working controls
• CTOs who bought the tool and are unsure how to make it earn its keep
• Compliance leads mid-implementation with budget committed

Sixteen Pillars designs the DORA control library on paper first, then configures ServiceNow to hold it, so the platform encodes your framework rather than imposing its template. Pricing is published at /pricing/. If this is live for your organisation and you would like an independent reading, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.