ISO 27001 Architecture Diagrams: ISMS Scope & Annex A Controls (2026)
How to create ISO 27001 architecture diagrams for ISMS certification. Covers the ISMS scope boundary, Annex A control themes, the Statement of Applicability, risk treatment, and how ISO 27001 diagrams differ from SOC 2 — with AI prompt templates.
ISO 27001 architecture diagrams serve a narrower purpose than a general system diagram: an auditor needs to see exactly which systems, data flows, and controls fall inside your Information Security Management System (ISMS) scope, and which sit outside it. ISO/IEC 27001:2022 doesn't mandate a specific diagram format, but certification bodies consistently ask for a scope diagram, a network/data-flow diagram, and evidence that Annex A controls map onto real infrastructure — not just policy documents. This guide covers what to include.
Core components of an ISO 27001 diagram
- ISMS scope boundary: A clearly drawn line around the systems, teams, locations, and data covered by the certification. Everything inside this boundary is subject to the ISMS; everything outside is explicitly excluded and should be justified in the Statement of Applicability. This is the single most-requested diagram in an ISO 27001 audit.
- Asset inventory: Information assets (databases, code repositories, customer data stores) and supporting assets (servers, cloud accounts, third-party services) that the ISMS protects — grouped by classification (public, internal, confidential, restricted).
- Risk register and treatment plan: The identified risks to in-scope assets and which Annex A controls treat each one. A diagram doesn't need to enumerate every risk, but should show the risk assessment process feeding into control selection.
- Annex A control groups: ISO 27001:2022 organizes 93 controls into four themes — organizational (37), people (8), physical (14), and technological (34). Map controls onto the actual systems that implement them (e.g., access control policy → your IAM/SSO provider) rather than leaving them as an abstract checklist.
- Statement of Applicability (SoA): The document (and, ideally, an accompanying diagram) stating which of the 93 Annex A controls apply, which are excluded, and why. Auditors cross-reference the SoA against your architecture diagrams to confirm claimed controls actually exist.
- Access control and identity architecture: SSO/IdP, MFA enforcement, role-based access, and privileged access management — this maps to Annex A's access control theme and is almost always drawn in detail.
- Logging, monitoring, and incident response flow: Where security events are collected (SIEM), how alerts route to responders, and the escalation path — maps to the technological and organizational control themes.
The four Annex A control themes
| Theme | What it covers on a diagram |
|---|---|
| Organizational | Policies, roles/responsibilities, supplier relationships, incident management process — often shown as a process flow rather than an infrastructure diagram |
| People | Screening, training, disciplinary process, remote-working controls — usually referenced in text, not diagrammed |
| Physical | Data center access controls, equipment security, clear desk/screen — relevant when you diagram physical facility boundaries or on-prem infrastructure |
| Technological | Access control, cryptography, network security, secure development, logging/monitoring, backup, malware defenses — the theme most directly represented in a system architecture diagram |
ISO 27001 vs SOC 2 vs other frameworks
ISO 27001 and SOC 2 overlap heavily in intent — both certify that an organization manages information security seriously — but differ in shape. ISO 27001 certifies an entire management system (the process of identifying and treating risk) against a fixed international standard, while SOC 2 is an attestation report scoped to specific Trust Services Criteria your auditor selects. In practice, many companies pursuing both find their architecture diagrams are largely reusable — the ISMS scope boundary from ISO 27001 and the system description boundary from SOC 2 tend to describe the same infrastructure. See the SOC 2 architecture diagram guide for the trust-criteria-first version of this same exercise.
Prompt examples for ISO 27001 architecture diagrams
ISMS scope diagram for a SaaS company
Annex A technological controls mapped to infrastructure
Incident response process for organizational controls
What to annotate on an ISO 27001 diagram
- Scope boundary justification: Why each in-scope system is included and each excluded system is safely out — auditors probe boundary decisions first.
- Control-to-system mapping: Which Annex A control each labeled system or process satisfies, not just an abstract policy statement.
- Data classification: Public, internal, confidential, restricted — labeled on the data stores that hold each class.
- Third-party and supplier boundaries: Where processors and subprocessors sit relative to your ISMS scope, since supplier relationships are their own Annex A control area.
- Review and revision date: ISO 27001 requires periodic management review of the ISMS — a dated diagram is easier to defend as “current” during a surveillance audit.
Related guides: SOC 2 architecture diagrams, GDPR architecture diagrams, threat modeling diagrams, and zero trust architecture diagrams.
Ready to try it yourself?
Start Creating - Free