GRC Software vs vCISO Under DORA: What Supervisors Examine

In this article ↓

1. What GRC software covers — accurately
2. What DORA Article 5 actually requires
3. What GRC software covers vs what DORA supervisors examine
4. The supervisory evidence gap: what NCAs look for that GRC tools don't produce
5. GRC software and vCISO: complementary, not competing
6. Frequently asked questions
7. Is Vanta DORA compliant?
8. Can GRC software replace a vCISO for DORA compliance?
9. What does a DORA supervisory review look for that GRC tools do not cover?
10. What is the minimum governance structure a fintech needs for DORA, beyond a GRC tool?
11. How CyAdviso approaches GRC + vCISO design for DORA

Last reviewed: 14 July 2026

---

GRC compliance software (Vanta, Drata, Sprinto) automates control mapping, evidence collection, and audit readiness. Under DORA, however, National Competent Authorities examine the ICT risk management function: a documented governance structure, management body accountability (Article 5), and ongoing risk oversight. A software dashboard does not satisfy these requirements.

DORA Article 5 requires the management body to approve and oversee the ICT risk management framework. GRC software can support documentation and evidence collection, but it cannot fulfil the governance, accountability, and ongoing-function requirements that DORA supervisors examine. The two serve different but complementary purposes.

For EU-licensed fintechs operating as EMIs, Payment Institutions, or CASPs, the pattern that generates supervisory findings is this: a GRC tool produces a clean dashboard. The compliance officer reports "green" status. The NCA arrives and examines the ICT risk management function — the management body's documented accountability, the ICT risk register's operational maintenance, the incident classification governance — and issues findings because the function behind the dashboard was not operational.

For a CEO, the green dashboard is reassuring precisely because it looks like the answer. But when the NCA examines the function behind it, accountability under Article 5 runs to the management body — not to the tool, and not to the vendor. The dashboard does not absorb the personal exposure.

This article explains what GRC software covers, what DORA supervisors actually examine, and why the two categories require different solutions. It also covers how GRC tools and a vCISO function work together for fintechs that want both.

---

What GRC software covers — accurately

GRC compliance software platforms (Vanta, Drata, Sprinto, and comparable tools) address a genuine compliance need. They:

Automate control evidence collection: GRC tools integrate with cloud infrastructure (AWS, Azure, GCP), identity providers, and SaaS tools to continuously collect evidence that controls are in place: access reviews, encryption status, vulnerability scan outputs, backup logs.

Map controls to regulatory frameworks: Most platforms offer pre-built framework mappings: SOC 2, ISO 27001, GDPR, and increasingly DORA and NIS2. These help identify which controls address which regulatory requirements.

Maintain audit readiness: By collecting evidence continuously, GRC tools keep organisations audit-ready for framework assessments and certifications without manual evidence collection exercises.

Track remediation: GRC platforms typically include task management for open findings, with assignees and deadlines.

Produce compliance reports: Dashboard views and exportable reports show control status across frameworks.

These are real capabilities. For fintechs pursuing SOC 2 certification or ISO 27001 audits, GRC software is a legitimate operational tool. The question is not whether GRC software is useful. The real question is whether it satisfies what DORA supervisors examine.

---

What DORA Article 5 actually requires

DORA Article 5 establishes the ICT risk management framework as a governance responsibility of the management body. The requirements are substantive:

Article 5(2): The management body bears ultimate accountability for the ICT risk management framework. This is not a technical control. It is a governance obligation requiring documented management body approval and oversight.

Article 5(4): The management body must "keep updated knowledge and skills to understand and assess ICT risk." This requires ongoing engagement and training to keep that knowledge current, not a one-time briefing.

Article 6(1): The ICT risk management framework must be "sound, comprehensive and well-documented." EBA supervisory guidance treats "sound" as functional: the framework must operate, not merely be documented.

Article 8: Ongoing "identification of all sources of ICT risk": not automated control scanning, but systematic risk identification across the entity's ICT environment.

Article 18: ICT incidents must be classified against the DORA classification criteria (Commission Delegated Regulation (EU) 2024/1772) and reported to the NCA under Article 19 where they meet the major incident threshold. This requires a governance process, not a monitoring tool.

Article 28: A Register of Information for all third-party ICT providers (Article 28(3)), with concentration risk assessment (Article 29) and DORA-compliant contractual clauses (Article 30). This is a documented governance process, not a vendor survey.

None of these requirements are satisfied by a GRC dashboard. They require a function: a person or team responsible for operating the framework, reporting to the management body, and maintaining the evidence on an ongoing basis.

For the regulatory basis for the ICT risk function requirement, see EBA ICT and Security Risk Guidelines →.

---

What GRC software covers vs what DORA supervisors examine

The table shows that GRC software addresses some of what DORA requires: control evidence, third-party questionnaires, vulnerability scan logs. It does not address the governance layer: management body accountability, documented ICT risk decision-making, ongoing risk register maintenance, or the incident classification governance process.

A "green dashboard" in Vanta does not mean the ICT risk management function is operational under DORA. An NCA reviewing a fintech will ask for the evidence behind the dashboard, not the dashboard itself.

---

The supervisory evidence gap: what NCAs look for that GRC tools don't produce

When an NCA reviews a DORA-supervised entity, they typically examine evidence in categories that GRC software does not produce:

Management body ICT risk records: NCAs request management body meeting minutes, board packs, or equivalent records showing that ICT risk was reported, discussed, and acted upon. A GRC dashboard is not a management body record. Someone needs to extract meaningful ICT risk information from the tool and present it to the management body in a format that enables governance decisions.

Documented ICT risk function ownership: NCAs ask: who owns the ICT risk management function? What is their reporting line? How is the function resourced? A GRC platform does not answer these questions. The answers require an organisational decision and documented accountability.

Operational ICT risk register: NCAs distinguish between a static control mapping document and a live ICT risk register that reflects the entity's current risk environment. A GRC tool can support risk register maintenance, but the risk identification that feeds it requires human expertise and ongoing engagement. Understanding which ICT assets carry which risks is a judgment task, not an automated one.

Incident classification governance: When an ICT incident occurs, the decision about whether it meets the DORA major incident threshold (Article 18) requires a governance process: who makes the decision, on what basis, with what documentation. This is not automated by a GRC tool.

For related patterns where GRC over-reliance generates findings, see common DORA compliance mistakes →. For the tool-specific limits of a GRC SaaS platform under DORA, see the limits of GRC SaaS for DORA compliance →; for how the EBA guidelines frame tooling versus the ICT risk function, see EBA ICT guidelines: tooling vs the ICT risk function →.

---

GRC software and vCISO: complementary, not competing

The framing of "GRC software vs vCISO" is ultimately a false choice for most EU-licensed fintechs. The two serve different layers of the DORA compliance programme:

GRC software is a control and evidence management tool. It is efficient for collecting evidence that controls are in place, maintaining audit readiness, and tracking remediation items. For fintechs with existing technology infrastructure, a GRC platform reduces the manual burden of evidence collection.

A vCISO (or dedicated ICT risk function) provides the governance layer. This includes: owning the ICT risk management framework; designing and maintaining the ICT risk register; reporting to the management body; managing ICT incidents through the DORA classification and reporting process; overseeing third-party ICT provider review; and building the supervisory evidence package.

The combination works as follows: the GRC tool collects and organises control evidence; the vCISO interprets the risk picture, reports to the management body, makes governance decisions, and translates tool outputs into the supervisory-facing evidence package that NCAs actually examine.

For fintechs operating under EU financial-sector supervision, the EBA ICT and Security Risk Guidelines, which informed DORA's ICT risk management requirements, emphasise that the ICT risk function is a governance responsibility, not a technical one. The EBA ICT guidelines → are the regulatory basis for this distinction.

For a broader orientation on the DORA compliance programme, the comprehensive DORA compliance guide → covers the full regulatory requirements.

Lietuvos bankas, the Lithuanian National Competent Authority, in its ICT risk supervisory approach, focuses on governance evidence — the management body's role, documented accountability, and operational evidence of the ICT risk function — rather than on control dashboards. This is consistent with EBA supervisory convergence guidance.

---

Frequently asked questions

Is Vanta DORA compliant?

Vanta supports some DORA obligations, notably control evidence collection, third-party questionnaires, and audit readiness documentation. It does not constitute a DORA-compliant ICT risk management function. DORA Article 5 requires management body accountability, documented governance, and ongoing risk oversight that a SaaS dashboard cannot provide. Vanta may be a useful part of a DORA compliance programme; it is not a substitute for the ICT risk management function DORA requires. The same applies to Drata, Sprinto, and comparable GRC platforms.

Can GRC software replace a vCISO for DORA compliance?

No. GRC software automates control evidence collection and tracks remediation. A vCISO (or dedicated ICT risk function) provides the governance layer: ICT risk framework ownership, management body reporting, ICT incident classification governance, third-party ICT oversight, and the supervisory evidence package. DORA Article 5 requires a governance function — not only a documentation tool. GRC software and a vCISO serve complementary roles. Neither alone satisfies DORA's requirements; the governance layer cannot be replaced by software.

What does a DORA supervisory review look for that GRC tools do not cover?

NCAs examine management body accountability (documented ICT risk reporting and decisions), documented ownership of the ICT risk function, operational ICT risk register maintenance, ICT incident classification governance (not just incident logging), third-party ICT provider oversight per Article 28, and evidence that the ICT risk function operates continuously. GRC tools produce artefacts: control evidence, audit trails, compliance dashboards. Supervisors examine the function behind the artefacts: who owns it, how it operates, and what decisions it produces.

What is the minimum governance structure a fintech needs for DORA, beyond a GRC tool?

At minimum, a DORA-compliant governance structure requires: a named ICT risk function owner with a reporting line to the management body; a documented ICT risk management framework approved by the management body; a live ICT risk register with a defined update process; a management body reporting cadence for ICT risk; and a documented ICT incident classification process aligned to the DORA classification criteria (Commission Delegated Regulation (EU) 2024/1772). GRC software can support several of these — but the governance decisions and accountability cannot be automated.

---

How CyAdviso approaches GRC + vCISO design for DORA

CyAdviso works with EU-licensed fintechs to design the ICT risk governance layer that GRC software cannot provide. Where a fintech already uses Vanta, Drata, Sprinto, or a comparable tool, CyAdviso's approach is to integrate, not replace: use the GRC tool for control evidence and audit readiness, and build the governance and reporting layer that makes the tool's output meaningful under supervisory scrutiny.

Based on engagements under EU financial-sector supervision, this typically involves:

• mapping the GRC tool's existing outputs against DORA Articles 5–16 to identify governance gaps;
• establishing the ICT risk management function: ownership, reporting line, management body reporting cadence;
• designing the ICT risk register structure that reflects the entity's actual ICT environment, not a generic framework template;
• building the supervisory evidence package that translates GRC outputs into NCA-ready documentation.

The goal is a compliance programme that passes a supervisory review, not a dashboard that reads green.

To discuss how your DORA programme can combine GRC tooling with the governance layer, schedule a consultation with CyAdviso or contact us at info@cyadviso.com.