Most organisations think evaluating cloud providers means checking a SOC 2 report, glancing at an ISO certificate, and calling it a day. Under DORA and NIS2, that shortcut becomes a regulatory liability. Cloud risk is now business risk ; and regulators expect you to prove you understand it.
DORA and NIS2 changed the rules of the game. Regulators no longer care whether your cloud provider has “good security.” They care whether you can continue operating when your provider fails.
This means:
- deeper assessments
- contractual transparency
- concentration risk analysis
- ongoing monitoring
- exit strategies
- real governance, not checklists
Most organisations are not ready for this ; and auditors know it.
Here’s how to evaluate cloud providers the right way under DORA and NIS2.
1. Start With Criticality: Not All Cloud Services Are Equal
The biggest mistake organisations make is treating every SaaS or cloud service the same.
Under DORA and NIS2, you must classify providers by business impact:
- critical
- important
- non-critical
Critical services directly affect:
- business continuity
- customer-facing operations
- financial transactions
- regulatory obligations
- safety
- core infrastructure
Anecdote: A client labelled their CRM as “low risk” because “marketing uses it.” Turns out 60% of their revenue pipeline depended on it. Under DORA, that’s critical.
Regulators expect prioritisation. Start there.
2. Demand Transparency on Architecture, Dependencies & Sub-Processors
Under NIS2 and DORA, you need clarity on:
- data location
- sub-processors
- infrastructure dependencies
- multi-region failover design
- residency and jurisdictional exposure
Cloud providers love vague diagrams and marketing fluff. Regulators want specifics.
Your risk is your vendor’s vendor.
3. Evaluate Operational Resilience, Not Just Security Controls
ISO 27001 and SOC 2 tell you about security hygiene. DORA and NIS2 want to know:Can your operations survive a cloud provider failure?
Ask for:
- RTO/RPO for their entire stack
- real outage history
- failover test results
- capacity management metrics
- incident escalation timelines
- service-level maturity
- status page reliability (history matters)
Anecdote: A SaaS vendor claimed “99.99% uptime.” Their public status page showed eight outages in 6 months. Your assessment must match reality ; not marketing.
4. Confirm How They Handle Major Incidents (DORA Has Expectations)
DORA requires contractual clarity on:
- incident classification
- reporting timelines
- information sharing
- root-cause analysis delivery
- escalation paths
If your cloud provider has no mature incident response process, you inherit the gap.
A story from the field: A service provider delivered RCAs 30 days late ; every time. Under DORA, this becomes your regulatory issue.
If they can’t support your regulatory reporting timelines, they are not compliant for you.
5. Assess Concentration Risk & Single Points of Failure
This is the part most companies ignore ; and where regulators will push hardest.
Questions to ask:
- Are multiple critical services relying on the same cloud provider?
- Are we locked into one vendor with no viable alternative?
- What’s the switching cost?
- How many of our critical processes depend on AWS/Azure/GCP?
- Do we have geographic redundancy?
- Are two “vendors” actually the same because they share infrastructure?
Anecdote: A bank thought they had “redundancy” because they used two SaaS services. Both were running on the same AWS region.
You can outsource services. You can’t outsource responsibility.
6. Demand Contractual Control (DORA Makes This Mandatory)
DORA requires mandatory contractual clauses for ICT services deemed critical.
Your contract must cover:
- audit & inspection rights
- performance reporting
- security obligations
- exit & transition plans
- resilience requirements
- incident notification
- sub-contractor transparency
- termination assistance
- encryption responsibilities
Anecdote: A SaaS provider refused audit rights. Under DORA, that’s a deal-breaker. Full stop.
If they don’t allow oversight, you can’t use them.
7. Evaluate Ongoing Monitoring, Not One-Off Assessments
NIS2 and DORA both emphasise continuous oversight, not annual checklists.
You need:
- quarterly security status updates
- annual SOC reports
- real-time availability monitoring
- vendor questionnaire refresh cycles
- regulatory impact assessments when they change something
- re-assessment after major incidents
If the vendor “doesn’t do ongoing reviews,” walk away.
Anecdote: A SaaS provider only refreshed their SOC 2 report every 18–24 months. Under NIS2 and DORA, that’s unacceptable for critical systems.
8. Test Their Exit & Portability Plans (The Most Ignored Requirement)
DORA explicitly requires exit strategy testing. NIS2 expects operational continuity.
Cloud providers must prove:
- you can extract your data
- you can migrate without service disruption
- formats are portable
- timelines are reasonable
- support is available during exit
Anecdote: One vendor said, “We provide data export.” The export was a proprietary binary blob. Zero portability.
If you cannot leave them, you cannot use them.
9. Build a Cloud Provider Scoring Model Aligned With DORA & NIS2
The simplest way to scale evaluations is to use a scoring model.
Recommended categories:
- Security (ISO/SOC)
- Operational resilience
- Incident management maturity
- Regulatory alignment
- Transparency & documentation
- Vendor dependency (sub-processors)
- Contractual strength
- Concentration risk
- Exit feasibility
- Monitoring ability
Each category scored 1–5. The weighted score determines risk classification.
10. Map Cloud Provider Evidence Across All Frameworks
ISO → access, logging, backups GDPR → processors, transfers, data protection NIS2 → resilience, supply chain, incident reporting DORA → ICT governance, testing, oversight
Instead of multiple assessments:Use one questionnaire mapped to all frameworks.
One assessment. Multiple compliances. Zero duplication.
Final Thought
Cloud provider evaluations are no longer a procurement formality. Under DORA and NIS2, they’re a core part of your operational resilience strategy.
The organisations that succeed will be the ones who:
- classify providers by criticality
- demand transparency
- assess resilience, not just security
- enforce contract strength
- monitor continuously
- minimise dependency risk
- build real exit options
Cloud risk is regulatory risk. If your providers fail, regulators will ask why you didn’t evaluate them properly.
Use this moment to move from checkbox vendor reviews to real governance.
If you want to build a unified, regulator-ready vendor evaluation system for DORA, NIS2, GDPR, and ISO 27001, that’s exactly what we teach inside the Cyber Academy DORA Lead Manager or NIS2 Lead Implementer Course Join the next session and secure your entire digital supply chain.