ISO 27001 Annex A controls, explained one by one

How to read these pages

The standard gives each control a short title and a paragraph of requirements. These pages keep the title as an identifier and explain the rest in plain words, with the evidence that usually proves it. The decisions live elsewhere. Your Statement of Applicability holds them: every control, whether it applies, why, and how it is met. For how a small team works through the list, read Annex A for startups.

Organizational controls

How the company runs security: policies, roles, suppliers, incidents, continuity and legal duties. Most of these are written decisions and the records that show you follow them. There are 37 of them, A.5.1 to A.5.37. Each line below says why the control exists, in the words a Statement of Applicability would use. Start with the ones that apply.

• A.5.1, security policies: to give everyone written security rules that leadership has approved.
• A.5.2, security roles: to make one named person answerable for each part of security.
• A.5.3, segregation of duties: to stop one person from making and approving the same sensitive change alone.
• A.5.4, what managers must enforce: to have managers hold their teams to the security rules.
• A.5.5, contact with authorities: to reach regulators and law enforcement quickly when an incident requires it.
• A.5.6, security communities: to hear about new threats and fixes from security communities early.
• A.5.7, threat intelligence: to learn about threats to companies like it and act before they cause harm.
• A.5.8, security in projects: to build security into each project from the start rather than add it late.
• A.5.9, asset inventory: to know every device, account, data store and piece of software it relies on, and who owns each.
• A.5.10, acceptable use: to make clear how staff may use company devices and information.
• A.5.11, returning assets: to get company devices and information back when people leave.
• A.5.12, classifying information: to protect information according to how sensitive it is.
• A.5.13, labeling information: to show people at a glance how sensitive information must be handled.
• A.5.14, sending information out: to share information outside the company only in safe, agreed ways.
• A.5.15, access control rules: to give people only the access their job needs.
• A.5.16, identities and accounts: to tie every action on its systems to one named person.
• A.5.17, passwords and secrets: to keep passwords and secrets from being guessed, reused or shared.
• A.5.18, granting and removing access: to remove access people no longer need before it can be misused.
• A.5.19, supplier security: to avoid relying on suppliers that would put its information at risk.
• A.5.20, security in supplier contracts: to bind suppliers to the security terms its information needs.
• A.5.21, technology supply chain: to manage the risk from the providers its technology suppliers rely on.
• A.5.22, watching your suppliers: to notice and act when the service or security of a supplier changes.
• A.5.23, cloud services: to keep the cloud services it uses configured and governed securely.
• A.5.24, incident readiness: to have a plan and named people ready before an incident happens.
• A.5.25, triaging security events: to decide quickly and consistently which security events are incidents.
• A.5.26, responding to incidents: to contain and recover from incidents in a planned, consistent way.
• A.5.27, learning from incidents: to stop the same incident from happening twice.
• A.5.28, collecting evidence: to keep incident records that would hold up if they are needed later.
• A.5.29, security during a disruption: to keep information protected during an outage or disruption.
• A.5.30, technology continuity: to recover its systems as fast as the business needs after a disruption.
• A.5.31, legal and contract duties: to know and meet the laws, regulations and contract terms that set security rules for it.
• A.5.32, intellectual property: to use software and content only as their licenses allow.
• A.5.33, protecting records: to keep important records for the right time and protect them from loss or change.
• A.5.34, personal data protection: to handle personal information the way privacy law and its customer commitments require.
• A.5.35, independent security review: to have someone independent check that its security program works.
• A.5.36, checking policy compliance: to confirm that its security rules are followed in practice.
• A.5.37, written procedures: to have routine and recovery tasks done the same safe way by anyone on the team.

People controls

What happens before, during and after someone works for you: screening, terms, training, discipline, remote work and reporting. Small teams meet these with a handful of signed records. There are 8 of them, A.6.1 to A.6.8. Each line below says why the control exists, in the words a Statement of Applicability would use. Start with the ones that apply.

• A.6.1, background screening: to check new people before they are given access to its information.
• A.6.2, employment terms: to make the security duties of each person part of their terms of work.
• A.6.3, security training: to make sure everyone knows the security basics and their own part in them.
• A.6.4, disciplinary process: to deal fairly and consistently with breaches of its security rules.
• A.6.5, duties after leaving: to end access on the day a person leaves and keep their confidentiality duties in force.
• A.6.6, confidentiality agreements: to bind staff and contractors to keep its information confidential.
• A.6.7, remote work: to keep information safe when people work outside company premises.
• A.6.8, reporting security events: to hear about suspicious activity from staff as soon as they see it.

Physical controls

Buildings, rooms, equipment and media. A remote company with no office can exclude several of these in its Statement of Applicability, with the reason written down, and covers the rest through laptop rules and its cloud provider. There are 14 of them, A.7.1 to A.7.14. Each line below says why the control exists, in the words a Statement of Applicability would use. Start with the ones that apply.

• A.7.1, physical perimeters: to keep its premises behind a secure boundary.
• A.7.2, getting into the building: to let only authorized people into its premises, and know who visited.
• A.7.3, securing offices and rooms: to protect the rooms and facilities that hold its information.
• A.7.4, physical monitoring: to detect a break in at its premises.
• A.7.5, environmental threats: to protect its premises and equipment from fire, flood and similar threats.
• A.7.6, working in secure areas: to control who works in rooms that hold sensitive equipment, and how.
• A.7.7, clear desk and screen: to keep unattended screens and papers from being read.
• A.7.8, placing equipment safely: to keep office equipment from being damaged, stolen or overlooked.
• A.7.9, devices off site: to protect laptops and phones taken off company premises, and wipe them if lost.
• A.7.10, storage media: to stop information leaving on removable media unprotected.
• A.7.11, power and utilities: to keep systems running, or failing safely, when power or network supply fails.
• A.7.12, cabling: to protect its power and network cabling from damage and tapping.
• A.7.13, equipment maintenance: to keep its equipment reliable and secure through regular maintenance.
• A.7.14, disposing of equipment: to make sure no information survives on a device that is reused or thrown away.

Technological controls

The controls built into your systems: access, devices, malware, vulnerabilities, backups, logging, networks, encryption and secure development. Exports and settings screenshots prove most of them. There are 34 of them, A.8.1 to A.8.34. Each line below says why the control exists, in the words a Statement of Applicability would use. Start with the ones that apply.

• A.8.1, laptops and phones: to keep company laptops and phones managed, patched and protected.
• A.8.2, privileged access: to limit administrator access to the people who need it.
• A.8.3, restricting access to data: to let people reach only the data their role needs.
• A.8.4, source code access: to stop unauthorized reading or changing of its source code.
• A.8.5, secure sign in: to stop a stolen password alone from opening its important systems.
• A.8.6, capacity: to act before its systems run out of capacity.
• A.8.7, malware protection: to keep malware off its devices and servers.
• A.8.8, vulnerability management: to find and fix software weaknesses before they are exploited.
• A.8.9, configuration management: to build systems from a known secure configuration and keep them that way.
• A.8.10, deleting information: to delete information once it is no longer needed.
• A.8.11, data masking: to hide sensitive data from people who do not need to see it.
• A.8.12, data leak prevention: to stop sensitive data leaving the company by accident or on purpose.
• A.8.13, backups: to restore its data after loss or corruption.
• A.8.14, redundancy: to keep key systems running when one part fails.
• A.8.15, logging: to keep a record of security events long enough to investigate them.
• A.8.16, monitoring for anomalies: to spot unusual activity and have a named person act on it.
• A.8.17, clock synchronization: to line up the times in its logs so events can be traced.
• A.8.18, powerful admin utilities: to limit powerful administration tools to the people who need them.
• A.8.19, installing software: to keep unapproved software off its servers and staff devices.
• A.8.20, network security: to allow only the network traffic its systems need.
• A.8.21, network services: to set up the network services it uses and provides securely.
• A.8.22, network segregation: to keep production apart from development and test.
• A.8.23, web filtering: to block staff devices from known harmful websites.
• A.8.24, encryption: to protect data with encryption when it is stored and when it moves.
• A.8.25, secure development: to build security into every step of making its software.
• A.8.26, application security needs: to write down security needs before a feature is built.
• A.8.27, secure architecture: to design its systems on agreed security principles.
• A.8.28, secure coding: to avoid common security mistakes in its code.
• A.8.29, security testing: to test new and changed software for security before release.
• A.8.30, outsourced development: to hold outside developers to its security standards.
• A.8.31, separate environments: to stop development and test work from affecting production.
• A.8.32, change management: to approve, test and trace every change to production.
• A.8.33, test data: to keep real customer data out of test environments.
• A.8.34, audits on live systems: to run audits and tests without disrupting or exposing live systems.

Where SOC 2 overlaps

Most of these controls ask for evidence a SOC 2 examination also tests, so one set of records can serve both when each record names what it proves. Every control page lists the SOC 2 criteria that cover the same ground, and the Trust Services Criteria pages link back. For the bigger differences between the two, read SOC 2 vs ISO 27001.