Walk in already audit-ready.

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) applies to financial entities in the EU. It establishes requirements for ICT risk management, ICT-related incident reporting, digital operational resilience testing (including threat-led penetration testing for significant entities), ICT third-party risk management, and information sharing on cyber threats. DORA became applicable on 17 January 2025. Acuna covers DORA requirements across all four panes: framework mapping in Comply, ICT controls and asset inventory in Implement, incident and third-party management in Operate, and TLPT findings and corrective actions in Assure.

DORA Chapter IV requires financial entities to maintain a digital operational resilience testing programme. This includes vulnerability assessments, network security testing, gap analysis, and software security reviews. Significant entities must also conduct threat-led penetration testing (TLPT) at least every three years, simulating real-world attacks against live production systems using threat intelligence. TLPT must be performed by qualified testers and results reported to the National Competent Authority. Acuna tracks TLPT planning, findings, and corrective actions in the Assure pane.

SOC 2 Type I evaluates whether controls are suitably designed at a specific point in time. SOC 2 Type II evaluates whether those controls operated effectively over a period, typically 6 to 12 months. Type II is more rigorous because it requires evidence of sustained operation — not just that controls exist on paper. Most enterprise buyers require a Type II report. Acuna is designed for continuous evidence collection during the Type II observation period, with recurring tasks, control health scoring, and audit-ready evidence packs.

A SOC 2 report is the written output of an attestation engagement: an independent CPA firm examines a service organization's controls against the AICPA Trust Services Criteria and issues a formal opinion. The report is a private document — unlike an ISO 27001 certificate, it is not publicly verifiable. It is distributed under NDA to enterprise customers and prospects who request it during vendor due diligence. Procurement and security teams read three things in a SOC 2 report: the auditor's opinion (whether it is unqualified or contains exceptions), the system description (which services and systems were in scope), and the exceptions table (any controls that failed or deviated during the audit period). A narrow scope or a qualified opinion raises questions a buyer will ask about. A Type II report with a clean, unqualified opinion and appropriate scope is the artifact that closes enterprise deals where a vendor security questionnaire alone would not suffice. The report is typically renewed annually — which is why the observation-period cadence is ongoing rather than one-time.

SOC 2 readiness and audit typically take six to eighteen months depending on starting state. The observation period for a Type II report is a minimum of six months — the auditor must see controls operating for at least that long, so the earliest a first-time Type II report is available is roughly six months after controls are operational. Organizations starting from scratch typically spend two to four months on readiness — scoping, control implementation, tooling, and initial evidence collection — before beginning the observation period. That makes the total timeline nine to twelve months for a first-time Type II. Type I moves faster: it is a point-in-time assessment with no observation period, and some organizations use a Type I as a milestone on the way to Type II, getting a report into customers' hands faster while the Type II evidence accumulates. The most common source of delay is not the audit itself but the observation period: controls must run without gaps, and evidence must be collected consistently. Starting continuous evidence collection early — before the formal observation window opens — is the practical way to compress the overall timeline.

In Acuna, evidence records follow four states: Draft (being compiled), Submitted (sent for approval), Approved (locked and timestamped), and Expired (no longer current). Each record captures collection, review, and expiry dates, supports versioned file attachments, and can be linked to multiple controls with per-link notes. Approvers receive notifications and can request changes before accepting. Approved evidence contributes to control effectiveness and audit readiness metrics. Expired evidence is flagged visually and cannot be deleted without administrator approval, preserving the audit trail.

Acuna supports four KPI data source types. Manual entry is for metrics from outside the platform (pen test scores, survey results). Computed KPIs calculate automatically from live compliance data using either a predefined metric library (grouped by Compliance, Operations, Risk, Controls, General, and Assure categories), a custom query builder with filters and operators, or a control-sourced effectiveness/execution feed. Connectors pull values from integrated external services. External API/webhook receives inbound values from systems that push data to Acuna. Per-item compliance thresholds with colour-coded progress bars are available for computed sources.

Assure is the evidence and audit-readiness layer. It manages evidence records through their full lifecycle (Draft → Submitted → Approved → Expired), links evidence to controls, tracks review and expiry dates, and packages evidence for internal or external audits. Assure also handles findings management: audit observations, non-conformities, and corrective actions with due dates and ownership. The pane provides audit-readiness dashboards showing evidence coverage, expiry forecasts, and open finding counts — so you know exactly where you stand before an auditor arrives.

Audit readiness in Assure is a composite metric driven by three factors: evidence coverage (percentage of controls with at least one approved, non-expired evidence record), control health (rolled up from task completion), and open finding count (unresolved non-conformities and observations). Each factor contributes to an overall readiness score displayed on the Assure dashboard. When evidence expires or a finding goes overdue, the score drops automatically. This gives compliance managers a single number to report to leadership and auditors — backed by drill-down detail to every underlying control and artefact.

A CISO dashboard is a consolidated view of security, risk, and compliance indicators a Chief Information Security Officer needs to run their program. Effective CISO dashboards combine: multi-framework compliance posture (ISO 27001, NIS2, DORA, SOC 2), risk register with scoring and trends, control maturity by domain, and readiness for upcoming audits. In Acuna, each CISO configures their dashboard via RBAC to show only their scope, their KPIs, and the risks they own. Leadership sees the summary. Analysts see their controls. Same platform, different views per role.

The DORA register of information is the record, required by Article 28 of Regulation (EU) 2022/2554, of all your contractual arrangements for the use of ICT services provided by third parties. Every financial entity must keep it current, maintain it at entity and, where relevant, sub-consolidated and consolidated group level, and make it available to its competent authority on request. It is the backbone of DORA's third-party risk regime: supervisors use it to see, across the financial sector, which providers the system depends on. The register is not a one-time inventory. It is a living record that has to reflect your ICT supply chain as it actually is, including which arrangements support critical or important functions, because those carry stricter contractual and oversight requirements. That distinction, critical-or-important versus the rest, drives much of what DORA asks of the relationship. The register documents each ICT contractual arrangement: the provider, the service, whether it supports a critical or important function, and the contractual terms DORA requires. The European Supervisory Authorities set the detailed template and fields through technical standards, so the precise columns are defined centrally rather than left to each entity. The register has to be complete and consistent enough that a supervisor can read your ICT dependency map from it. A register maintained as a spreadsheet, separate from the vendor relationships it describes, is accurate the day it is built and wrong the week a contract changes and nobody updates the file. That is the failure mode DORA's "keep it current" requirement is aimed at, and it is why the register cannot be a document you refresh before an inspection.

DORA requires financial entities to detect, manage, classify, and report ICT-related incidents. Major incidents must be reported to the competent authority in stages: an initial notification, followed by an intermediate report as the situation develops, and a final report once the root cause is known. The classification of what counts as "major" is based on criteria set out in the regulation and its technical standards, covering factors such as the number of clients affected, duration, geographic spread, data losses, and economic impact. Entities may also notify significant cyber threats voluntarily. Before you report, you classify. DORA and its technical standards define the thresholds that separate a major incident from a routine one, using materiality factors. Getting classification right matters because it determines whether the reporting clock starts at all. This is where a running incident process earns its place: if you cannot quickly assemble which clients, systems, and data an incident touched, you cannot classify it, let alone report it on time. DORA structures reporting in stages: an initial notification once you determine an incident is major, an intermediate report as handling progresses, and a final report with root-cause analysis. The precise deadlines for each stage are set by the regulatory and implementing technical standards and should be verified against the current published standard before you rely on them.

Threat-led penetration testing (TLPT) is the advanced form of resilience testing that DORA requires of financial entities identified as significant. Unlike routine vulnerability scanning or standard penetration tests, TLPT simulates the tactics, techniques, and procedures of real threat actors against an entity's live production systems, covering the critical or important functions that support its business. It is performed by qualified external testers, scoped and validated with the competent authority, and carried out at least every three years. TLPT draws on the TIBER-EU framework for threat-led testing. TLPT sits at the demanding end of DORA's testing pillar. Most in-scope entities run a general resilience testing programme; significant entities additionally run TLPT, because the regulation treats their disruption as a bigger systemic risk. A standard penetration test checks whether known weaknesses can be exploited. TLPT is intelligence-led: it starts from a picture of the threats that realistically target your kind of entity, then tests whether your live systems and your people would withstand those specific adversary behaviours. It runs against production, not a test environment, which is what makes it a genuine test of operational resilience rather than of a lab setup. TLPT is a structured engagement: scoping the critical or important functions to be tested, developing threat intelligence, running the red-team test against live systems, and producing findings that feed remediation. Tester qualification, scoping, and the outcome are handled with the competent authority.

Under Article 23 of NIS2, essential and important entities must report significant incidents to their national CSIRT or competent authority in stages: an early warning shortly after becoming aware of the incident, a fuller incident notification, and a final report once the incident is handled. An incident is significant if it has caused or is capable of causing serious operational disruption or financial loss, or has affected other people through considerable material or non-material damage. Because NIS2 is a directive, the exact deadlines and mechanics are shaped by each member state's transposition, so confirm the specifics against your applicable national law. The staged structure exists so authorities get an early signal quickly, then a complete picture as the situation resolves. The reporting clock only starts once you determine an incident is significant, which is why fast, accurate classification matters as much as the reporting itself. NIS2 sets out when an incident is significant, based on the disruption or loss it causes or could cause, and the harm to others. National transposition and guidance sharpen these thresholds. Classifying correctly is the gate: misjudge it and you either over-report routine events or, worse, miss the clock on a reportable one. Reporting is a sequence, not a single filing: an early warning soon after awareness, a subsequent notification with a fuller assessment, and a final report after the incident is resolved including root cause and mitigation. The precise timeframes are set by Article 23 and national implementation, so verify the current figures for your member state before relying on them.