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.1Maintain a management-approved set of information security policies, communicate them to staff, and review them on a schedule and after major change.
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.4Have leadership actively require and support all staff to apply information security in line with policy.
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.11Recover organizational assets when people leave or change role.
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.16Manage the full lifecycle of digital identities for people and services.
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.19Address the information security risk that arises from using suppliers' products and services.
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.22Periodically check supplier-delivered services and manage security-impacting changes.
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.27Use lessons from incidents to strengthen controls and reduce recurrence.
A.5.28Handle incident evidence in a way that preserves reliability and traceability.
A.5.29Keep essential security protections operating during business disruption.
A.5.30Make sure ICT can recover within the timeframes business continuity requires.
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.8Give people an easy, well-known way to report observed security events promptly.
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.13Create protected backups and prove that restoration works.
A.8.14Add failover capacity where outages would exceed the organization's tolerance.
A.8.15Record activities and events so they can be reviewed and investigated.
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.19Allow only approved software to be installed onto live operational systems.
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.24Apply cryptography and manage keys under a defined policy.
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.32Control changes to systems so security is preserved through change.
A.8.33Select and protect data used for testing.
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.

Ready to streamline your compliance work?

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

Try ISMS Copilot 2.0