Straight answers to GRC questions.

ISO 27001 is the international standard for information security management systems (ISMS). Published by ISO/IEC, it defines requirements for establishing, implementing, maintaining, and continually improving an ISMS. The 2022 revision includes 93 controls across four themes: organisational, people, physical, and technological. Certification requires an accredited external audit demonstrating that the ISMS meets all clause requirements and that selected Annex A controls are implemented and effective. Acuna supports the full ISO 27001 lifecycle from scoping through audit preparation.

NIS2 (Directive (EU) 2022/2555) is the EU directive on cybersecurity for essential and important entities. It expands the scope of NIS1, introduces stricter security requirements under Article 21, and mandates incident reporting within 24 hours (early warning), 72 hours (notification), and one month (final report). Essential entities include energy, transport, banking, health, water, and digital infrastructure. Important entities cover postal, waste, chemicals, food, manufacturing, and digital providers with 50+ employees or EUR 10M+ turnover. Acuna maps NIS2 articles to controls, manages supply chain risk, and tracks incident reporting deadlines.

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.

GRC (Governance, Risk, and Compliance) is a broad management discipline covering how an organisation directs strategy, manages risk, and meets regulatory obligations across all domains. An ISMS (Information Security Management System) is a specific implementation of governance and risk management focused on information security, typically conforming to ISO 27001. An ISMS is one component within a wider GRC programme. Acuna is a GRC platform that supports ISMS management as one of its use cases alongside privacy, business continuity, supplier risk, and enterprise risk management.

Cross-framework control mapping identifies where requirements from different frameworks overlap — for example, ISO 27001 A.8.5 (access control) and NIS2 Article 21(2)(i) (access management) describe essentially the same practice. By mapping these overlaps, organisations implement and evidence a control once instead of duplicating effort per framework. In Acuna, mappings can be direct (manual), derived via 58 curated reference measures across 11 domains, or suggested by AI with confidence scores. Batch mapping lets you align entire domains in one operation.

The Statement of Applicability (SoA) is a mandatory document in ISO 27001 that lists all Annex A controls, states whether each is applicable or not applicable to the organisation's ISMS scope, provides justification for exclusions, and references the implementation status of each applicable control. The SoA is a key audit artefact — auditors use it to verify that control selection is risk-based and that excluded controls have documented rationale. In Acuna, the SoA is managed directly in the Comply pane with applicability markings and justification fields per control.

A Data Protection Impact Assessment (DPIA) is required under GDPR Article 35 when processing is likely to result in a high risk to the rights and freedoms of individuals. This includes systematic profiling with legal effects, large-scale processing of special categories of data, and systematic monitoring of public areas. A DPIA must describe the processing, assess necessity and proportionality, identify risks, and define mitigating measures. If residual risk remains high after mitigation, the controller must consult the supervisory authority under Article 36. DPIA workflows are on the Acuna Data Protection module roadmap; currently, processing activities can be documented and linked to controls and assets to support DPIA preparation.

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.

The Trust Services Criteria (TSC) are the standards the AICPA publishes against which an independent CPA firm evaluates a service organization's controls. There are five categories. Security (Common Criteria, CC) is mandatory and appears in every SOC 2 report. The other four — Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P) — are optional: organizations include them where relevant to the services they provide and to what buyers need to see. Most SaaS companies scope Security as the baseline and add Availability when uptime commitments matter to buyers, Confidentiality when enterprise data handling is a selling point, Privacy when the service processes significant personal data, and Processing Integrity for transactional or financial processing. The Common Criteria are further divided into CC1 through CC9. CC6 covers logical and physical access controls — provisioning, authentication, role-based access, and periodic access review. CC7 covers systems operations and monitoring. CC9 covers risk management and vendor risk, including CC9.2, which requires monitoring of third-party providers and the controls they operate on your behalf. CC6 maps closely to ISO 27001 A.5.15–A.5.18; CC9.2 to A.5.19–A.5.23 — organizations running both frameworks reuse this evidence rather than maintaining separate control sets.

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.

SOC 2 and ISO 27001 both address information security controls, but they are architecturally different. ISO 27001 produces a certificate: issued by an accredited certification body, three-year validity, globally recognized, and publicly verifiable. SOC 2 produces an attestation report: issued by a licensed CPA firm, privately distributed, renewed annually, and standard in US enterprise markets. ISO 27001 requires a formal Information Security Management System (ISMS) with documented scope, risk assessment, and a Statement of Applicability for 93 Annex A controls. SOC 2 is organized around the AICPA Trust Services Criteria — Security (CC) is mandatory, the other four categories are optional. The control overlap is significant: CC6 (logical access controls) maps closely to ISO 27001 A.5.15–A.5.18; CC9.2 (vendor monitoring) maps to A.5.19–A.5.23; CC7 (operations) maps to ISO 27001 A.8.x controls. Organizations running both frameworks map once and reuse evidence across both rather than maintaining parallel control sets. The choice depends on where your buyers are. ISO 27001 is the expectation in EU enterprise and global markets. SOC 2 is the US market standard and is frequently required by US enterprise procurement before a contract is signed. Many organizations operating across both markets pursue both.

Supplier Shield is Acuna's third-party risk management (TPRM) software. It gives you a scored vendor register, a daily-refreshed external security grade on every supplier, AI-assisted assessment campaigns that a human evaluator confirms, a supplier portal for external responses, and an immutable activity log that serves as your audit artifact for DORA, NIS2, and ISO 27001. Vendors are scored across three dimensions, dependency, reach, and impact, into one colour-coded risk tier. It is one module of the Swiss-hosted Acuna GRC platform, which maps to 50+ frameworks, so vendor evidence collected here is reusable across your wider compliance programme.

In Acuna, a measure is a template-level practice drawn from curated libraries aligned with frameworks like ISO 27001 and NIST CSF. It describes what should be done. A control is the operational record you create from a measure — typed (preventive, detective, or corrective), owned, statused, and linked to specific requirements, assets, processes, and risks. You implement and attest at the control level; measures standardise the underlying practice across your programme. One measure can spawn multiple controls in different scopes.

Each control in Acuna displays a colour-coded health badge — green (healthy), orange (at risk), or red (unhealthy). Health is driven primarily by recurring task completion: a task completed on time scores as healthy (100), completed late scores as at risk (75), in progress but not past due as at risk (75), and not started past due as unhealthy (0). These scores cascade upward through measures and requirements so operational slippage surfaces in the control and programme views, not only in a task list. Click any health badge for a breakdown explaining which tasks contributed to the current score.

Aiko is Acuna's built-in AI assistant, accessible from every page via the floating Aiko icon. It helps with compliance questions about framework requirements and control approaches, navigation guidance with internal links to relevant pages, status summaries of compliance posture and pending tasks, and gap identification where requirements lack linked measures or controls. Aiko uses the same token budget shown on the Admin → AI Agents dashboard, and all conversations are context-aware with the current date included for time-sensitive guidance.

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.

Comply is where you manage frameworks, requirements, and applicability. You import or create regulatory frameworks (ISO 27001, NIS2, DORA, SOC 2, GDPR, and others), review each requirement, mark applicability with justification, and establish cross-framework mappings so overlapping requirements share the same measures and controls. The pane shows a real-time compliance posture per framework — coverage percentage, gap counts, and requirement-level status — so compliance managers and auditors see the programme state without opening spreadsheets.

In Comply, each requirement can be marked Applicable or Not Applicable with a mandatory justification field. For ISO 27001, this produces the Statement of Applicability (SoA). Applicability decisions propagate downstream: when a requirement is marked not applicable, its linked measures and controls are excluded from coverage calculations. Auditors can filter the requirement list by applicability status and export the SoA as a versioned artefact. Changing applicability after initial marking is tracked in the audit trail with the user, timestamp, and reason for change.

Implement is where you build the operational backbone of your compliance programme. You create measures from curated libraries or custom definitions, instantiate controls from those measures, assign owners, set statuses, and link controls to the requirements they satisfy. The pane also manages your asset inventory (IT systems, data stores, physical locations), process register, and risk catalogue. Everything connects: a control is linked to one or more requirements, one or more assets, and optionally to risks — so you can trace from a framework clause all the way down to the specific system and team responsible.

In Implement, each measure represents a security or compliance practice (e.g. 'Access reviews are performed quarterly'). Measures are linked upward to one or more requirements across frameworks — one measure can satisfy clauses in ISO 27001, NIS2, and SOC 2 simultaneously. Controls are the operational instances of measures: they carry an owner, implementation status, control type (preventive, detective, corrective), and linked evidence. This three-tier hierarchy (requirement → measure → control) is how Acuna avoids duplicate work across multi-framework programmes.

Operate is the day-to-day execution layer. It manages recurring tasks (with configurable frequencies and owners), objectives and KPIs, incident tracking, and third-party registers. Tasks drive control health: when a recurring task is completed on time, the linked control stays green; when it slips, the control turns orange or red, and that status cascades up to the measure and requirement. Operate also houses the KPI dashboard with manual, computed, connector, and webhook data sources, giving management real-time visibility into programme performance.

Each control can have one or more recurring tasks — for example, 'Review access rights quarterly' or 'Test backup restoration monthly.' Tasks are assigned an owner, frequency (daily, weekly, monthly, quarterly, annually, or custom), and a due date. When a task is completed on time, it scores 100 (healthy). Completed late scores 75 (at risk). In progress but not overdue scores 75. Not started past due scores 0 (unhealthy). These scores roll up to the parent control, then to the measure, then to the requirement — so a missed task surfaces as a visible gap at every level of the programme.

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.

Acuna grades each vendor's public-facing security posture from A to F and refreshes it daily. This is OSINT, open-source intelligence: an outside-in signal, drawn entirely from a vendor's public footprint, that you hold against what they claim in their questionnaire. The OSINT security grade reflects five areas: email and domain security, encryption, web security, breach exposure, and reputation. You can open any grade to see what drove it. The grade sits alongside the three-dimension risk tier (dependency, reach, impact) on the supplier's profile.

Business Impact Analysis in Acuna scores each business process across configurable impact dimensions — financial, regulatory, reputational, and operational dependency. Each dimension is rated on a consistent scale, and a composite criticality score is calculated automatically. The score drives prioritisation: processes with the highest criticality get RTO/RPO/MTPD targets first, and resilience committees see a ranked priority list. BIA results feed into management dashboards, connect to recovery plans, and link to the asset and supplier dependencies that underpin each process.

RTO (Recovery Time Objective) defines how quickly a process must be restored after a disruption. RPO (Recovery Point Objective) defines how much data loss is acceptable, measured in time. MTPD (Maximum Tolerable Period of Disruption) defines the absolute maximum time a process can be unavailable before the impact becomes unacceptable to the organisation. In Acuna, all three are recorded per process and linked to the owning business unit. The platform flags inconsistencies — for example, an RPO that exceeds the MTPD — and compares targets against actual recovery capabilities during exercises.

Enterprise Risk in Acuna provides a structured risk register where each risk is scored on likelihood and impact across configurable dimensions (financial, operational, reputational, regulatory). Risks are linked to controls, assets, processes, and owners. The module supports risk treatment plans (mitigate, accept, transfer, avoid) with action tracking, residual risk recalculation after control implementation, and heat-map visualisation for management reporting. Risk data integrates with other modules: a high-risk supplier in Supplier Shield or a failed control in Implement surfaces as a risk event automatically.

A risk treatment plan documents how an organisation addresses identified risks. Four standard options exist: mitigate (implement controls to reduce likelihood or impact), accept (acknowledge the risk with formal sign-off), transfer (shift risk to a third party via insurance or outsourcing), and avoid (eliminate the activity that creates the risk). In Acuna, each treatment option is tracked with an owner, due date, linked controls, and progress status. After treatment actions are completed, residual risk is recalculated and the risk register updates automatically — providing auditors with a clear before-and-after trail.

The Data Protection module provides an operational privacy register built around processing activities (Article 30 ROPA). A 7-step wizard guides creation through purpose, legal basis, data subjects, data categories, retention, and transfers, with a four-state workflow (Draft → In Review → Approved → Needs Update). Activities link to assets via a data inventory with personal data grids, to third parties with DPA status and transfer country tracking, and to frameworks (GDPR and Swiss FADP pre-configured). An interactive data flow diagram visualizes how personal data moves across the organisation. A privacy dashboard surfaces PA status distribution, data inventory coverage, DPA completeness, and framework assignments. The module also supports structured migration from OneTrust.

Vanta is purpose-built for companies getting their first SOC 2. For organizations running multiple frameworks simultaneously (ISO 27001, SOC 2, NIS2, DORA, GDPR), Vanta's single-framework origins show. The best Vanta alternatives for multi-framework programs include platforms built for continuous compliance across mature, overlapping obligations. Acuna is designed from the ground up for multi-framework control mapping, shared evidence, and audit defensibility at enterprise scale. Drata and OneTrust each address adjacent problems. Choose based on whether your program is scaling compliance depth or adding your first certification.

OneTrust positions itself as a privacy-led enterprise platform, strongest for organizations where privacy (GDPR, CCPA) sits at the center of the GRC program. The best OneTrust alternatives for broader GRC depth are platforms that integrate privacy, security, quality, and audit programs in one operating rhythm rather than parallel silos. Acuna is built for compliance leaders running multi-framework programs where privacy is one obligation among many (ISO 27001, SOC 2, NIS2, ISO 9001, GDPR). Pricing is organization-based, not per-seat, and the architecture supports quality, privacy, and security in shared evidence.

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.

A compliance calendar is a structured view of every review, audit, assessment, renewal, and regulatory deadline a compliance program must meet. Organizations running multiple frameworks (ISO 27001, SOC 2, GDPR, NIS2) face dozens of recurring obligations per year, from quarterly internal audits to annual surveillance audits to vendor reviews. Compliance calendar software consolidates these into one view, tracks ownership, and surfaces what's overdue. Without it, deadlines live in Outlook and on spreadsheets, making missed obligations common. In Acuna, the calendar spans every framework, every cycle, every owner, with alerts before due dates.

A Record of Processing Activities (ROPA) is the internal register required by GDPR Article 30 that documents how your organisation processes personal data — purpose, data categories, recipients, transfers outside the EU or EEA, retention periods, and security measures. Controllers and processors must keep one in writing and produce it to a supervisory authority on request. It is the source of truth that a DPIA, a DSAR, a breach assessment, and a transfer assessment all read from. Acuna's data privacy management treats each processing activity as a living record tied to your asset and vendor inventory, so the people closest to the data keep the register honest.

A Data Protection Impact Assessment (DPIA) is mandatory under GDPR Article 35 whenever processing is likely to result in a high risk to the rights and freedoms of individuals. Article 35(3) names three cases that always require one: systematic and extensive profiling with legal effects, large-scale special-category data processing, and systematic monitoring of a publicly accessible area at scale. The EDPB adds nine criteria; two or more typically require a DPIA. Acuna's data privacy management carries a built-in screener against the EDPB criteria on every processing activity, so the question is answered as part of recording the activity, not as a separate project.

Under GDPR Article 33, a controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it — unless the breach is unlikely to result in a risk to individuals. Where the breach is likely to result in a high risk, the controller must also notify affected data subjects under Article 34. The clock starts at awareness, not at the conclusion of the investigation; Article 33(4) permits phased notification as facts emerge. Every breach must be documented under Article 33(5) whether or not it meets the notification threshold.

Under GDPR Article 12(3), a controller must respond to a data subject access request without undue delay and within one month of receiving it. The period can be extended by two further months for complex or numerous requests, giving a three-month maximum, provided you notify the individual within the first month and explain the reasons. The legal unit is one month, not 30 days; a month is calculated by the calendar. Acuna's data privacy management tracks each DSAR against a response deadline with a colour-coded countdown, records the one permitted extension with its rationale, and links the request to the processing activities that hold the subject's data.

A Data Processing Agreement (DPA) is the written contract GDPR Article 28 requires whenever a controller engages a processor to handle personal data on its behalf. It must bind the processor to obligations covering the subject matter, duration, nature, and purpose of the processing — plus data subject rights assistance, breach notification, DPIA support, sub-processor controls, and audit access. Without a compliant DPA the processing relationship is unlawful. Acuna's data privacy management generates an Article 28 agreement pre-filled from the processing activity it covers and tracks each agreement through its lifecycle on the matching supplier record in third-party risk management.

A Transfer Impact Assessment (TIA) is the analysis required under GDPR Chapter V before transferring personal data to a country outside the EU or EEA without an adequacy decision. Following Schrems II, relying on Standard Contractual Clauses alone is insufficient: you must assess whether the destination country's law and practice provide essentially equivalent protection and, where it falls short, apply supplementary measures or stop the transfer. Acuna's data privacy management builds the TIA from the cross-border recipients already recorded on a processing activity and defaults to a higher-risk outcome so a transfer has to earn a lower rating rather than be assumed safe.

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.

DORA applies to a broad range of financial entities established in the EU, including credit institutions, payment and electronic money institutions, investment firms, insurance and reinsurance undertakings and intermediaries, crypto-asset service providers, fund managers, trading venues, and more. It also reaches the ICT third-party service providers those entities depend on, and it creates a dedicated oversight regime for providers designated as critical, who become subject to direct supervision by a lead overseer. Scope is deliberately wide, so an EU financial entity should assume it is in scope until it confirms otherwise. DORA is not one-size-fits-all. Smaller and less complex entities apply a simplified version of the ICT risk management framework, calibrated to their scale and risk. Simplified is not exempt: the obligation still applies, at a proportionate depth. The largest and most systemically important entities carry the fullest requirements, including advanced testing. Certain ICT providers, judged critical to the EU financial system, are designated and brought under direct oversight by a lead overseer among the European Supervisory Authorities. This extends supervision to firms that are not themselves financial entities but on which the sector depends. For a financial entity, it means the concentration risk in your ICT supply chain is now a supervisory concern, not only a commercial one, which is exactly why the [third-party risk management](/supplier-shield) register matters.

NIS2 (Directive (EU) 2022/2555) applies to public and private organisations that operate in one of the sectors listed in its annexes and meet a size threshold, generally medium-sized and larger organisations. In-scope organisations are classified as either essential entities or important entities, a distinction that determines the intensity of their supervision and the penalties they face, not whether the obligations apply. Because NIS2 is a directive, the precise scope is set by each member state's national transposition, so the exact boundaries can vary by country. NIS2 splits in-scope organisations into two tiers. Essential entities are the larger organisations in the highest-criticality sectors; important entities are the rest of those in scope. Both tiers must meet the same core risk-management and reporting obligations. The difference is supervisory: essential entities face proactive, ex-ante supervision, while important entities are supervised reactively, ex-post, typically after an incident or evidence of non-compliance. Penalty ceilings also differ between the tiers. NIS2 organises covered sectors into two annexes. Annex I lists sectors of high criticality such as energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration, and space. Annex II lists other critical sectors such as postal and courier services, waste management, chemicals, food, manufacturing of certain products, digital providers, and research. Whether you are essential or important depends on the combination of your sector and your size. As a general rule, NIS2 applies to medium-sized and larger organisations in the covered sectors, using the EU definition of enterprise size. But there are important exceptions where the directive applies regardless of size, for certain types of entity whose disruption would have outsized effect, so the size threshold is a starting point, not a complete test. National transposition can add further specifics. Scope is not a one-time determination. An organisation grows across a threshold, enters a covered sector through an acquisition, or its member state transposes the directive with a wider net than expected. Treating scope as settled is how organisations discover, late, that they were in scope all along.

NIS2 and DORA are two EU frameworks for cybersecurity and operational resilience that came into force around the same time and overlap heavily, but they are not interchangeable. NIS2 (Directive (EU) 2022/2555) is a cross-sector cybersecurity directive covering many industries; DORA (Regulation (EU) 2022/2554) is a finance-specific regulation for digital operational resilience. Where both could apply to the same organisation, DORA generally takes precedence for ICT risk in financial services as the more specific law, the lex specialis principle. A financial entity can therefore be in scope for both, with DORA governing its ICT risk and NIS2 relevant to the extent DORA does not cover. The two differ on instrument, scope, and specificity. NIS2 is a directive, so it is transposed into each member state's national law and its details can vary by country. DORA is a regulation, so it applies directly and uniformly across the EU without transposition. NIS2 spans many sectors; DORA is confined to financial entities and their ICT providers. DORA is also more prescriptive on ICT specifics, such as the register of information and threat-led penetration testing, than NIS2's more general risk-management measures. Where a financial entity would fall under both, DORA is treated as the more specific regime for its ICT risk, and it prevails on the matters it covers. NIS2 recognises this relationship, so the two are designed to fit together rather than duplicate. In practice, a bank manages its ICT risk under DORA and does not also apply NIS2's general measures to the same ground. For a financial entity in scope for both: determine your DORA obligations for ICT risk first, since they are the more specific and prescriptive. Then confirm what, if anything, NIS2 adds beyond DORA's coverage for your organisation, which depends partly on your member state's transposition. The efficient path is to map the shared requirements once, as most of the risk-management and supply-chain substance is common, and only maintain the genuinely distinct pieces separately.

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.

A NIS2 compliance programme comes down to a handful of things done properly: confirm whether you are in scope and as which tier, put in place the Article 21 risk-management measures, stand up incident detection and staged reporting, address supply chain security, and get the management body to approve and oversee it all. The checklist below covers the core areas any programme must address; it is not a substitute for your member state's transposed requirements, which add the specifics. Determine scope and tier: confirm whether you are in scope, in which Annex I or II sector, and whether you are an essential or an important entity. Register with your authority: meet the registration and information obligations your member state's transposition sets for in-scope entities. Implement the Article 21 measures: put in place the ten categories of risk-management measures, covering risk analysis and security policy, incident handling, business continuity and crisis management, supply chain security, security in acquisition and development, policies to assess effectiveness, basic cyber hygiene and training, cryptography, human resources and access control, and multi-factor authentication and secured communications. Stand up incident reporting: build the detection, classification, and staged reporting process required under Article 23, and know who your CSIRT or competent authority is. Address supply chain security: assess and manage the security of your direct suppliers and service providers, as Article 21 requires. Secure management-body approval and oversight: under Article 20, the management body approves the risk-management measures, oversees them, and can be held liable. Training for management is part of this. Maintain evidence: keep the records that show the measures are real and operating, because supervision, proactive for essential entities, will look for them.

NIS2 is a directive, not a regulation, which means it does not apply directly. Instead, each EU member state must transpose it into national law, and it is that national law you actually comply with. The transposition deadline was 17 October 2024, but member states have transposed at different speeds and with different specifics, so the precise obligations, the designated authority, and some thresholds can vary depending on where you operate. For a multi-country organisation, this is the defining practical feature of NIS2. This is the single biggest difference in character between NIS2 and DORA. DORA, a regulation, is uniform across the EU. NIS2, a directive, is a common baseline that each country implements in its own law, so complying with NIS2 really means complying with the NIS2 transposition in each country where you are in scope. A directive sets the objectives every member state must achieve but leaves the form and method to national governments. That allows NIS2 to fit each country's existing legal and regulatory structures, but it means the operative detail lives in national law. Two organisations in the same sector in different member states can face variations in registration, reporting specifics, and supervisory approach. Member states were required to adopt and publish their transposing measures by 17 October 2024. In practice, transposition has been uneven. Because the position by country changes over time, confirm the current status and the operative national law for each member state where you are in scope rather than relying on a general statement. For a single-country organisation: identify your national transposing law and your competent authority, and comply with that. For a multi-country organisation: map the common NIS2 baseline once, then track the national deltas per member state. The baseline is largely shared; the variation is in the specifics, which is a manageable overlay rather than a separate programme per country.