One Implementation.
Multiple Frameworks.

Summary

Most organisations run their Zero Trust programme and their compliance programme as two separate workstreams. Two teams, two budgets, two sets of evidence, two audit trails — and a growing sense that neither is quite enough.

They don't have to be separate. A properly structured Zero Trust implementation produces compliance evidence as a natural output. The frameworks and the architecture share the same technical measures. The question is whether you build them together or pay for them twice.

The structural problem

Regulatory requirements — DORA, NIS2, the Cyber Resilience Act, SWIFT CSP, NIST, ISO 27001, PCI DSS, DNB — have multiplied faster than most security programmes can absorb them. Most organisations respond by adding compliance workstreams beside their existing security architecture. This creates redundancy, inconsistency, and two sets of evidence that may not agree with each other. It also means audit preparation becomes a project in itself, separate from the work of actually securing the environment.

Why regulated organisations outperform

Research consistently shows that organisations subject to external regulation perform better at cybersecurity — not because regulation creates good security, but because it forces the kind of asset classification, risk measurement, and board-level reporting that makes security operational rather than aspirational. Zero Trust provides the same structural discipline — and when mapped to compliance frameworks, it provides the evidence base that satisfies both internal governance and external auditors simultaneously.

What the mapping produces

ON2IT has mapped its Zero Trust technical measure repository — 12 categories, 33 individual measures — to the major regulatory frameworks and industry standards. Every protect surface that implements a technical measure automatically generates compliance evidence for the frameworks that require that measure. One implementation decision. Multiple framework controls satisfied. Auditors receive near-real-time evidence that measures are operational and monitored 24/7.

The SWIFT worked example

This guide uses the SWIFT Gateway protect surface — a payment clearance system for financial institutions — as a worked example throughout. It shows how a protect surface is defined, scored, measured, and governed using the five-step model, and how that process simultaneously satisfies SWIFT CSP, ECB/DNB requirements, ISO 27001, NIST 800-53, and PCI DSS — without running a separate compliance programme.

"The complexity of standards and frameworks, together with dispersed asset-oriented security measures and distributed responsibility, leads to an ineffective security organisation. Zero Trust solves both problems at once — or neither." — Bobbert & Timmermans, ON2IT

---

I. The First Decision — How Critical Is This Protect Surface?

The starting point for any compliance-aware Zero Trust implementation is the same as the starting point for Zero Trust itself: define the protect surface and assign it a relevance score. The relevance score determines which technical measures are required, which compliance controls apply, and what level of monitoring the protect surface demands.

Traditional CIA ratings — Confidentiality, Integrity, Availability — capture the technical risk of a protect surface. But they miss two dimensions that regulators and auditors care most about: personal data exposure and audit obligation. A system with low CIA ratings that processes sensitive personal data or sits within regulatory scope carries a compliance burden that a pure CIA score will underestimate. The ON2IT relevance score adds both.

The six dimensions combine to produce a single relevance score. If the protect surface contains multiple DAAS elements, the highest individual score across all elements determines the collective score — the weakest link principle applied to asset classification. The relevance score then drives the selection of technical measures: a high score mandates more controls, more monitoring, and more rigorous policy enforcement.

CISO signal: "The relevance score is not a compliance checkbox. It is the mechanism that connects your business risk appetite to your technical security posture — and to your audit obligations. Without it, you are guessing which controls matter most."

---

II. The SWIFT Gateway — A Worked Example Through All Five Steps

The SWIFT Gateway protect surface — the system that clears international payment transactions for financial institutions — illustrates how the five-step model applies to a high-value, highly regulated asset. It is subject to SWIFT CSP attestation, ECB and DNB supervision, DORA requirements, and potentially PCI DSS. Without a unified approach, compliance with these overlapping frameworks requires five separate evidence trails.

A relevance score of 75 triggers specific mandatory measures: MFA for all access, active security monitoring, anti-DDoS protection for both volumetric and targeted attacks, encrypted traffic inspection, and full audit logging. These requirements come from the relevance score — but they simultaneously satisfy ECB/DNB controls 4.1, 11.1, 11.2, 18.1, and 22.1 without any additional compliance-specific work.

Step 2 maps the transaction flows — in this case, the incoming and outgoing payment flows between the SWIFT Gateway and the systems that feed and consume it, including the HR system that manages DBA role entitlements. Step 3 selects the technical measures the relevance score requires. Step 4 defines the Kipling Method policy:

This single policy statement — group membership rather than source IP, application rather than port/protocol, time-bounded, location-restricted, with content inspection — satisfies the access control requirements of SWIFT CSP, PCI DSS, ISO 27001, and ECB/DNB simultaneously. The same policy that protects the asset generates the compliance evidence. Step 5 (Monitor and Maintain) closes the loop: all access is logged, all exceptions trigger SOC review, and the audit trail is continuous — not reconstructed at audit time.

CISO signal: "A Kipling-structured policy for each protect surface is also the audit response. When an assessor asks 'who has access to the SWIFT Gateway, when, and under what conditions?' — the policy statement is the answer. No separate documentation required."

---

III. The Technical Measure Repository — 12 Categories, 33 Controls, Multiple Frameworks

The Zero Trust architecture for any protect surface is built from a repository of technical measures organised into 12 categories. The relevance score determines which measures are mandatory. The measures are then mapped to the compliance frameworks that require them — so every implementation decision carries a compliance tag from the start, not as an afterthought.

• CAT 01 · Encryption: SSL inspection, encryption at rest, encryption in transit. Maps to MITRE M1020/M1041, ISO 27001 A.8.24, FedRAMP SC-28, DNB 2.3/4.1, SWIFT CSP 2.1/4.1, PCI DSS 3.6/4.1, NEN 7510.
• CAT 02 · Identity & Access Management: Centrally managed IAM, role-based access control, MFA, deviation logging. Maps to MITRE M1036/M1032, ISO 27001 A.5.16/A.8.5, FedRAMP AC-2/IA-2, DNB 6.1/7.1, SWIFT CSP 5.1/5.2, PCI DSS 7.1/8.3.
• CAT 03 · DDoS Protection: Volumetric and targeted attack prevention. Specifically required by ECB/DNB controls and DORA for financial sector protect surfaces. Maps to MITRE M1037.
• CAT 04 · Endpoint Protection: Exploit prevention, malware prevention, ransomware protection. Maps to MITRE M1042/M1049/M1053, ISO 27001 A.8.7, CIS Controls v8 10.1.
• CAT 05 · Traffic Flows: Segmentation, restricted outbound traffic, application-based control, content inspection, URL filtering, behavioural analytics. The largest category — maps to MITRE M1030/M1031/M1021/M1040, FedRAMP AC-17, CIS Controls v8 13.x.
• CAT 06–12 · DevSecOps · Threat Management · Secure Systems · Data · Orchestration · Reporting · Validation: Secure build standards, threat intelligence, vulnerability management, hardened software and hardware, DLP, data classification, automated rules of engagement, KPIs and KRIs, and technical validation via attack simulation. Each maps to corresponding framework controls across the major standards.

Compliance signal: "When an auditor asks for evidence that MFA is in place for access to a regulated protect surface — the measure is already tagged, the policy already enforces it, and the logs already prove it. The Test of Design and Test of Effectiveness are continuous, not point-in-time."

---

IV. The Frameworks a Single ZT Implementation Covers

The mapping is not aspirational. ON2IT has mapped every technical measure in the ZT repository to each of the following frameworks — which means a protect surface that implements the measures required by its relevance score automatically generates compliance evidence for every applicable framework. No separate mapping exercise. No parallel evidence trail.

• ISO/IEC 27001:2022: International information security management — mapped to Annex A controls across all 12 measure categories
• NIST SP 800-53: US federal security controls — the FedRAMP baseline, mapped control by control to each ZT measure
• SWIFT CSP 2022: 23 mandatory + 9 advisory controls across 3 objectives and 8 principles — fully mapped to the measure repository
• DNB Good Practice: Dutch Central Bank prudential framework — based on COBIT and NIST standards, mapped to ZT encryption and identity measures
• CIS Controls v8: Centre for Internet Security prioritised controls — mapped across encryption, identity, endpoint, traffic, and data categories
• PCI DSS v3.2.1: Payment card industry data security standard — particularly relevant for SWIFT Gateway and financial sector protect surfaces
• NEN 7510:2020: Dutch information security standard for healthcare — relevant for hospital and care sector protect surfaces
• MITRE ATT&CK: Not a compliance framework — but the measure-to-MITRE mapping shows which threat techniques each measure mitigates, providing threat-informed compliance evidence
• BIO / NIS2 / DORA: Dutch Government Baseline (BIO), NIS2 Directive, and DORA — EU regulatory requirements applied to critical infrastructure and financial sector organisations

The value of this coverage is not just breadth. It is that a single implementation decision — this protect surface requires MFA and active monitoring — satisfies the MFA requirement in ISO 27001 A.8.5, FedRAMP IA-2, SWIFT CSP 5.1, DNB 7.1, and PCI DSS 8.3 simultaneously. Compliance coverage is a function of implementation quality, not additional compliance work.

Compliance signal: "External framework requirements are not bolt-on after the fact. They are a structural ingredient of every operational process — baked into the protect surface design from the relevance score onwards, not added during audit preparation."

---

V. What Changes When Compliance Is Built Into ZT — Not Beside It

The operational consequences of unifying ZT implementation with compliance evidence are significant across every layer of the security organisation.

CISO signal: "The SOC is the last line of the five-step model. Step 5 — Monitor and Maintain — is not passive observation. It is the operational proof that measures are working, policies are enforced, and the organisation is managing risk in real time. That proof is exactly what regulators require."

---

The Numbers Behind the Argument

• 9 major regulatory frameworks and industry standards satisfied by a single ZT implementation — without parallel compliance workstreams
• 33 individual technical measures in the ZT architecture repository — each mapped to applicable framework controls across all nine standards
• 6 dimensions in the relevance score — CIA plus personal data, business criticality, and subject to audit, ensuring regulatory scope is captured at Step 1
• 24/7 continuous compliance evidence — AUXO™ logs measure implementation and policy enforcement in real time, not as a point-in-time audit reconstruction
• 75 — relevance score of the SWIFT Gateway protect surface, triggering MFA, active monitoring, anti-DDoS, and encrypted inspection as mandatory controls
• 0 additional compliance evidence runs required for frameworks already mapped — implementation quality is compliance coverage

---

Conclusion: The Compliance Burden Is a Design Problem. Zero Trust Is the Design.

The proliferation of regulatory requirements — DORA, NIS2, the Cyber Resilience Act, SWIFT CSP, NIST, ISO 27001, DNB, PCI DSS — is not going to reverse. Every new regulation is another set of controls to satisfy, another audit trail to maintain, another evidence package to assemble. If compliance sits beside the security programme, this burden compounds every year.

Zero Trust does not reduce the regulatory requirements. It changes the architecture from which compliance evidence flows. When protect surfaces are defined with a relevance score that captures regulatory scope from the start, when technical measures are selected from a repository mapped to the applicable frameworks, and when Kipling-structured policies enforce those measures continuously — compliance becomes a natural output of the security programme, not a separate workstream running beside it.

The SWIFT Gateway example demonstrates this concretely. One protect surface, one relevance score, one set of measures, one policy — satisfying SWIFT CSP, ECB/DNB, DORA, and PCI DSS simultaneously. One audit trail, not four. The same model applies to every regulated protect surface in the environment: healthcare OT under NIS2, financial infrastructure under DORA, government systems under BIO. The framework changes. The approach does not.

The compliance burden is a design problem. Zero Trust is the design that solves it.

Source: Bobbert, Y. & Timmermans, T. — "How Zero Trust Eases the Compliance Burden" · ON2IT Whitepaper
Yuri Bobbert, Global CSO · ON2IT & Professor, Antwerp Management School
Tim Timmermans, CISO Netherlands · ON2IT