DORA Article 30 requires financial entities to include specific contractual provisions in their ICT vendor agreements. Among these, the service level and availability requirements are among the most operationally significant for SaaS vendors. Banks and other financial entities have specific expectations about what SLA commitments must look like — and what the consequences of SLA breach should be.
What DORA Requires on Availability and Performance
DORA Article 30(2)(c) requires ICT contracts with financial entities to include:
"provisions on availability, authenticity, integrity and confidentiality of data, including personal data"
Article 30(2)(e) requires:
"provisions setting out a complete description of all functions and services to be provided by the ICT third-party service provider, including updates and revisions"
While DORA does not mandate specific SLA percentages or response times, it requires that these commitments be specific and contractually binding — not vague statements of intent. The EBA ICT and Security Risk Management Guidelines add further detail on what regulators expect.
Availability Commitments
Minimum Uptime Standards
For systems used in regulated financial processes, banks typically expect:
Critical systems (payment processing, trading, core banking):
- 99.9% uptime minimum (8.7 hours downtime per year)
- Many banks expect 99.95% or 99.99% for mission-critical systems
Non-critical enterprise systems (CRM, HR, analytics):
- 99.5% to 99.9% is typically acceptable
- Lower tiers with clear exclusions (planned maintenance, force majeure) may be accepted
What must be specified in the contract:
- The uptime percentage commitment
- How uptime is measured (by calendar month, year, rolling window)
- What constitutes a service outage (partial degradation vs. complete unavailability)
- Scheduled maintenance windows and how they are treated in uptime calculations
- The remedies for SLA breach (credits, termination rights)
Incident Classification
DORA requires financial entities to classify ICT incidents by severity. Your SLA should align with this classification framework:
Major incident (P1): Full service unavailability or loss of critical functionality affecting the financial entity's operations
- Response time: immediate acknowledgement, typically within 15–30 minutes
- Notification to customer: within 1–4 hours
Significant incident (P2): Significant degradation of service, affecting a substantial portion of users or critical functions
- Response time: within 1 hour
- Notification to customer: within 4–24 hours
Standard incident (P3/P4): Limited impact, workaround available
- Response time: within 1 business day
- Notification: standard ticketing process
Recovery Time and Recovery Point Objectives
DORA Article 11 (Business Continuity Policy) requires financial entities to define RTO and RPO for critical functions. They flow these requirements to their ICT vendors:
What banks typically require from SaaS vendors:
| System Criticality | RTO | RPO |
|---|---|---|
| Mission-critical | 4 hours | 1 hour |
| Important | 24 hours | 4 hours |
| Standard | 48–72 hours | 24 hours |
These are guidelines — actual requirements will vary by bank and by the criticality classification of your specific service. The contract must specify:
- The RTO and RPO commitments
- Whether these apply to the full service or specific components
- How RTO/RPO is tested and at what frequency
Incident Notification Requirements
This is where many SaaS vendors are most underprepared. DORA's notification timelines apply to the financial entity — but to meet them, the entity needs vendor notifications that arrive in time.
DORA's financial entity notification timelines:
- Initial notification to competent authority: within 4 hours of classifying a major incident
- Intermediate report: within 72 hours
- Final report: within 1 month
What this means for vendor SLA contracts: Your contract must specify vendor-to-customer notification timelines that allow the financial entity to meet regulatory deadlines. In practice:
- Major ICT incidents affecting the financial entity's service: 1–4 hours from detection
- Significant incidents: 4–8 hours
- Security incidents (potential data breaches): immediate escalation regardless of operational impact
The notification must include:
- Nature of the incident
- Systems affected
- Current status and mitigation steps taken
- Estimated time to resolution
Planned Maintenance and Change Management
Banks operating under DORA require advance notice of changes that may affect service availability:
What to specify in the contract:
- Planned maintenance windows (day of week, time, typical duration)
- Advance notice of planned maintenance: typically 5–10 business days for standard maintenance, longer for major changes
- Major version releases or infrastructure migrations: typically 30 days advance notice
- Emergency maintenance: as soon as possible, with immediate notification
Change management implications: DORA-regulated banks have their own change management processes. They need advance notice to coordinate internal change approvals with your maintenance schedule. An unannounced major update that changes authentication mechanisms, API structure, or data format creates internal compliance violations for the bank.
SLA Remedies
Banks expect meaningful consequences for SLA breach. Typical structures:
Service credits:
- Below 99.9% uptime: credits proportional to downtime (e.g., 1 day credit per hour of excess downtime)
- Credits apply automatically, not requiring claim submission
- Credits cap at a percentage of monthly fees (typically 30–50%)
Escalating consequences:
- Repeated SLA breaches (2–3 consecutive months below threshold) trigger additional remediation obligations
- Right to terminate for persistent SLA failure after remediation period
Step-in rights:
- For critical services, some financial entities require the right to step in and manage the service themselves or through a third party if the vendor fails to restore service within the RTO
What SaaS Vendors Should Do Now
If you sell to financial services and your SLA section says "we target 99.9% uptime and will use commercially reasonable efforts to restore service":
- Replace "commercially reasonable efforts" with specific timelines
- Define incident classification and notification timelines aligned with DORA's reporting framework
- Add RTO/RPO commitments matched to the criticality of your service
- Add planned maintenance notification obligations
- Add service credit provisions for SLA breach
The investment in improving your SLA documentation pays back in faster sales cycles and fewer late-stage contract negotiations.