- A properly structured Zero Trust implementation produces compliance evidence as a natural output, not a separate workstream.
- ON2IT's technical measure repository (12 categories, 33 measures) is mapped to 9 major frameworks, including ISO 27001, NIST 800-53, SWIFT CSP, DORA.
- The SWIFT Gateway worked example shows one relevance score and one policy simultaneously satisfying SWIFT CSP, ECB/DNB, DORA, and PCI DSS.
- Compliance evidence becomes continuous and real-time (AUXO™ logs) instead of assembled manually before every audit.
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 Current State | The Zero Trust Answer |
|---|---|
| Most security organisations treat compliance as something that sits beside their technical security programme: a checklist to be completed after the architecture is built. The result: dispersed security measures with no single line of sight, manual evidence collection before every audit, and a compliance burden that grows every time a new regulation lands. | The technical measures that make up a Zero Trust architecture (encryption, identity governance, traffic segmentation, logging, threat management) are the same measures that compliance frameworks require. One implementation simultaneously satisfies MITRE, ISO 27001, NIST 800-53, FedRAMP, DNB, CIS Controls, PCI DSS, SWIFT CSP, and NEN 7510. Compliance becomes an output, not a parallel effort. |
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
In our experience, 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.
01 · Confidentiality
Risk if data is accessed without authorisation, ranging from no sensitive data (negligible) to sensitive personal or financial data with serious legal and regulatory impact.
02 · Integrity
Risk if data is modified without authorisation, same scale as confidentiality, assessed independently because the impact profile differs by asset type.
03 · Availability
Recovery time and recovery point objectives. Time-critical systems (RTO under 60 minutes) score high. This is especially significant for DORA and NIS2 obligations.
04 · Personal Data (extended)
Volume and sensitivity of personal data processed, from none (negligible) to special category personal data (photos, health, religion, criminal records). Directly maps to GDPR and NEN 7510 obligations.
05 · Business Criticality (extended)
Impact on core business processes, from no impact to immediate significant impact on core operations. Industrial control systems and payment infrastructure score highest here.
06 · Subject to Audit (extended)
Whether the protect surface falls within the scope of a regulatory audit obligation. A protect surface subject to external audit requires documented evidence of operational controls, not just their presence.
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.
| Field | Step 1 Result · SWIFT Gateway Protect Surface Definition |
|---|---|
| Protect Surface | SWIFT Gateway: processing and clearing of financial transactions according to SWIFT standards |
| Data | Transaction details: sender, recipient, amount, identifiers. Sensitive financial data with serious regulatory impact |
| Applications | SWIFT Gateway Controller: the system storing and processing transaction records |
| Assets | Servers storing transaction data, hosted in a VMware environment |
| Services | Monitoring of correct transaction processing in line with SWIFT CSP requirements |
| Regulatory scope | SWIFT CSP · ECB/DNB · DORA · PCI DSS, subject to annual Security Attestation under SWIFT CSP |
| Relevance Score | 75/100, Very High across all six dimensions |
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:
| WHO | WHAT | WHEN | WHERE | HOW | WHY |
|---|---|---|---|---|---|
| SWIFT DBA AD user group | SWIFT Gateway Controller Application | Monday to Friday, 08:00 to 18:00 | On-premise HQ network or Office VPN (Benelux) | URL filtering · SSL decryption · SSO authentication · header insertion | Restrict access to sensitive transaction data: prevent abuse and breach |
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 to 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.”
Want more on Zero Trust, MDR, and managed cybersecurity?
Whitepapers, datasheets, infographics, and the Zero Trust Dictionary, all in one library.
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.
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.
| Current State | Unified ZT + Compliance |
|---|---|
| Compliance evidence assembled manually before each audit: a project that competes with operational work | Evidence is continuous and real-time: AUXO™ logs measure implementation and policy enforcement 24/7. Auditors access current data, not reconstructed snapshots. |
| Security teams and compliance teams maintain separate frameworks, separate controls lists, and separate documentation | One framework (the ZT protect surface model) drives both security and compliance. The same policy statement that protects the SWIFT Gateway is the compliance evidence for SWIFT CSP, DNB, and DORA. |
| New regulations (DORA, NIS2, Cyber Resilience Act) create new compliance projects that must be mapped to existing controls after the fact | New regulations are absorbed by updating the framework mapping in the repository. If the required measures are already implemented, the evidence is already there. If new measures are needed, the relevance score triggers them. |
| Boards see compliance as a cost centre with no visibility into whether technical measures are actually operational | Board-level dashboard shows real-time Zero Trust Fitness: per protect surface, per measure, per framework. Risk scores on high-value assets and regulatory alignment visible in one view. |
| SOC and compliance operate independently: an incident response process that doesn't speak the same language as the audit trail | CSIRT incident response and compliance evidence share the same foundation: the protect surface model and its associated logs. A breach in a regulated protect surface produces the documentation for both CSIRT escalation and regulatory notification simultaneously. |
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
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
FAQ
How does Zero Trust reduce the compliance burden?
The technical measures that make up a Zero Trust architecture, such as encryption, identity governance, traffic segmentation and logging, are the same measures compliance frameworks require. When every protect surface implements the measures its relevance score demands, it automatically generates evidence for each framework that requires those measures. Compliance becomes an output of the security programme instead of a separate workstream with its own team, budget and audit trail.
Which frameworks does a single Zero Trust implementation cover?
ON2IT has mapped its technical measure repository, 33 measures in 12 categories, to ISO/IEC 27001:2022, NIST SP 800-53, SWIFT CSP, DNB Good Practice, CIS Controls v8, PCI DSS, NEN 7510, BIO, NIS2 and DORA. MITRE ATT&CK is mapped as well. It is not a compliance framework, but it shows which threat techniques each measure mitigates.
What is a relevance score?
A relevance score rates how critical a protect surface is across six dimensions: confidentiality, integrity and availability, plus personal data, business criticality and whether it is subject to audit. The last three capture the regulatory scope a pure CIA rating misses. If a protect surface contains multiple DAAS elements, the highest individual score determines the collective score. The relevance score then decides which technical measures are mandatory and how much monitoring the protect surface needs.
What is the Kipling Method, and why does it matter for audits?
The Kipling Method defines access policy by answering who, what, when, where, why and how. Access is based on group membership and applications instead of IP addresses and ports, and is limited in time and location. Because the policy states exactly who may access a protect surface and under which conditions, the policy statement itself answers the auditor’s question. No separate documentation is required.
How is continuous compliance evidence different from audit preparation?
In most organisations, evidence is assembled manually before each audit. With compliance built into Zero Trust, AUXO™ logs measure implementation and policy enforcement 24/7. Auditors see current data instead of reconstructed snapshots, and the Test of Design and Test of Effectiveness become continuous rather than point-in-time.