Industry Mappings
ADS is deliberately cross-industry — it doesn’t prescribe regulatory content, but it gives you the structure to demonstrate compliance with common industry standards. This page maps ADS sections to the regulatory and governance frameworks architects most often encounter.
GDS / UK Government Service Standard
Section titled “GDS / UK Government Service Standard”The UK Government Digital Service (GDS) Service Standard has 14 points. Here is where each is best evidenced in an ADS SAD:
| GDS Point | ADS Section(s) |
|---|---|
| 1. Understand users and their needs | Section 2.1 Stakeholders; Section 3.6 Scenarios (use cases as user journeys) |
| 2. Solve a whole problem for users | Section 1.2 Business Context; Section 3.6 Scenarios |
| 3. Provide a joined-up experience across all channels | Section 3.2 Integration & Data Flow |
| 4. Make the service simple to use | Section 3.6 Scenarios |
| 5. Make sure everyone can use the service | Section 4.3 Performance (accessibility under broader sense); consider a dedicated Accessibility custom section |
| 6. Have a multidisciplinary team | Section 2.1 Stakeholders; Section 5.6 Resourcing & Skills |
| 7. Use agile ways of working | Section 5.1 Software Development & CI/CD; Section 5.4 Release Management |
| 8. Iterate and improve frequently | Section 5.4 Release Management |
| 9. Create a secure service which protects users’ privacy | Section 3.4 Data View; Section 3.5 Security View; Section 6.8 Compliance Traceability |
| 10. Define what success looks like and publish performance data | Section 4.1 Operational Excellence (KPIs, observability) |
| 11. Choose the right tools and technology | Section 3.1 Logical View; Section 6.7 Architecture Decisions Log |
| 12. Make new source code open | Section 5.1 (development practices); Section 6.6 Guardrail Exceptions if closed |
| 13. Use and contribute to open standards, common components and patterns | Section 1.3 Strategic Alignment (Reuse); Framework Alignment page of this standard |
| 14. Operate a reliable service | Section 4.2 Reliability & Resilience; Section 5.5 Operations & Support |
Tip for GDS assessments: cross-reference each Service Standard point by ID in Section 6.8 Compliance Traceability so assessors can find evidence quickly.
NIST Cybersecurity Framework (CSF) 2.0
Section titled “NIST Cybersecurity Framework (CSF) 2.0”NIST CSF 2.0 organises security around six functions. Each is covered by specific ADS sections:
| NIST CSF Function | Description | ADS Section(s) |
|---|---|---|
| Govern (GV) | Cybersecurity strategy, risk management, policies, roles | Section 6 Decision Making & Governance; Section 2.3 Compliance |
| Identify (ID) | Asset inventory, business context, risk assessment | Section 3.1 Logical View (components); Section 3.4 Data View (data assets); Section 6.1-6.3 (constraints, assumptions, risks) |
| Protect (PR) | Access control, data security, awareness, maintenance | Section 3.5 Security View (identity, encryption); Section 3.4 Data View (classification, retention) |
| Detect (DE) | Continuous monitoring, anomaly detection | Section 3.5 Security View (monitoring); Section 4.1 Operational Excellence (observability) |
| Respond (RS) | Incident response planning, analysis, mitigation | Section 3.5 Security View (incident response); Section 4.2 Reliability (DR plan); Section 5.5 Operations & Support |
| Recover (RC) | Recovery planning, improvements, communications | Section 4.2 Reliability & Resilience (DR, RTO/RPO, backup); Section 5.9 Decommissioning & Legacy Removal (ransomware resilience) |
PCI-DSS v4.0
Section titled “PCI-DSS v4.0”PCI-DSS has 12 high-level requirements. Here is where each is typically evidenced in a SAD for a system handling payment card data:
| PCI-DSS Requirement | ADS Section(s) |
|---|---|
| 1. Install and maintain network security controls | Section 3.3 Physical View (network segmentation, perimeter); Section 3.5 Security View |
| 2. Apply secure configurations | Section 3.3 Physical View (infrastructure hardening); Section 5.1 Development (baseline images) |
| 3. Protect stored account data | Section 3.4 Data View (encryption at rest); Section 3.5 Security View (key management) |
| 4. Protect cardholder data in transit | Section 3.2 Integration & Data Flow (encryption in transit); Section 3.5 Security View |
| 5. Protect from malicious software | Section 3.3 Physical View (security agents); Section 5.1 Development (container scanning) |
| 6. Develop and maintain secure systems | Section 5.1 Development (SAST, DAST, SCA); Section 5.4 Release Management |
| 7. Restrict access by business need | Section 3.5 Security View (authorisation, RBAC) |
| 8. Identify and authenticate access | Section 3.5 Security View (authentication, MFA, PAM) |
| 9. Restrict physical access | Primarily provider concern for cloud (reference in Section 3.3); document if on-premises |
| 10. Log and monitor all access | Section 3.5 Security View (monitoring, SIEM); Section 4.1 Operational Excellence |
| 11. Test security regularly | Section 5.3 Test Strategy (pen testing, vulnerability scanning) |
| 12. Support information security with organisational policies | Section 2.3 Compliance; Section 6.8 Compliance Traceability |
For the Cardholder Data Environment (CDE): explicitly scope the CDE in Section 1.4 Scope, document the CDE components in Section 3.1 Logical View, and show segmentation from non-CDE components in Section 3.3 Physical View.
ISO/IEC 27001:2022
Section titled “ISO/IEC 27001:2022”ISO 27001 controls are in Annex A, organised into 4 themes: Organisational, People, Physical, Technological. Here is where to evidence them in a SAD:
| ISO 27001 Theme | Example Controls | ADS Section(s) |
|---|---|---|
| Organisational (37 controls) | A.5.1 Policies; A.5.7 Threat intelligence; A.5.23 Cloud services | Section 2.3 Compliance; Section 6.8 Compliance Traceability |
| People (8 controls) | A.6.3 Awareness; A.6.6 Confidentiality | Section 2.1 Stakeholders; Section 5.6 Resourcing |
| Physical (14 controls) | A.7.1 Physical security perimeters; A.7.5 Protecting against environmental threats | Section 3.3 Physical View (where on-premises); primarily provider concern for cloud |
| Technological (34 controls) | A.8.5 Secure authentication; A.8.24 Cryptography; A.8.28 Secure coding | Section 3.5 Security View; Section 5.1 Development |
For ISO 27001 certification scope: if the SAD describes a system within scope of the organisation’s ISMS, reference the ISMS in Section 2.3 and map the specific controls applied in Section 6.8 Compliance Traceability.
NHS Data Security and Protection Toolkit (DSPT)
Section titled “NHS Data Security and Protection Toolkit (DSPT)”For NHS / UK health and care organisations, the NHS DSPT is the primary information governance framework. DSPT has 10 National Data Guardian (NDG) standards:
| NDG Standard | ADS Section(s) |
|---|---|
| 1. Personal confidential data | Section 3.4 Data View (classification, PII, SPI); Section 2.3 Compliance |
| 2. Staff responsibilities | Section 2.1 Stakeholders; Section 5.6 Resourcing |
| 3. Training | Out of scope for SAD — reference organisational training in Section 2.3 |
| 4. Managing data access | Section 3.5 Security View (authorisation, PIM) |
| 5. Process reviews | Section 5.4 Release Management; Section 6.8 Compliance Traceability |
| 6. Responding to incidents | Section 4.2 Reliability (DR); Section 5.5 Operations & Support |
| 7. Continuity planning | Section 4.2 Reliability & Resilience (RTO/RPO) |
| 8. Unsupported systems | Section 1.5 Current State; Section 5.8 Maintainability |
| 9. IT protection | Section 3.5 Security View; Section 4.1 Operational Excellence |
| 10. Accountable suppliers | Section 2.1 Stakeholders; Section 3.2 External Integrations; Section 6.4 Dependencies |
Clinical safety additions (DCB0129 and DCB0160): For clinical systems, document the Clinical Safety Officer (CSO) in Section 2.1, the Clinical Safety Case in Section 6.8, and reference the CSO’s sign-off in Section 7.4 Approvals. See the Medwick Healthcare example for a worked healthcare SAD demonstrating these clinical-safety patterns against a fictional national-healthcare framework.
UK GDPR / Data Protection Act 2018
Section titled “UK GDPR / Data Protection Act 2018”| UK GDPR Principle / Right | ADS Section(s) |
|---|---|
| Lawfulness, fairness, transparency | Section 2.3 Compliance; Section 3.4 Data View (legal basis) |
| Purpose limitation | Section 1.4 Scope; Section 3.4 Data View |
| Data minimisation | Section 3.4 Data View (only collect what’s needed) |
| Accuracy | Section 3.4 Data View (integrity controls) |
| Storage limitation | Section 3.4 Data View (retention periods) |
| Integrity and confidentiality | Section 3.5 Security View |
| Accountability | Section 2.1 Stakeholders (DPO); Section 6.8 Compliance Traceability |
| Data subject rights (access, rectification, erasure) | Section 3.4 Data View (retention, deletion); Section 3.6 Scenarios (subject access request flow) |
| International transfers | Section 3.4 Data View (data sovereignty); Section 3.2 External Integrations |
| Breach notification | Section 5.5 Operations & Support (incident response with 72-hour notification) |
DPIA (Data Protection Impact Assessment): Where required, the DPIA is a separate document. Reference it in Section 2.3 Compliance and cross-link from Section 3.4 Data View.
FCA / SYSC (UK Financial Services)
Section titled “FCA / SYSC (UK Financial Services)”For FCA-regulated firms, relevant touchpoints are in SYSC (Senior Management Arrangements, Systems and Controls):
| FCA/SYSC Area | ADS Section(s) |
|---|---|
| SYSC 4: General organisational requirements | Section 2.1 Stakeholders; Section 6 Governance |
| SYSC 7: Risk control | Section 6.3 Risks |
| SYSC 9: Record-keeping | Section 3.4 Data View (retention); Section 3.5 Security View (audit logging) |
| SYSC 13: Operational risk | Section 4.2 Reliability; Section 6.3 Risks |
| SYSC 15A: Operational resilience | Section 4.2 Reliability; Section 5.5 Operations; Section 5.9 Decommissioning |
| Consumer Duty (PRIN 2A) | Section 3.6 Scenarios (customer journey fair outcomes) |
Tips for mapping
Section titled “Tips for mapping”- Don’t copy regulation into the SAD. Reference the control ID in Section 6.8 Compliance Traceability and link to the source document.
- Map once, re-use often. If your organisation has mapped its general controls to these frameworks, reference the corporate mapping rather than repeating it per SAD.
- Be specific. “Meets PCI-DSS” is weak. “Meets PCI-DSS 4.0 Requirements 3.5.1, 3.6.1, and 4.2.1 via AES-256 encryption with AWS KMS customer-managed keys” is strong.
- Include out-of-scope explicitly. “Out of scope of the CDE” is as useful to an assessor as “in scope”.
- Reference external evidence. Penetration test reports, SOC 2 reports, certifications — link them in Section 7.2 Reference Documents.