Every DORA programme reaches the same argument. Someone says a function is critical, someone else says it is merely important, and there is no agreed way to settle it because nobody has written down how much disruption would actually be unacceptable. That number is your tolerance, and until it exists on paper the designation is an opinion.
Impact tolerance is not a DORA term. That matters.
If you have worked under the UK operational resilience regime you will know impact tolerance as a formal concept: for each important business service, the maximum tolerable level of disruption, expressed as a time limit. DORA does not use that phrase. It requires the ICT risk management framework to state the entity's tolerance for ICT risk (Article 6), and it requires recovery objectives and continuity arrangements (Article 11).
The practical consequence is easy to get wrong. Because DORA never hands you a template for tolerance, teams skip the step entirely and jump from a service list straight to a criticality label. The regulation still expects the reasoning to exist. It simply does not tell you what the artefact looks like, which means you choose the format and you own the defence of it.
The three numbers people confuse
Most of the confusion in tolerance workshops comes from mixing three different measures that answer three different questions.
| Measure | Question it answers | Set by |
|---|---|---|
| Tolerance | Beyond what point is the disruption unacceptable to customers, the market or our authorisation? | The business, validated by the board |
| MTPD | How long can the process be down before that unacceptable point is reached? | Business impact analysis |
| RTO / RPO | How fast must ICT actually restore, and how much data may be lost? | ICT, working backwards from MTPD |
The order is not decorative. Tolerance is a statement about harm. MTPD is a measurement of time until that harm occurs. RTO is an engineering commitment that must sit comfortably inside MTPD, with margin. When an entity sets RTO first, which happens more often than anyone admits, the recovery target reflects what the infrastructure can already do rather than what the business can survive. That is the inversion supervisors notice.
Writing a tolerance you can defend
1. Express it as harm, not as uptime
"99.9% availability" is a service level, not a tolerance. A tolerance says what becomes unacceptable: customers unable to access funds, a payment window missed, a reporting obligation breached, a number of clients affected. Availability percentages hide the thing a supervisor asks about, which is the consequence.
2. Put a unit on it
Pick units you already report on elsewhere so the numbers can be challenged: customers affected, transactions failed, euros at risk, hours past a regulatory deadline. A tolerance with no unit cannot be tested, and anything that cannot be tested will not survive a review.
3. Anchor it to a severe but plausible scenario
Tolerances set against a mild scenario are meaningless, and tolerances set against catastrophe are ignored. The useful anchor is severe but plausible: the provider is unavailable for a working day, the data centre is lost, the file arrives corrupted. Write the scenario next to the number so the reader knows what the number was measured against.
4. Name who signed it
This is the step that converts an assumption into evidence. A tolerance approved by the accountable executive, with a date, is a governance record. The same number in an analyst spreadsheet is a draft. The business impact analysis methodology covers how to run the collection so the sign-off is meaningful rather than ceremonial.
How tolerance decides the designation
Once tolerance and MTPD exist, the critical-or-important test stops being a debate. A function whose disruption crosses a tolerance the board has approved is, by the entity's own stated standard, one whose failure would materially impair its services or its compliance obligations. That is the language of Article 3(22), and you have arrived at it with arithmetic rather than opinion.
The reverse case matters just as much. A function that stays well inside tolerance for several days is defensibly not critical, and being able to show that is what protects you from designating everything out of caution. Over-designation is expensive: every critical function drags its providers into stricter contractual requirements, exit planning and testing scope.
Where entities get caught
- One tolerance for the whole entity. Tolerances belong to services, not to organisations. A single group-wide figure tells you nothing about which function to restore first.
- Tolerance copied from the provider's SLA. The provider's commitment is an input to your RTO, not a statement of what your customers can absorb.
- No margin between RTO and MTPD. If they are equal, any variance at all is a breach. Supervisors read a zero-margin plan as one that has never been exercised.
- Never revisited. The framework is reviewed at least annually (Article 6(7)); tolerances that never move across a year of business change look unmaintained.
- No trace to the register. If a function is inside tolerance only because a specific provider performs, that dependency belongs in your register of information.
A worked shape
A tolerance record that survives scrutiny fits on one row. Function: retail payment initiation. Tolerance: no more than 2,000 customers unable to initiate a payment, or any breach of the settlement cut-off. Scenario: primary payment gateway unavailable during business hours. MTPD: 4 hours to the cut-off. RTO: 90 minutes. RPO: 5 minutes. Approved by: Head of Retail Banking, 12 March 2026. Supporting providers: two, both in the register, both flagged as supporting a critical function.
Everything a reviewer needs is on that row: the harm, the scenario, the time to harm, the commitment, the margin, the owner, the date and the onward link to third-party scope.
Frequently asked questions
Does DORA require a documented impact tolerance?
DORA does not use the term. It requires the ICT risk management framework to express the entity's tolerance for ICT risk, and it requires recovery objectives supported by business continuity arrangements. In practice you need a documented statement of unacceptable disruption per function, whatever you choose to call it.
Who should own the number?
The business owner of the service, validated at board or executive committee level. ICT owns the RTO that must fit inside it. A tolerance signed only by technology reads as a capability statement rather than a risk appetite.
How many functions need one?
Every function that is a candidate for critical or important designation, plus the ones you intend to argue are not. The second group is the one entities forget, and it is the group that proves the assessment was applied consistently rather than selectively.
What if the business cannot give a number?
Offer a range and a scenario rather than an open question. "Would 500 affected customers be acceptable for a day? Would 5,000?" converges quickly, and the bracketing itself is evidence of a method.
