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 three stages. You file an initial notification within 4 hours of classifying the incident as major, and no later than 24 hours after you became aware of it. An intermediate report follows within 72 hours as handling progresses, and a final report with root-cause analysis within one month. These time limits are set in RTS 2025/301, with the reporting templates in ITS 2025/302, under Article 19 of DORA.

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 within 24 hours of becoming aware of the incident, a fuller incident notification within 72 hours, and a final report within one month of that notification. 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. These windows are fixed in Article 23(4) of the directive, so the 24-hour, 72-hour, and one-month deadlines are the same in every member state. What national transposition changes is the authority or CSIRT you report to and the reporting mechanics, so confirm your reporting route for the country where you operate. 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 within 24 hours of awareness, a notification within 72 hours with a fuller assessment, and a final report within one month of that notification covering root cause and mitigation. If the incident is still open at one month, you file a progress report and a final report once it is resolved. The timeframes come from Article 23(4) of the directive and do not change by member state; national implementation sets the authority you report to and the mechanics, not the windows.