ISO 27001 · the Statement of Applicability
The Statement of Applicability: 93 controls, four columns, one document
Every Annex A control with its status, a justification for each exclusion, and the Statement written as the auditor reads it: the control, whether it applies, whether it is implemented, and why; the statuses travel in the address so the draft can be shared.
Every control starts as applicable and planned, the honest default for a system being built; mark a control implemented when its evidence exists, partly when it is in place for part of the scope, and excluded only with a written reason: an auditor reads the exclusions first.
Where the Statement stands
93 controls applicable, of which 0 implemented, 0 partly and 93 planned; 0 excluded.
Organizational (37)
A.5.1 Written security policies, approved and kept current
Define an approved infosec policy set, publish it to the right people, review it on schedule and on major change.
A.5.2 Who is accountable for what in security
Assign and communicate who owns which security responsibilities.
A.5.3 Splitting sensitive tasks between different people
Split conflicting duties so no one person can both commit and conceal a harmful act.
A.5.4 What leadership must require of everyone
Management requires everyone to actually follow the security rules that apply to them.
A.5.5 Knowing who to contact at the authorities
Know which authorities to contact about security matters, and how, before you need them.
A.5.6 Staying connected to security communities
Stay plugged into security communities to keep threat and practice knowledge current.
A.5.7 Gathering and acting on threat information
Collect and analyse threat information and turn it into action.
A.5.8 Building security into every project
Bake security into how projects are planned and run, whatever the project type.
A.5.9 Knowing what information and equipment you hold
Keep an owned, current inventory of information and the assets that carry it.
A.5.10 Rules for using company information and devices
Set and communicate rules for acceptable use and handling of information and assets.
A.5.11 Getting equipment and data back when people leave
Get equipment and information back when people leave or contracts end.
A.5.12 Grading information by how sensitive it is
Classify information by confidentiality, integrity and availability needs.
A.5.13 Marking information with its sensitivity
Label information according to its classification so handling rules can follow it.
A.5.14 Sending information safely, inside and out
Set rules and agreements for transferring information inside and outside the organization.
A.5.15 Deciding who may reach which systems and data
Decide and enforce who gets access to what, based on business and security needs.
A.5.16 Managing accounts and identities over their life
Manage the full life cycle of identities: one identity per person, deactivated when no longer needed.
A.5.17 Handling passwords, keys and other secrets
Control how passwords and other secrets are issued, stored and used.
A.5.18 Granting, reviewing and revoking permissions
Provision, review and revoke access rights following the access-control rules.
A.5.19 Managing the risk that suppliers bring
Manage the security risks that come with using suppliers.
A.5.20 Putting security terms into supplier contracts
Put the relevant security requirements into supplier contracts.
A.5.21 Security through the technology supply chain
Extend security requirements down the ICT supply chain, not just to direct suppliers.
A.5.22 Keeping watch on suppliers as they change
Watch supplier service delivery and security, and manage changes to it.
A.5.23 Using cloud services safely
Decide how cloud services are acquired, used, managed and exited securely.
A.5.24 Being ready before an incident happens
Plan incident management: processes, roles and responsibilities, defined before incidents happen.
A.5.25 Judging which events are real incidents
Assess events and decide which ones are actual security incidents.
A.5.26 Acting on an incident once it is declared
Respond to incidents following the documented procedures.
A.5.27 Learning from incidents afterwards
Use incident lessons to strengthen controls.
A.5.28 Preserving evidence after an incident
Collect and preserve incident evidence in a way that holds up.
A.5.29 Holding security together during a crisis
Keep security at an appropriate level during disruptions, not just in normal operation.
A.5.30 Keeping technology running through disruption
Make sure ICT can recover to meet continuity objectives: plan, implement, test.
A.5.31 Knowing the laws and contracts that bind you
Identify and keep current the legal and contractual security requirements that apply to you.
A.5.32 Respecting copyright and software licensing
Protect intellectual property rights, yours and others'.
A.5.33 Keeping records safe for as long as required
Protect records against loss, falsification and unauthorized access for as long as required.
A.5.34 Protecting personal data
Meet privacy and PII-protection requirements from law and contracts.
A.5.35 Having security checked by someone independent
Have the security approach independently reviewed at intervals and after significant change.
A.5.36 Checking your own rules are actually followed
Regularly check that security policies and standards are actually followed.
A.5.37 Writing down how things are actually done
Document operating procedures for security-relevant activities and make them available to those who need them.
People (8)
A.6.1 Background checks before hiring
Background-check candidates proportionally to role, law and risk.
A.6.2 Security duties written into employment terms
Put security responsibilities into employment terms.
A.6.3 Training people to work securely
Train everyone on the security they need for their role, and keep it fresh.
A.6.4 Consequences when the rules are broken
Have a formal, communicated process for handling security-policy violations.
A.6.5 Duties that outlast someone leaving or moving
Define which security duties survive job change or departure, and enforce them.
A.6.6 Confidentiality agreements
Use and review NDAs that reflect your protection needs.
A.6.7 Working securely away from the office
Set security measures for people working outside the office.
A.6.8 Making it easy for staff to report problems
Give people a channel to report observed or suspected security events promptly, and make sure they know it.
Physical (14)
A.7.1 Defining the physical boundary you protect
Define and protect perimeters around areas holding sensitive information or assets.
A.7.2 Controlling who gets through the door
Control entry to secure areas so only authorized people get in.
A.7.3 Securing the rooms themselves
Design and apply physical security for offices and facilities.
A.7.4 Watching the premises for intruders
Monitor premises continuously for unauthorized physical access.
A.7.5 Guarding against fire, flood and the like
Design protection against fire, flood, power issues and other physical threats.
A.7.6 Rules for working inside restricted areas
Set rules for how people work inside secure areas.
A.7.7 Leaving nothing sensitive on desks or screens
Keep sensitive material off unattended desks and screens.
A.7.8 Placing equipment where it is safe
Place and protect equipment to reduce environmental and access risks.
A.7.9 Protecting equipment taken off site
Protect devices and media that leave the premises.
A.7.10 Handling disks, drives and removable media
Manage storage media through their life cycle: acquisition, use, transport, disposal.
A.7.11 Depending safely on power, cooling and water
Protect facilities from failures of power and other supporting utilities.
A.7.12 Protecting power and network cabling
Protect power and data cabling from interception, interference and damage.
A.7.13 Maintaining equipment so it keeps working
Maintain equipment correctly to preserve availability, integrity and confidentiality.
A.7.14 Wiping equipment before disposal or reuse
Verify sensitive data and licensed software are removed before disposal or re-use.
Technological (34)
A.8.1 Securing laptops, phones and desktops
Protect information on and accessed through laptops, phones and other endpoints.
A.8.2 Restricting administrator access
Restrict and manage privileged access tightly.
A.8.3 Limiting what each person can open
Restrict access to information and functions per the access-control policy.
A.8.4 Controlling who can reach the source code
Manage read and write access to source code, tools and libraries.
A.8.5 Logging in securely
Use authentication technology and procedures that match access restrictions, with MFA where it matters.
A.8.6 Having enough capacity to keep running
Monitor and adjust resource capacity against requirements.
A.8.7 Defending against malware
Combine technical anti-malware protection with user awareness.
A.8.8 Finding and fixing known weaknesses
Track vulnerabilities in what you run, assess exposure, and remediate.
A.8.9 Keeping systems configured the way you intended
Define, apply, monitor and review secure configurations, including hardening.
A.8.10 Deleting data you no longer need
Delete information when no longer required, wherever it lives.
A.8.11 Hiding data that does not need to be shown
Mask or pseudonymize data where policy and law require it.
A.8.12 Stopping data leaving where it should not
Apply measures that detect and prevent unauthorized data exfiltration.
A.8.13 Backing data up and proving restores work
Back up per policy and test that restores actually work.
A.8.14 Spare capacity so a failure is survivable
Build enough redundancy to meet availability requirements.
A.8.15 Recording what happened on your systems
Produce, protect and analyse logs of activities, exceptions and events.
A.8.16 Watching systems for suspicious behaviour
Monitor systems for anomalies and act on what you find.
A.8.17 Keeping system clocks aligned
Synchronize clocks to approved time sources so logs correlate.
A.8.18 Restricting powerful system tools
Restrict and control utilities that can override system controls.
A.8.19 Controlling what gets installed in production
Manage software installation on production systems securely.
A.8.20 Securing the network itself
Secure, manage and control networks and network devices.
A.8.21 Agreeing security terms for network services
Identify and enforce security requirements for network services, in-house or outsourced.
A.8.22 Keeping networks separated from each other
Segregate network segments by trust and need.
A.8.23 Filtering access to risky websites
Manage access to external websites to cut exposure to malicious content.
A.8.24 Using encryption properly and managing keys
Define and apply rules for effective cryptography, including key management.
A.8.25 Security throughout how software gets built
Apply security rules across the whole development life cycle.
A.8.26 Deciding what an application must do securely
Specify security requirements when building or acquiring applications.
A.8.27 Designing systems on secure principles
Establish secure-engineering principles and apply them to every build.
A.8.28 Writing code that resists attack
Apply secure-coding principles to software you write.
A.8.29 Testing security before anything ships
Define and run security testing through development and at acceptance.
A.8.30 Overseeing security when others build for you
Direct, monitor and review externally developed work against your requirements.
A.8.31 Keeping build, test and live environments apart
Separate and secure dev, test and production environments.
A.8.32 Controlling changes to live systems
Put changes to systems and facilities through change-management procedures.
A.8.33 Using safe data when testing
Select, protect and manage the data you test with.
A.8.34 Auditing systems without disrupting them
Plan audits and tests on production systems so they can't disrupt or expose them.
The document
# Statement of Applicability Written on 14 September 2026 with the free page at getstandardos.com, against Annex A of ISO/IEC 27001:2022, 93 controls. For each control: whether it applies to the scope, whether it is implemented, and the reason it is included or excluded (Clause 6.1.3(d)). The control titles are StandardOS's plain-language descriptions, not the standard's text; the references are the standard's. ## Summary 93 controls applicable: 0 implemented, 0 partly implemented, 93 planned. 0 controls excluded, each with its justification below. ## Organizational (37) | Control | What it is about | Applicable | Implemented | Justification | |---|---|---|---|---| | A.5.1 | Written security policies, approved and kept current | Yes | No | Necessary for the risk treatment within the scope. | | A.5.2 | Who is accountable for what in security | Yes | No | Necessary for the risk treatment within the scope. | | A.5.3 | Splitting sensitive tasks between different people | Yes | No | Necessary for the risk treatment within the scope. | | A.5.4 | What leadership must require of everyone | Yes | No | Necessary for the risk treatment within the scope. | | A.5.5 | Knowing who to contact at the authorities | Yes | No | Necessary for the risk treatment within the scope. | | A.5.6 | Staying connected to security communities | Yes | No | Necessary for the risk treatment within the scope. | | A.5.7 | Gathering and acting on threat information | Yes | No | Necessary for the risk treatment within the scope. | | A.5.8 | Building security into every project | Yes | No | Necessary for the risk treatment within the scope. | | A.5.9 | Knowing what information and equipment you hold | Yes | No | Necessary for the risk treatment within the scope. | | A.5.10 | Rules for using company information and devices | Yes | No | Necessary for the risk treatment within the scope. | | A.5.11 | Getting equipment and data back when people leave | Yes | No | Necessary for the risk treatment within the scope. | | A.5.12 | Grading information by how sensitive it is | Yes | No | Necessary for the risk treatment within the scope. | | A.5.13 | Marking information with its sensitivity | Yes | No | Necessary for the risk treatment within the scope. | | A.5.14 | Sending information safely, inside and out | Yes | No | Necessary for the risk treatment within the scope. | | A.5.15 | Deciding who may reach which systems and data | Yes | No | Necessary for the risk treatment within the scope. | | A.5.16 | Managing accounts and identities over their life | Yes | No | Necessary for the risk treatment within the scope. | | A.5.17 | Handling passwords, keys and other secrets | Yes | No | Necessary for the risk treatment within the scope. | | A.5.18 | Granting, reviewing and revoking permissions | Yes | No | Necessary for the risk treatment within the scope. | | A.5.19 | Managing the risk that suppliers bring | Yes | No | Necessary for the risk treatment within the scope. | | A.5.20 | Putting security terms into supplier contracts | Yes | No | Necessary for the risk treatment within the scope. | | A.5.21 | Security through the technology supply chain | Yes | No | Necessary for the risk treatment within the scope. | | A.5.22 | Keeping watch on suppliers as they change | Yes | No | Necessary for the risk treatment within the scope. | | A.5.23 | Using cloud services safely | Yes | No | Necessary for the risk treatment within the scope. | | A.5.24 | Being ready before an incident happens | Yes | No | Necessary for the risk treatment within the scope. | | A.5.25 | Judging which events are real incidents | Yes | No | Necessary for the risk treatment within the scope. | | A.5.26 | Acting on an incident once it is declared | Yes | No | Necessary for the risk treatment within the scope. | | A.5.27 | Learning from incidents afterwards | Yes | No | Necessary for the risk treatment within the scope. | | A.5.28 | Preserving evidence after an incident | Yes | No | Necessary for the risk treatment within the scope. | | A.5.29 | Holding security together during a crisis | Yes | No | Necessary for the risk treatment within the scope. | | A.5.30 | Keeping technology running through disruption | Yes | No | Necessary for the risk treatment within the scope. | | A.5.31 | Knowing the laws and contracts that bind you | Yes | No | Necessary for the risk treatment within the scope. | | A.5.32 | Respecting copyright and software licensing | Yes | No | Necessary for the risk treatment within the scope. | | A.5.33 | Keeping records safe for as long as required | Yes | No | Necessary for the risk treatment within the scope. | | A.5.34 | Protecting personal data | Yes | No | Necessary for the risk treatment within the scope. | | A.5.35 | Having security checked by someone independent | Yes | No | Necessary for the risk treatment within the scope. | | A.5.36 | Checking your own rules are actually followed | Yes | No | Necessary for the risk treatment within the scope. | | A.5.37 | Writing down how things are actually done | Yes | No | Necessary for the risk treatment within the scope. | ## People (8) | Control | What it is about | Applicable | Implemented | Justification | |---|---|---|---|---| | A.6.1 | Background checks before hiring | Yes | No | Necessary for the risk treatment within the scope. | | A.6.2 | Security duties written into employment terms | Yes | No | Necessary for the risk treatment within the scope. | | A.6.3 | Training people to work securely | Yes | No | Necessary for the risk treatment within the scope. | | A.6.4 | Consequences when the rules are broken | Yes | No | Necessary for the risk treatment within the scope. | | A.6.5 | Duties that outlast someone leaving or moving | Yes | No | Necessary for the risk treatment within the scope. | | A.6.6 | Confidentiality agreements | Yes | No | Necessary for the risk treatment within the scope. | | A.6.7 | Working securely away from the office | Yes | No | Necessary for the risk treatment within the scope. | | A.6.8 | Making it easy for staff to report problems | Yes | No | Necessary for the risk treatment within the scope. | ## Physical (14) | Control | What it is about | Applicable | Implemented | Justification | |---|---|---|---|---| | A.7.1 | Defining the physical boundary you protect | Yes | No | Necessary for the risk treatment within the scope. | | A.7.2 | Controlling who gets through the door | Yes | No | Necessary for the risk treatment within the scope. | | A.7.3 | Securing the rooms themselves | Yes | No | Necessary for the risk treatment within the scope. | | A.7.4 | Watching the premises for intruders | Yes | No | Necessary for the risk treatment within the scope. | | A.7.5 | Guarding against fire, flood and the like | Yes | No | Necessary for the risk treatment within the scope. | | A.7.6 | Rules for working inside restricted areas | Yes | No | Necessary for the risk treatment within the scope. | | A.7.7 | Leaving nothing sensitive on desks or screens | Yes | No | Necessary for the risk treatment within the scope. | | A.7.8 | Placing equipment where it is safe | Yes | No | Necessary for the risk treatment within the scope. | | A.7.9 | Protecting equipment taken off site | Yes | No | Necessary for the risk treatment within the scope. | | A.7.10 | Handling disks, drives and removable media | Yes | No | Necessary for the risk treatment within the scope. | | A.7.11 | Depending safely on power, cooling and water | Yes | No | Necessary for the risk treatment within the scope. | | A.7.12 | Protecting power and network cabling | Yes | No | Necessary for the risk treatment within the scope. | | A.7.13 | Maintaining equipment so it keeps working | Yes | No | Necessary for the risk treatment within the scope. | | A.7.14 | Wiping equipment before disposal or reuse | Yes | No | Necessary for the risk treatment within the scope. | ## Technological (34) | Control | What it is about | Applicable | Implemented | Justification | |---|---|---|---|---| | A.8.1 | Securing laptops, phones and desktops | Yes | No | Necessary for the risk treatment within the scope. | | A.8.2 | Restricting administrator access | Yes | No | Necessary for the risk treatment within the scope. | | A.8.3 | Limiting what each person can open | Yes | No | Necessary for the risk treatment within the scope. | | A.8.4 | Controlling who can reach the source code | Yes | No | Necessary for the risk treatment within the scope. | | A.8.5 | Logging in securely | Yes | No | Necessary for the risk treatment within the scope. | | A.8.6 | Having enough capacity to keep running | Yes | No | Necessary for the risk treatment within the scope. | | A.8.7 | Defending against malware | Yes | No | Necessary for the risk treatment within the scope. | | A.8.8 | Finding and fixing known weaknesses | Yes | No | Necessary for the risk treatment within the scope. | | A.8.9 | Keeping systems configured the way you intended | Yes | No | Necessary for the risk treatment within the scope. | | A.8.10 | Deleting data you no longer need | Yes | No | Necessary for the risk treatment within the scope. | | A.8.11 | Hiding data that does not need to be shown | Yes | No | Necessary for the risk treatment within the scope. | | A.8.12 | Stopping data leaving where it should not | Yes | No | Necessary for the risk treatment within the scope. | | A.8.13 | Backing data up and proving restores work | Yes | No | Necessary for the risk treatment within the scope. | | A.8.14 | Spare capacity so a failure is survivable | Yes | No | Necessary for the risk treatment within the scope. | | A.8.15 | Recording what happened on your systems | Yes | No | Necessary for the risk treatment within the scope. | | A.8.16 | Watching systems for suspicious behaviour | Yes | No | Necessary for the risk treatment within the scope. | | A.8.17 | Keeping system clocks aligned | Yes | No | Necessary for the risk treatment within the scope. | | A.8.18 | Restricting powerful system tools | Yes | No | Necessary for the risk treatment within the scope. | | A.8.19 | Controlling what gets installed in production | Yes | No | Necessary for the risk treatment within the scope. | | A.8.20 | Securing the network itself | Yes | No | Necessary for the risk treatment within the scope. | | A.8.21 | Agreeing security terms for network services | Yes | No | Necessary for the risk treatment within the scope. | | A.8.22 | Keeping networks separated from each other | Yes | No | Necessary for the risk treatment within the scope. | | A.8.23 | Filtering access to risky websites | Yes | No | Necessary for the risk treatment within the scope. | | A.8.24 | Using encryption properly and managing keys | Yes | No | Necessary for the risk treatment within the scope. | | A.8.25 | Security throughout how software gets built | Yes | No | Necessary for the risk treatment within the scope. | | A.8.26 | Deciding what an application must do securely | Yes | No | Necessary for the risk treatment within the scope. | | A.8.27 | Designing systems on secure principles | Yes | No | Necessary for the risk treatment within the scope. | | A.8.28 | Writing code that resists attack | Yes | No | Necessary for the risk treatment within the scope. | | A.8.29 | Testing security before anything ships | Yes | No | Necessary for the risk treatment within the scope. | | A.8.30 | Overseeing security when others build for you | Yes | No | Necessary for the risk treatment within the scope. | | A.8.31 | Keeping build, test and live environments apart | Yes | No | Necessary for the risk treatment within the scope. | | A.8.32 | Controlling changes to live systems | Yes | No | Necessary for the risk treatment within the scope. | | A.8.33 | Using safe data when testing | Yes | No | Necessary for the risk treatment within the scope. | | A.8.34 | Auditing systems without disrupting them | Yes | No | Necessary for the risk treatment within the scope. | The control references are ISO/IEC 27001:2022 Annex A identifiers; the titles are StandardOS's own descriptions. The statuses and the justifications are the company's. This is a document, not a certificate.
The Statement that moves when the evidence does
StandardOS keeps the 93 controls as positions on one screen, turns a control implemented on the day its evidence is attached, keeps every justification with the risk it came from, and prints the Statement the auditor asks for on audit day, dated.
The controls are read from the package's Annex A data, never typed on this page, and their titles are StandardOS's descriptions rather than the standard's wording. Whether a control applies and is implemented is the company's own reading. This is a document, not legal or certification advice.