If you sell infrastructure to EU-regulated financial entities — banks, payment institutions, investment firms — you are an ICT third-party provider under DORA, regardless of where you are incorporated. India SaaS companies are in scope. DORA became applicable on January 17, 2025. The questionnaires from EU procurement teams are not optional; they are how financial entities satisfy their own supervisory obligations.
Most engineering teams reach for their SOC 2 Type II report first. It covers some of the ground. This article maps what it doesn't.
Four obligations in DORA RTS Article 28 are load-bearing and not covered by SOC 2. Knowing which four is the starting point.
What DORA RTS Article 28 actually requires
The Delegated Regulation (EU) 2024/1774, which sets out the Regulatory Technical Standards under DORA Article 28, specifies the contractual content that financial entities must secure from their ICT third-party providers. Four obligations are load-bearing and not covered by SOC 2.
Contractual audit rights. Article 28 RTS requires that contracts grant the financial entity — and, where applicable, its competent supervisory authority — the right to audit the ICT third-party provider and its sub-contractors. The audit right must be contractually enforceable, not just stated in policy. SOC 2 has no equivalent mandate. A SOC 2 report is a third-party attestation; it does not grant your customer the right to audit you directly.
Exit and transition plans. The RTS requires that ICT providers maintain documented exit strategies that enable the financial entity to migrate away without material disruption to its own operational continuity. This includes data portability timelines, knowledge transfer procedures, and transition service terms. SOC 2 has no Trust Service Criterion covering exit feasibility.
Incident notification to the financial entity. DORA Article 19 requires financial entities to notify their competent authority within four hours of classifying a major ICT incident. For that clock to run, the financial entity must first receive notification from you. The RTS requires that contracts mandate timely incident notification upstream to the financial entity, on timelines aligned with DORA's regulatory deadlines. SOC 2 CC7 addresses incident response procedures, but it addresses historical control design, not real-time contractual notification obligations tied to EU supervisory timelines.
Subcontracting chain visibility. Article 28(8) of DORA requires that the financial entity be able to identify and audit the full sub-contracting chain. SOC 2 CC9.2 covers vendor management as an optional criterion, and even where it is in scope, it does not produce a jurisdiction-level sub-processor inventory with contractual audit-access provisions — which is what the RTS requires the financial entity to hold.
What SOC 2 covers — and where it stops
SOC 2 is built on the AICPA Trust Service Criteria: Security (mandatory), plus Availability, Confidentiality, Processing Integrity, and Privacy (optional). A Type II report attests that your controls were operating effectively over a defined review period, typically six or twelve months.
That attestation is useful for the Security and Availability sections of a DORA questionnaire. Your CC6 access controls, CC7 incident detection procedures, and CC9 risk management evidence all map to DORA's operational resilience baseline.
The framework was designed for US enterprise software procurement. It was not designed to satisfy EU financial supervisory obligations. The four gaps listed above — audit rights, exit plans, incident notification timelines, subcontracting chain — are structural, not incidental.
What this means for India SaaS companies
If you process data for an EU financial entity — call recordings, transaction logs, identity verification outputs, communication records — you are in your customer's DORA Register of Information. Their procurement team is obligated to verify the four obligations above. Your SOC 2 report will satisfy part of their questionnaire. The rest requires documentation you may not have produced yet.
The first step is knowing what your stack currently covers. Before your EU customer's risk team sends the formal questionnaire, run a scan against your own data flows: what you collect, where it goes, which sub-processors handle it, and whether your contracts include the provisions DORA requires your customer to verify.
Frequently asked questions
Does SOC 2 satisfy DORA Article 28 requirements?
Partially. SOC 2 covers operational resilience baseline requirements — CC6 access controls, CC7 incident detection procedures, and CC9 risk management evidence all map to DORA's Security and Availability criteria. However, SOC 2 does not satisfy the four structural obligations in DORA RTS Article 28: contractual audit rights, exit and transition plans, incident notification timelines tied to EU supervisory deadlines, and sub-contracting chain visibility with contractual audit access.
Are India SaaS companies subject to DORA?
Yes. If you sell infrastructure to EU-regulated financial entities — banks, payment institutions, investment firms — you are an ICT third-party provider under DORA regardless of where you are incorporated. DORA became applicable on January 17, 2025. India SaaS companies processing data for EU financial entities are in scope and will appear in those customers' DORA Register of Information.
What does DORA RTS Article 28 require for audit rights?
DORA RTS Article 28 requires that contracts grant the financial entity — and, where applicable, its competent supervisory authority — the right to audit the ICT third-party provider and its sub-contractors. The audit right must be contractually enforceable, not just stated in policy. SOC 2 has no equivalent mandate. A SOC 2 report is a third-party attestation; it does not grant your customer the right to audit you directly.
What exit and transition plan obligations does DORA impose on ICT providers?
DORA RTS Article 28 requires that ICT providers maintain documented exit strategies enabling the financial entity to migrate away without material disruption to its own operational continuity. This includes data portability timelines, knowledge transfer procedures, and transition service terms. SOC 2 has no Trust Service Criterion covering exit feasibility — this gap must be addressed through contract documentation separate from any SOC 2 report.
Scan your stack for data flow gaps
Before your EU customer's risk team sends the formal questionnaire, know what your stack covers. Juro scans your data flows — what you collect, where it goes, which sub-processors handle it — and maps findings to specific regulatory provisions including DORA Article 28. No account required.
Scan your stack for data flow gaps →