ISMS Copilot
Free tool

ISO 27001 Statement of Applicability Generator

Work through all 93 ISO/IEC 27001:2022 Annex A controls, mark each as applicable, excluded or partial with your justification, and export a structured starter SoA — a draft to refine with your auditor, not a finished artefact.

This produces a STARTER DRAFT only. It does not reproduce ISO/IEC 27001:2022 control titles or normative text — refer to the standard from your national standards body. A real Statement of Applicability must reflect your risk assessment and risk treatment decisions and be reviewed internally before being assessed by a competent auditor or certification body.

1. ISMS scope

0 of 93 controls decided · Applicable: 0 · Excluded: 0 · Partially applicable: 0

Before you export

Fill in the ISMS scope fields above (organization, scope statement, version, date) — a Statement of Applicability is incomplete without them.

  • A.5.1 — No decision recorded yet
  • A.5.2 — No decision recorded yet
  • A.5.3 — No decision recorded yet
  • A.5.4 — No decision recorded yet
  • A.5.5 — No decision recorded yet
  • A.5.6 — No decision recorded yet
  • A.5.7 — No decision recorded yet
  • A.5.8 — No decision recorded yet
  • A.5.9 — No decision recorded yet
  • A.5.10 — No decision recorded yet
  • +83…

2. Annex A control decisions

A.5
A.5.1Policy set: a short, findable set of documents that tell staff the security rules, each with an owner and a last-reviewed date.
A.5.2Allocate and document who is responsible and accountable for each information security activity across the organization.
A.5.3Separate conflicting duties so no single person can both perform and conceal misuse of a process.
A.5.4Make security visible from the top: leaders set expectations in onboarding, all-hands meetings and their own behaviour, not just in a policy PDF.
A.5.5Keep working channels to reach regulators, law enforcement and supervisory bodies before they are urgently needed.
A.5.6Take part in security forums and professional groups to stay current on threats and good practice.
A.5.7Use selected threat sources to turn relevant warning signs into practical security actions.
A.5.8Build security requirements and risk assessment into projects from initiation onward.
A.5.9Maintain a current list of important information resources, supporting systems and responsible owners.
A.5.10Set practical do-and-don't rules for how people use, handle and retire information resources.
A.5.11When someone leaves or moves team, get the laptop, badge, tokens and any company files back, and tick them off a checklist.
A.5.12Grade information by sensitivity so the level of protection matches its value and legal needs.
A.5.13Mark information consistently with its classification so handling rules are unambiguous.
A.5.14Protect information moved between people, systems or organizations under agreed transfer rules.
A.5.15Base access decisions on documented need, risk and approved business purpose.
A.5.16Give every person and workload its own traceable identity, from the day it is created to the day it is switched off.
A.5.17Issue, protect and manage passwords, tokens and other secrets used to authenticate.
A.5.18Keep user permissions current: give only what is needed, check it periodically, and remove it promptly when no longer justified.
A.5.19Know which vendors touch your data or systems, and check their security before you sign and again when you renew.
A.5.20Put security expectations for suppliers into contracts or equivalent written commitments.
A.5.21Extend security requirements through layered ICT product and service supply chains.
A.5.22Keep an eye on key vendors after signing: review their reports and incidents, and reassess when they change how they run your service.
A.5.23Decide how cloud services are approved, operated and exited before using them.
A.5.24Prepare incident roles, playbooks and tools before a real incident occurs.
A.5.25Triage detected security events to decide which qualify as incidents.
A.5.26Contain, eradicate and recover from confirmed incidents following the response plan.
A.5.27After each incident, hold a blameless review and turn what went wrong into tracked fixes.
A.5.28Handle incident evidence in a way that preserves reliability and traceability.
A.5.29Crisis-mode security: make sure emergency workarounds during an outage do not quietly switch off access control, logging or encryption.
A.5.30Set recovery time and data-loss targets for critical systems and run tests that show you can meet them.
A.5.31Maintain a register of outside obligations that affect security and assign owners for satisfying them.
A.5.32Manage software, content and licences so the organization respects others' IP and protects its own.
A.5.33Keep required records reliable, available only to appropriate people, and retained for the required period.
A.5.34Meet privacy obligations for the personal data the organization handles.
A.5.35Arrange periodic outside or impartial checks of how the security programme is working.
A.5.36Check that operations actually comply with the organization's own security policies and standards.
A.5.37Write down recurring operational tasks where consistency matters for security.
A.6
A.6.1Verify candidates' backgrounds proportionately to the role's risk, within legal limits.
A.6.2Include security duties in worker contracts, onboarding documents or equivalent terms.
A.6.3Keep people current through recurring security briefings, training and role-specific learning.
A.6.4Operate a defined, fair process for handling violations of security policy.
A.6.5Define security duties that remain in force after a person leaves or changes role.
A.6.6Put enforceable confidentiality commitments in place for handling protected information.
A.6.7Protect information when people work away from organizational premises.
A.6.8Tell staff exactly where to flag anything suspicious, such as a phishing button or a security inbox, and make flagging painless.
A.7
A.7.1Use walls, doors, barriers or equivalent boundaries to separate sensitive work areas from public or lower-trust space.
A.7.2Control who may physically enter secure areas and when.
A.7.3Make workspaces and facilities harder to misuse, enter or damage.
A.7.4Use alarms, surveillance, patrols or logs to spot and respond to unwanted entry attempts.
A.7.5Guard facilities against fire, flood, power loss and similar environmental hazards.
A.7.6Set rules for how people behave and work inside sensitive areas.
A.7.7Leave no sensitive information exposed on desks or unattended screens.
A.7.8Place and secure equipment so location, environment and access risks are reduced.
A.7.9Protect devices and assets used or stored away from organizational sites.
A.7.10Track and protect storage media from first use through retirement.
A.7.11Provide resilience for utilities that critical equipment depends on.
A.7.12Route and shield important cables so they are harder to tap, tamper with or accidentally break.
A.7.13Maintain equipment so it stays available and secure.
A.7.14Before redeploying or discarding equipment, wipe sensitive content and clear licensed software where required.
A.8
A.8.1Apply baseline protections to laptops, phones and other user devices that handle organizational information.
A.8.2Tightly restrict and monitor elevated administrative access.
A.8.3Limit access to information and functions to what each user needs.
A.8.4Limit repository and build-system access to people and services with a justified need.
A.8.5Use authentication strength and techniques matched to the access risk.
A.8.6Monitor and tune resource use so systems stay available under load.
A.8.7Apply layered defences and user awareness against malicious code.
A.8.8Find, assess and remediate technical vulnerabilities in good time.
A.8.9Keep system and software settings aligned to approved secure baselines.
A.8.10Delete information that is no longer needed to limit exposure and meet obligations.
A.8.11Mask or limit exposure of sensitive data such as personal data.
A.8.12Detect and prevent unauthorized disclosure of sensitive data.
A.8.13Take backups on a schedule, keep at least one copy out of reach of attackers, and run test restores.
A.8.14Add failover capacity where outages would exceed the organization's tolerance.
A.8.15Capture who did what on important systems, protect those logs from tampering, and keep them long enough to investigate.
A.8.16Use technical monitoring to spot unusual activity and route alerts for investigation.
A.8.17Keep system time aligned so event timelines can be trusted.
A.8.18Limit tools that can bypass ordinary controls to approved users and logged use.
A.8.19Stop ad hoc software installs on production: only vetted packages, through a controlled pipeline or allowlist.
A.8.20Secure networks and the devices that operate them.
A.8.21Set security expectations for network services and check they are followed.
A.8.22Split networks into zones to contain risk and limit lateral movement.
A.8.23Use browsing controls to steer users away from known risky or unsuitable web destinations.
A.8.24Decide where encryption is mandatory, which algorithms are allowed, and who can create, rotate and destroy keys.
A.8.25Build security into software across the whole development life cycle.
A.8.26Identify and apply security requirements specific to applications.
A.8.27Use secure design principles when planning and reviewing systems.
A.8.28Use coding practices intended to prevent common security flaws.
A.8.29Check security before new or changed software is accepted.
A.8.30Direct and verify security where development work is outsourced.
A.8.31Keep non-production work from affecting live systems through separate access, data and infrastructure boundaries.
A.8.32Put production changes through a ticket, review and approval, with a tested way to roll back.
A.8.33Keep real customer data out of test environments where possible, and mask or lock down any you have to use.
A.8.34Scope audit testing so live systems are not exposed or disrupted.

Important

This tool generates a starter Statement of Applicability draft from your inputs. It is not legal advice, not an audit, does not certify your organization, and is not a statement of conformity. It does not by itself document all evidence, implementation status or inclusion rationale needed for a final SoA. Your SoA must be derived from your risk assessment and risk treatment, and confirmed with a competent auditor; some requirements are not captured here.

FAQ

Is this a finished Statement of Applicability?
No — it is a structured starter draft. A real SoA must be traceable to your risk assessment and risk treatment decisions and reviewed with your auditor. This tool helps you not miss a control and keep the justifications organised.
Are these the official ISO control titles?
No. We deliberately do not reproduce ISO/IEC 27001:2022 control titles or normative text. Each control shows its number and our own plain-English summary. Use the standard from your national standards body for official wording.
Why must exclusions be justified?
Excluding an Annex A control without a documented, defensible justification is a common audit issue. The tool flags any exclusion or partial status that has no justification so you can fix it before export.
Do you store my answers?
No. Everything runs in your browser. There is no form gate; the CSV/JSON export and printable view are generated locally.

By ISMS Copilot. Structured around ISO/IEC 27001:2022 Annex A. Control summaries are original editorial content; refer to the standard from your national standards body for official titles and normative requirements.

Browse all 21 free compliance tools

Ready to do compliance work faster?

Built for speed, accuracy, and audit-ready output.

Try ISMS Copilot