Standards mapping.
Where the regulations and standards we build against live in the platform. A direct map from obligation to architectural surface, designed to be checked, not skimmed.
How to read this
Each row names a standard or regulation, the part of it most often in scope, the property it actually requires of a system, and the surface in our platform where that property is implemented and evidenced. The intent is to make the mapping falsifiable: every claim points to a capability page where the underlying mechanics are described, or to a glossary entry where the standard is summarised.
Scope and applicability vary by deployment. Specific control selection, audit boundary, and reporting cadence are agreed during specification — this page is the starting point, not the boundary.
Standards → platform surfaces.
01
SOC 2 Type II
Trust Services Criteria · CC1–CC9, A1, C1, PI1
What it requires
Operating effectiveness of controls across security, availability, confidentiality, and processing integrity over a defined audit window. Continuous evidence rather than point-in-time attestation.
02
ISO 27001
Annex A control families A.5–A.18 (2013) / A.5–A.8 (2022)
What it requires
Risk-based information security management with documented controls, internal audit, management review, and continual improvement.
03
PCI-DSS v4.0
All 12 requirement domains; SAQ scoping varies by deployment
What it requires
Cardholder data protection through network segmentation, encryption in transit and at rest, strong authentication, vulnerability management, and continuous monitoring.
Where it lives
04
FIPS 140-2 / 140-3
Cryptographic module validation (Level 2 or higher per use case)
What it requires
Validated cryptographic modules for key generation, storage, and use. HSM-backed key management with documented rotation and quorum-controlled recovery.
Where it lives
05
DORA
EU Regulation 2022/2554 — ICT risk, incident reporting, resilience testing, third-party risk
What it requires
Identification of important business services, impact tolerance setting, severe-but-plausible scenario testing, third-party ICT register, major-incident notification within regulatory windows.
06
ISO 20022
Payment messaging (pacs, pain, camt) for regulated payment rails
What it requires
Structured payment messaging with rich remittance data; correct mapping of legacy MT messages where coexistence applies; field-level validation against rail-specific usage guidelines.
07
BCBS 239
Risk data aggregation and risk reporting (G-SIBs and D-SIBs)
What it requires
Accurate, complete, and timely risk data aggregation across legal entities and risk types, with full lineage and the ability to reproduce any reported number on demand.
08
SR 11-7
US Federal Reserve guidance on model risk management
What it requires
Model inventory, independent validation, ongoing monitoring, and full lineage from input data through model logic to consumed output — reproducible at any point.
09
NIST SP 800-63-3
Identity assurance (IAL), authenticator assurance (AAL), federation (FAL)
What it requires
Risk-tiered identity proofing, phishing-resistant authenticators (FIDO2/WebAuthn at AAL3), federated assertion handling with replay and binding protections.
Where it lives
10
UK GDPR / DPA 2018
Data protection principles, lawful basis, data subject rights, transfers
What it requires
Documented lawful basis per processing activity, ROPA, DPIAs for high-risk processing, subject access workflows within statutory windows, transfer impact assessments for non-UK flows.
11
DCB0129 / DCB0160
NHS clinical risk management for health IT (manufacturer / deploying organisation)
What it requires
Named Clinical Safety Officer, hazard log, safety case, structured clinical risk review at design and deployment.
Where it lives
What this is, and is not.
This is a design-and-architecture mapping, not a certification register. Possessing the architecture for a control is necessary but not sufficient for the corresponding attestation, which requires audit evidence over a defined window.
Where a standard is named without a version, the current effective version applies. Where versions are in transition (PCI v3.2.1 → v4.0, ISO 27001:2013 → :2022), reference deployments are specified to the newer revision and back-mapped on request.
Sectoral regimes not listed here — NIS2, IEC 62443, HIPAA, CJIS, OFGEM, FCA SYSC, MiFID II RTS — are added on engagement when in scope. The same mapping discipline applies.
Where to go from here.
Regulatory & compliance engines
The capability that owns rule encoding, evidence production, and examination packs across the standards above.
ViewSecurity infrastructure
Zero-trust foundations, HSM-backed cryptography, detection engineering, and continuous control assurance.
ViewThe discipline of immutable evidence
How we treat audit-grade evidence as an architectural property rather than a reporting afterthought.
View