What Vanta, Drata and Sprinto Don't Cover Under DORA
Vanta, Drata and Sprinto automate DORA evidence collection, but Article 5 requires management-body governance of ICT risk. What GRC tools miss for EU fintechs.
In this article ↓
- What GRC compliance software does well under DORA
- What DORA Article 5 requires that GRC tools cannot deliver
- Where Vanta falls short of DORA requirements
- Where Drata falls short of DORA requirements
- Where Sprinto falls short of DORA requirements
- What supervisors examine that no GRC tool covers
- Frequently asked questions
- Is Vanta DORA compliant?
- Does Drata cover DORA compliance requirements?
- What does a DORA supervisory review look for that GRC tools do not cover?
- Can GRC software and a vCISO work together for DORA?
- How CyAdviso approaches GRC tool integration under DORA
Last reviewed: 25 August 2026
Key takeaways
- Vanta, Drata, and Sprinto automate control mapping and evidence collection well, and that has genuine value in a DORA programme — but no GRC platform provides the governance function DORA Article 5 requires.
- The gap is the same across tools: management body approval and updated knowledge (Article 5(2)/(4)), DORA severity-taxonomy incident classification (Article 18), and the Register of Information with subcontractor chains and concentration risk (Articles 28-30).
- Each platform falls short from its own strength — Vanta on management-body capture, Drata on supervisory presentation and continuity, Sprinto on the ongoing nature of the function.
- Supervisors examine the function behind the artefacts: who owns it, what the management body decided, how continuously it operated. The effective structure pairs a GRC tool for evidence with a retained vCISO for governance.
Vanta, Drata and Sprinto automate control mapping and evidence collection well. They generate audit trails, surface control gaps, and produce compliance reports at scale. Many EU-licensed fintechs adopt them as part of their DORA programme.
The problem is what these platforms do not do. DORA Article 5 requires the management body to approve and oversee the ICT risk management framework: a documented governance structure with named accountability, regular management body reporting, and ongoing risk decision-making. No GRC SaaS product fulfils this requirement. A software dashboard cannot substitute for a function.
When a National Competent Authority reviews an EU-licensed fintech under DORA, it examines whether the ICT risk management function is real: who owns it, how the management body receives ICT risk reporting, and what decisions the management body has made about ICT risk. An evidence collection platform that is not connected to a governance function will not answer those questions.
This article explains what Vanta, Drata and Sprinto provide that is useful for DORA, and where each falls short of what DORA Article 5 and EBA ICT Risk Guidelines require. It also sets out what supervisors examine that no GRC tool covers.
For the general comparison of GRC software versus the ICT risk function requirement, see the hub article: GRC compliance software vs vCISO under DORA: what supervisors actually examine. This article provides the tool-specific depth — where over-trust in a single platform (Vanta, Drata, or Sprinto) leaves the DORA governance function unaddressed. For the same tooling-versus-function distinction read from the EBA guidelines themselves, see EBA ICT guidelines: tooling vs function →.
What GRC compliance software does well under DORA
Vanta, Drata and Sprinto share a core capability: automating the evidence collection and control documentation that compliance frameworks require. For DORA, this includes:
- mapping internal controls against DORA obligation categories;
- collecting and storing evidence of control operation (access reviews, vulnerability scans, configuration snapshots);
- flagging controls that have drifted from their documented state;
- generating audit-ready reports that can be shared with reviewers.
These capabilities have genuine value for a DORA programme. DORA requires documented evidence that controls exist and operate. GRC tools make that documentation easier and more consistent. They reduce the manual effort of assembling an evidence package before a supervisory review.
What they do not do is create the governance structure that DORA requires. They can document that controls exist. They cannot ensure that the management body has reviewed those controls, made risk decisions, or maintained the ICT risk function.
What DORA Article 5 requires that GRC tools cannot deliver
DORA Article 5(2) places ultimate accountability for the ICT risk management framework on the management body. The management body must approve the framework, define risk appetite, and ensure adequate resourcing. This is a governance obligation. It requires people making decisions and documenting those decisions, not a software platform generating a compliance report.
Article 5(4) adds a harder requirement: the management body must maintain "updated" knowledge of ICT risks. That means regular briefing, documented review, and active engagement with the current risk environment. A dashboard to which the management body has access does not satisfy this requirement. Supervisors ask whether the management body has actually reviewed ICT risk information and what decisions they made.
Article 6(1) requires the framework to be "sound, comprehensive and well-documented." Soundness means the framework actually operates, not merely that a control exists in a platform. A GRC tool can show that a control is in place. It cannot show that the control has been reviewed by a person accountable for ICT risk, or that any action was taken when a risk changed.
The EBA ICT Risk Guidelines, which shape how NCAs interpret DORA during supervisory reviews, reinforce this distinction. The guidelines require documented governance accountability, regular management reporting, and a function that is resourced and active. These are function requirements, not documentation requirements.
The table below maps the gap:
| DORA requirement | GRC tool coverage | Gap |
|---|---|---|
| Management body approval of ICT risk framework (Art. 5(2)) | Control documentation | No governance event capture |
| Management body updated knowledge of ICT risks (Art. 5(4)) | Dashboard access | No documented review or decision record |
| Sound and continuously operated framework (Art. 6(1)) | Evidence of control state | No evidence of ongoing function operation |
| ICT incident classification and reporting governance (Art. 18) | Alert/ticket tracking | No DORA severity taxonomy or reporting governance |
| Register of Information for third-party ICT providers (Art. 28(3)) | Vendor questionnaires | No subcontractor chain or concentration risk |
| ICT testing programme scheduling and oversight (Art. 24-27) | Automated scanning | No testing programme governance or TLPT coverage |
Where Vanta falls short of DORA requirements
Vanta is strongest in SOC 2 and ISO 27001 evidence collection. Its DORA coverage maps controls against obligation categories but does not extend to governance layer requirements.
Management body governance: Vanta does not capture management body approval of the ICT risk framework as a compliance event. It does not track ICT risk reporting to the management body or document management body decisions on material ICT risks.
ICT risk register: Vanta's risk module tracks control-level gaps, not ICT risk at the framework level required by DORA Article 8. The distinction matters: DORA requires ongoing identification and classification of ICT risks, including emerging threats and changes in the ICT environment, not just a control gap list.
Register of Information: Vanta's vendor management module tracks vendor relationships but is not designed for the DORA Register of Information requirements, which include subcontractor chains, concentration risk assessment, and contractual clause compliance per the Register of Information template (Commission Implementing Regulation (EU) 2024/2956).
Incident classification: Vanta does not implement DORA's severity taxonomy for ICT incidents (Article 18), classification decision governance, or the reporting timeline requirements for significant incidents.
Vanta can be a useful evidence management layer within a DORA programme. It is not a DORA compliance function.
Where Drata falls short of DORA requirements
Drata's strength is continuous control monitoring and audit automation. Its DORA support is similar to Vanta: useful for control documentation, insufficient for governance.
Supervisory presentation: Drata's trust centre and audit reports are designed for SOC 2 and ISO 27001 audiences. DORA supervisory reviewers do not receive a Drata report. They request documentation of the management body's governance of the ICT risk function. Drata does not capture or present this governance layer.
ICT testing programme: The ICT testing programme requirements (DORA Articles 24-27), which include vulnerability assessments, penetration testing schedules, and for in-scope fintechs, threat-led penetration testing (TLPT), are not covered by Drata's standard automation. Scheduling and documenting the testing programme requires a governance process outside the platform.
Ongoing function versus certification model: Drata's model is to achieve a compliance certification and maintain evidence. DORA requires an ongoing function, not periodic certification. A fintech that treats DORA as a Drata certification project will face supervisory findings on continuity of the ICT risk function.
Where Sprinto falls short of DORA requirements
Sprinto is designed for startups achieving compliance certifications efficiently. Its DORA coverage follows the same pattern: control documentation and evidence collection are automated, governance layer requirements are not.
Scope of function requirements: Sprinto does not handle the ongoing nature of DORA's requirements. Its model is to achieve a certification checkpoint and maintain evidence. DORA requires continuous operation of the ICT risk function: the management body must engage with ICT risk regularly, incidents must be classified, third-party providers must be reviewed.
Article 28 coverage: Sprinto's vendor management functionality is not aligned to the DORA Register of Information structure set by Commission Implementing Regulation (EU) 2024/2956, which goes substantially beyond a standard vendor questionnaire process.
For fintechs that are early-stage and cost-sensitive, Sprinto can support the evidence layer of a DORA programme at lower cost than other platforms. The governance gap remains the same regardless of which platform is used.
What supervisors examine that no GRC tool covers
When a National Competent Authority reviews a DORA ICT risk framework, it examines the function behind the documentation. The questions that GRC platforms cannot answer:
Who is the named owner of the ICT risk management framework? What is their reporting line to the management body? Is that ownership formal and documented?
What ICT risk reporting has the management body received in the last twelve months? Can the entity show meeting records, report distributions, and documented management body responses?
How are ICT incidents classified against DORA's severity taxonomy? Who makes the classification decision? Is there a documented governance process, separate from IT operations?
How is the Register of Information maintained? How is concentration risk assessed? Has the management body reviewed it?
These questions require a function to have operated, not a platform to have run. GRC tools document controls. Supervisors examine the function behind the controls.
For the regulatory basis of the ICT risk function requirement, see the EBA ICT Risk Guidelines overview. For tool-related patterns in DORA compliance findings, see common DORA compliance mistakes. For what DORA requires as a full obligations overview, see DORA requirements 2025.
Fintechs supervised by Latvijas Banka, the Latvian National Competent Authority and those operating under other EU NCAs should note that supervisors apply the same function requirement regardless of which GRC tool the entity uses.
Frequently asked questions
Is Vanta DORA compliant?
Vanta supports some DORA obligations, particularly control evidence collection and audit readiness for ICT framework documentation. It is not a DORA-compliant ICT risk management function. DORA Article 5 requires management body accountability, governance documentation, and a continuously operated ICT risk function. Vanta can support the evidence layer of a DORA programme but cannot replace the governance function. A fintech using only Vanta for DORA will face supervisory findings on the governance layer.
Does Drata cover DORA compliance requirements?
Drata automates continuous control monitoring and evidence collection, which has value within a DORA programme. It does not cover the management body governance requirements of DORA Article 5, the ICT incident classification and reporting governance of Articles 17-19, the full scope of DORA Article 28(3) Register of Information obligations, or the ICT testing programme requirements of Articles 24-27. A DORA programme that relies on Drata without a dedicated ICT risk function will face supervisory findings on the governance layer.
What does a DORA supervisory review look for that GRC tools do not cover?
DORA supervisors examine management body accountability, documented decision-making on ICT risks, ICT incident classification and response governance, third-party ICT oversight procedures, and evidence that the ICT risk function has operated continuously. GRC tools produce artefacts: control documentation, evidence logs, audit reports. Supervisors examine the function behind those artefacts: who governed it, who made decisions, and how continuously it operated.
Can GRC software and a vCISO work together for DORA?
Yes. GRC tools like Vanta, Drata and Sprinto handle the evidence collection and control documentation layer well. A vCISO provides the governance function: management body reporting, ICT risk decision-making, incident classification oversight, and third-party review governance. The two are complementary in a DORA programme. Neither alone satisfies Article 5. The combination of a GRC tool for evidence and a retained vCISO for governance is a common and effective structure for EU-licensed fintechs.
How CyAdviso approaches GRC tool integration under DORA
CyAdviso works with EU-licensed fintechs that use GRC platforms as part of their DORA programme. Based on engagements under EU financial-sector supervision, the most common gap is not the tooling: it is the absence of a governance function that connects the platform to the management body.
Our approach is to assess what the existing GRC platform covers, identify the governance layer gaps, and design the ICT risk function structure that fills them. This includes:
- defining the management body reporting structure and cadence;
- establishing the incident classification governance process that the GRC tool does not provide;
- mapping the Register of Information requirements against what the vendor management module captures;
- delivering ICT risk reporting that gives the management body documented, auditable engagement with the risk framework.
GRC tools are infrastructure. The ICT risk function is governance. DORA requires both.
To discuss how your fintech's GRC programme can be structured to satisfy DORA supervisory expectations, schedule a consultation with CyAdviso or contact us at info@cyadviso.com.