Comply is your control library and crosswalk. Map a requirement once and it reuses across every framework you carry, so adding NIS2 means adding a framework, not another spreadsheet.
One measure — multiple frameworks
WHAT COMPLY IS
Comply is Acuna's module for multi-framework control mapping. You select the frameworks you must meet, then map each measure once to the requirements it satisfies, so a single control library serves ISO 27001, SOC 2, NIS2, DORA, GDPR, and 50+ frameworks at once. Add a framework and it maps against controls you already have, rather than starting over.
Comply holds your compliance program in one place. You choose the frameworks you carry, set scopes and tags to segment the organization, and build from a common measures library rather than from a blank page. Each measure maps to the requirements it satisfies, across every framework at once, so the work is done once and reused instead of repeated per standard. The result is a single control library where a change updates everywhere, not a set of parallel spreadsheets that drift apart.
Select your frameworks and scope the organization with scopes and tags.
Build from a common measures library, not a blank page.
Map each measure once to the requirements it satisfies across frameworks.
One library, one source of truth, updated in one place.
Frameworks overlap heavily, and Comply is built around that. A requirement is a clause from a framework. A measure is what you do to satisfy it, and one measure can address requirements in several frameworks at the same time. So when you map a measure to an access-control requirement in ISO 27001, the same measure answers the matching requirement in SOC 2 and NIS2 without being rebuilt. That is the crosswalk: the overlap is mapped once, and adding a framework becomes a mapping exercise against work you already have, not a second program.
When the crosswalk is real, a new obligation is a framework you switch on against controls you already hold, so NIS2 or DORA is an addition rather than a parallel program. Every team answers the same control the same way, because there is one source for it. And the manual reconciliation that eats your quarter, the spreadsheet of which control covers which clause, stops being a job at all.
WHEN A REGULATION LANDS
WHEN YOUR TEAM NEEDS AN ANSWER
WHEN QUARTER-END ARRIVES
Before
Open a new tracker. Build the mapping from scratch. Reconcile against everything you already run.
Before
Three spreadsheets. Three versions. Figure out which one is current.
Before
A week reconciling which control covers which clause across which standard.
With Comply
Switch the framework on. It maps against controls you already have.
With Comply
One control. One owner. One answer, regardless of which framework asked.
With Comply
Nothing to reconcile. The mapping was done the moment you added the framework.
Comply ships with 50+ frameworks pre-loaded, with full integration rolling out. These are where most programs start:
Comply defines the program. From there, Implement builds the controls and attaches evidence, Operate runs the risk, monitoring, and recurring work on a cadence, and Assure proves it all to an auditor. They share one set of data, so a measure you map in Comply flows through to the dashboards in Assure.
The crosswalk exists because the people who built it have maintained framework mappings in spreadsheets and refused to do it again. Acuna is built and run by practitioners, with more than a hundred years of combined GRC experience and the Swiss group behind it. Priced by program scope, not per seat. Data in Switzerland and the EU.
FAQ
Related answers
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.
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.
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.
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.
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.
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.
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.
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.
GET STARTED
Book a 30-minute demo scoped to the frameworks you carry, and see the control library built on them. You talk to the people who run the program, not an SDR queue.