Three PDFs and one question
A Tier 1 vendor's evidence pack usually looks the same: a SOC 2 Type II report of 80 pages or more, a data processing agreement, and a business continuity and disaster recovery plan. Sometimes an ISO 27001 certificate too.
The question DORA asks of that pack is narrower than it looks: does this evidence show the vendor meets what our contract and Articles 28 to 30 require, and can we point to where?
This post works through that review step by step. The examples come from the sample workspace in the ProcureCortex demo, which uses fictional vendors and documents. One thing to know up front: the demo labels its findings against SOC 2, ISO 27001, GDPR and contract clauses. For each finding below, we show which DORA provision it maps to as well.
Step 1: Decide what you're testing against
DORA is written for the financial entity, not the vendor. Article 30(3)(c) doesn't tell a vendor what to do; it tells you what your contract must contain. So before reading anything, turn the regulation into vendor-facing requirements you can test documents against.
For a vendor supporting a critical or important function, a workable starting set looks like this:
- The vendor meets appropriate information security standards (Article 28(5))
- Data locations are stated and changes are notified in advance (Article 30(2)(b))
- Data is protected for availability, authenticity, integrity and confidentiality (Article 30(2)(c))
- Data can be recovered and returned on insolvency or termination (Article 30(2)(d))
- The vendor notifies incidents fast enough for us to meet our 4-hour and 24-hour reporting clock (Article 30(2)(f) and our own reporting duties)
- Continuity plans are implemented and tested (Article 30(3)(c))
- Subcontractors supporting the service are known and assessed (Article 29 and Delegated Regulation (EU) 2025/532)
Step 2: Read the SOC 2 report for scope before controls
It's tempting to jump to the control tests. Don't. Start with three things: the system description, the audit period and the list of subservice organisations.
The system description tells you whether the report covers the service you actually buy. The audit period tells you how old the assurance is; if it ended more than a few months ago, ask for a bridge letter. The subservice organisations, usually hosting and infrastructure providers carved out of the audit, are your first view of the subcontracting chain DORA asks you to understand.
Then go to the exceptions. Here's one from the demo workspace:
- Finding F-3074, OmniPay Global (payments, Tier 1)
- Title: Encryption at rest not evidenced for backup storage
- Requirement: SOC 2 CC6.1, logical access and encryption
- Source: SOC 2 report, page 41
- Severity: High. Confidence: 89%. Status: In remediation
- DORA mapping: Article 30(2)(c) data protection, and Article 28(5) information security standards
Why this finding is useful
A reviewer reading this doesn't have to trust a summary. The finding names the page, the control and the gap: production encryption is covered, backups aren't evidenced. That's specific enough to send to the vendor as a remediation request, and specific enough to show a supervisor why the risk rating is what it is.
Step 3: The DPA tells you where data goes and how it comes back
The DPA is usually reviewed by privacy teams for GDPR. For DORA, the same document answers different questions: where is data processed and stored, who are the sub-processors, and what happens to the data when the relationship ends?
This finding from the demo shows how one gap can matter under two regulations at once:
- Finding F-3081, Helix Health Data (healthcare, Tier 1)
- Title: Sub-processor list does not cover AI model providers
- Requirement: GDPR Article 28(2), sub-processor transparency
- Source: DPA, section 6.3
- Severity: Critical. Confidence: 94%. Status: Open
- DORA mapping: subcontracting visibility under Article 29 and Delegated Regulation (EU) 2025/532, plus the data location duty in Article 30(2)(b)
One gap, two regulations
Under GDPR, an AI model provider that processes personal data without appearing on the sub-processor list is a transparency problem. Under DORA, it's an unassessed dependency in the subcontracting chain and a hole in your register of information. Fixing it once, by getting a complete list with locations, closes both.
Step 4: A continuity plan is only as good as its last test
Article 30(3)(c) requires the vendor to implement and test business contingency plans. Most vendors have a plan. Fewer have recent test evidence. Here's how that looks in the demo:
- Finding F-3055, Northwind Cloud (infrastructure, Tier 1)
- Title: Business continuity test evidence older than 12 months
- Requirement: ISO 27001 A.17.1.3, verify, review and evaluate continuity
- Source: BCP/DR plan, section 4
- Severity: Medium. Confidence: 86%. Status: Accepted
- DORA mapping: Article 30(3)(c) tested business contingency plans, and input to your exit strategy under Article 28(8)
What accepted should mean
Notice the status. The reviewer accepted this risk rather than escalating it. That's a legitimate outcome, as long as the record shows who accepted it, why, and until when. For a critical function under DORA, a sensible acceptance would come with a dated commitment from the vendor to retest, and a reminder to check the new report when it arrives.
Step 5: Hold the contract up against your reporting clock
The last check compares what the vendor's own documents say against what the contract promises. Incident notification is the classic mismatch:
- Finding F-3069, Atlas Logistics (supply chain, Tier 2)
- Title: Breach notification window exceeds contractual 24 hours
- Requirement: MSA clause 11, incident notification
- Source: MSA, clause 11.2
- Severity: High. Confidence: 91%. Status: Open
- DORA mapping: Article 30(2)(f) incident assistance, and your own 4-hour and 24-hour notification duties
Why a contract promise isn't enough
The contract says 24 hours. The vendor's documented process allows longer. If a major incident starts on the vendor's side, your 24-hour outer limit is already running while their process catches up. This is the kind of finding that's invisible in a questionnaire, because the vendor will simply answer yes to Do you notify customers within 24 hours?
What makes a finding defensible
Across all four examples, the same fields do the work. When a supervisor, an internal auditor or your own management asks why a vendor is rated the way it is, each finding should already answer:
- Which requirement was tested
- Which document, clause or page the conclusion comes from
- How severe the gap is and why
- How confident the extraction is, so reviewers know what to double-check
- What the reviewer decided: remediate, accept or escalate
- Who owns the next step, and by when
From findings to DORA outputs
A finished review isn't the end product. Under DORA, findings feed four other things:
- Remediation requests to the vendor, tracked to closure
- Contract changes where an Article 30 provision is missing or too weak
- Register of information updates when locations or subcontractors turn out to differ from what's recorded
- Management reporting on where the portfolio stands, by severity and over time
Try it on the sample vendors
Everything above comes from the ProcureCortex demo workspace. It includes six fictional vendors across payments, infrastructure, healthcare, SaaS, logistics and staffing, with their SOC 2 reports, DPAs, ISO certificates and continuity plans already indexed. You can open each finding, see the requirement, clause and confidence behind it, follow assessments from draft to approval, and see portfolio analytics by severity and risk dimension.
Access is self-serve: request it at procurecortex.com/explore and we'll email you a sign-in link. There's no password and no sales call needed to look around.
Sources
- Regulation (EU) 2022/2554 (DORA), Articles 28 to 30, on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- Commission Delegated Regulation (EU) 2025/532 on subcontracting ICT services supporting critical or important functions: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202500532
- European Commission, DORA implementing and delegated acts, including incident reporting standards: https://finance.ec.europa.eu/regulation-and-supervision/financial-services-legislation/implementing-and-delegated-acts/digital-operational-resilience-regulation_en
- Regulation (EU) 2016/679 (GDPR), Article 28 on processors: https://eur-lex.europa.eu/eli/reg/2016/679/oj
Frequently asked questions
Is a SOC 2 report enough for a DORA vendor assessment?
It's strong evidence for information security controls, but it doesn't cover everything DORA needs. You'll also need the contract for Article 30 provisions, the DPA for data locations and sub-processors, and continuity test evidence for Article 30(3)(c).
How do you map SOC 2 controls to DORA?
Turn DORA's requirements into vendor-facing statements, then link each to the evidence that supports it. For example, SOC 2 CC6 controls support the data protection provision in Article 30(2)(c), while subservice organisations in the report inform your subcontracting assessment under Article 29.
What is a bridge letter and when do you need one?
A bridge letter is a statement from the vendor covering the period between the end of its last SOC 2 audit and today. Ask for one when the audit period ended several months ago, so there's no unexplained gap in assurance.
Can a vendor risk be accepted under DORA?
Yes. DORA doesn't require every gap to be fixed, but acceptance should be documented with an owner, a reason and a review date, especially for services supporting critical or important functions.
Can I try ProcureCortex without a sales call?
Yes. Request access at procurecortex.com/explore and you'll receive a sign-in link to a sample workspace with fictional vendors, documents and findings.
ProcureCortex turns vendor documentation into structured, explainable compliance findings. Explore demo or explore the platform.
