Compliance crosswalk · ISO 27001
ISO/IEC 27001:2022 (international) - email + domain controls, mapped to Wiredepth
Framework version: 2022 revision, transition from 2013 version mandatory by October 31 2025
Who this is for. Any organisation pursuing or maintaining ISO/IEC 27001 certification. SaaS, financial services, healthcare, government suppliers, EU privacy- sensitive deployments. The 2022 revision restructured the Annex A controls from 114 across 14 sections to 93 across four themes (Organisational, People, Physical, Technological), with 11 brand-new controls.
Where email + domain controls fit. Mostly under A.5 Organisational (information transfer, supplier relationships) and A.8 Technological(authentication, monitoring, networks security). Several of the new-in-2022 controls map directly: A.5.7 (Threat intelligence) and A.8.16 (Monitoring activities) make continuous posture monitoring an explicit expectation rather than a "nice to have".
How to use this page. The clauses below are the Annex A controls most cited in audit testing of email + domain surfaces. Pair them with your Statement of Applicability (SoA) so each control has a documented Wiredepth-backed implementation reference. For controls that touch the broader information-security management system (ISMS) lifecycle, refer to the standard text and your auditor.
Clause-by-clause mapping
Each row maps a specific ISO 27001requirement to the Wiredepth surface that addresses it. The clause ids are the framework's own naming - verify them against the official text. We use precise language: "addresses" (the tool directly satisfies the control), "supports" (the tool contributes evidence the auditor will need), and "evidence for" (the artifact is part of the attestation package).
| Clause | Requirement | Wiredepth response |
|---|---|---|
A.5.7 Threat intelligence (NEW in 2022) Monitoring | Collect, analyse, and produce threat intelligence relevant to the organisation. Use it to inform technical, tactical, and strategic security decisions. | Threat-intel layer surfaces malware / phishing / active-threat IOC + leak-site mentions for your domains. Brand watchlist enumerates lookalike-domain registrations as an actionable intel feed. |
A.5.14 Information transfer Transport | Establish rules, procedures, agreements, and controls for the secure transfer of information via electronic communications. Includes email. | TLS + MTA-STS analyser proves outbound + inbound mail transport is encrypted to the standard the SoA commits to. Workpapers/tls + workpapers/email-auth produce the per-domain evidence for the audit binder. |
A.5.19 Information security in supplier relationships Inventory | Establish processes and procedures to manage the information-security risks associated with the use of supplier products or services. | Vendor consolidation audit enumerates every authorised email sender as a supplier. Per-supplier posture grade quantifies the information-security risk in that relationship. |
A.5.20 Addressing information security within supplier agreements Inventory | Relevant information-security requirements should be agreed with each supplier based on the type of access, processing, and risk. Includes email-sending vendors. | Per-vendor posture history is the evidence that an information-security clause in a vendor agreement is being met (or isn't). Scheduled compliance PDFs cover supplier-level reporting cadence. |
A.5.23 Information security for use of cloud services Inventory | Processes for acquisition, use, management, and exit from cloud services should be established in accordance with the information-security requirements. | Posture monitoring covers cloud-hosted email senders (Microsoft 365, Google Workspace) and the transactional cloud services authorised via SPF / DKIM. De-authorisation guides at /docs/deauthorize cover the exit step. |
A.5.30 ICT readiness for business continuity (NEW in 2022) Monitoring | ICT readiness should be planned, implemented, maintained, and tested based on business continuity objectives and ICT continuity requirements. | Continuous monitoring is the readiness signal. Hosted DMARC report inbox catches authentication-failure spikes that often precede a continuity-affecting incident. |
A.8.5 Secure authentication Authentication | Secure authentication technologies and procedures should be implemented based on information access restrictions and the topic-specific policy on access control. | Sender authentication is the email-specific application of A.8.5: SPF + DKIM + DMARC enforce 'this message is really from this domain'. DMARC alignment + p=reject is the on-the-wire artefact. |
A.8.16 Monitoring activities (NEW in 2022) Monitoring | Networks, systems, and applications should be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information-security incidents. | Hourly scan cadence + alert routing to Slack / Teams / SIEM produces the monitoring evidence. Audit-log Merkle chain (see /docs/verify) gives an auditor cryptographically-verifiable evidence that the monitoring data itself was not modified after the fact. |
A.8.20 Networks security Transport | Networks and network devices should be secured, managed, and controlled to protect information in systems and applications. | TLS analyser + protocol-version checks confirm the email transport surface meets the network-security baseline the SoA commits to. CAA + DNSSEC checks cover the domain-control layer. |
A.8.21 Security of network services Transport | Security mechanisms, service levels, and service requirements of network services should be identified, implemented, and monitored. | MX + MTA-STS posture per domain documents the email-transport network-service contract. Continuous monitoring is the implemented control. |
Clause 9.1 Monitoring, measurement, analysis + evaluation Reporting | The organisation should evaluate the information-security performance and the effectiveness of the ISMS. Determine what needs to be monitored + measured. | Grade-distribution dashboards + scheduled compliance PDFs provide the periodic measurement artefact ISO 27001 Clause 9.1 expects. The audit-log chain (Wiredepth Prove) covers the tamper-evident evidence side. |
What auditors actually look at
An ISO 27001 auditor reviewing the email + domain surface would typically ask for:
- The Statement of Applicability (SoA) entries for A.5.14, A.5.19, A.8.16, A.8.20, A.8.23 with linked implementation evidence
- Sampled outputs from the continuous-monitoring control (12 months of alert volumes + grade trends per domain)
- Supplier register of authorised email senders with per-supplier risk assessment
- Incident-management records for any DMARC / phishing events that crossed the reporting threshold
Generate a ISO 27001-tagged evidence pack (Wiredepth Prove)
Prove subscribers can generate a ZIP of all five workpapers + a ISO 27001 README in one click. Single domain, single click, ready to file in your audit binder. See pricing at /pricing#prove ($499/mo standalone, bundled in Enterprise).
Other compliance crosswalks
Disclaimer. This crosswalk is provided for informational purposes. It is not legal advice, audit guidance, or a substitute for engagement with a qualified assessor (QSA for PCI, accountant or QSA for SOC 2, lawyer for HIPAA / NIS2 / SEC). Framework clause ids and language may have been updated since publication; verify against the official text. Wiredepth does not guarantee compliance based on the use of any tool or page on this site.