ISO 27001 Annex A
The organizational controls, sorted by the work they do.
Theme 5 of Annex A holds 37 controls, more than a third of the 93. Read in number order they look like a loose list. Sorted into six working groups, each one gets an owner, a setup and a piece of evidence. This page does that for every control and points to our deeper pages where one exists.
Back to ISO 27001 services01 · Six groups
Thirty-seven controls, six jobs
Annex A numbers the theme in one run. Grouped by purpose, it becomes six areas you can hand to named owners.
The organizational theme is where the rules, relationships and routines live. The technical enforcement mostly sits in theme 8, but the decision about what to enforce, and who answers for it, is made here. That is why a Stage 1 auditor spends most of the document review in this theme.
| Group | Controls | Usual owner | Audit attention |
|---|---|---|---|
| Governance and direction | 5.1 to 5.4, 5.8, 5.37 | Security lead, leadership | Medium: read at Stage 1, then checked for approval and review dates |
| Assets and information handling | 5.9 to 5.14 | IT, data owners | High: the inventory is tested against what the auditor can see |
| Access and identity | 5.15 to 5.18 | IT, engineering leads | Highest: joiners, leavers and reviews are sampled one by one |
| Suppliers and cloud | 5.19 to 5.23 | Procurement, security lead | High: contracts and supplier reviews for the key vendors |
| Threats, incidents and continuity | 5.5 to 5.7, 5.24 to 5.30 | Security lead, on-call engineering | High: incident records and recovery tests |
| Legal and compliance | 5.31 to 5.36 | Legal, compliance lead | Medium: the obligations register and the independent review |
The attention column is our reading of where findings commonly cluster, not a rule. Any control in your Statement of Applicability (SoA) can be sampled.
02 · Governance
Governance and direction
Six controls that decide who is in charge of security and how the rules are written, approved and followed.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 5.1 Policies for information security | One approved top policy, with topic policies beneath it | A short policy signed by the CEO; topic policies in a wiki, each with an owner | Approval record, version history, staff acknowledgements |
| 5.2 Information security roles and responsibilities | Everyone knows which security tasks are theirs | A responsibility chart for the ISMS; owners named in the SoA | The chart, job descriptions, owners matching the SoA |
| 5.3 Segregation of duties | No single person can both make and approve a risky change | Two-person review on production code; two approvers on payments | Repository protection settings and a sample of merged changes |
| 5.4 Management responsibilities | Managers make their teams follow the rules | Policy acknowledgement tracked per manager; security steps in onboarding | Acknowledgement report; a short manager interview |
| 5.8 Information security in project management | Security is considered when a project starts, not bolted on later | A security question set in the project or feature template | Two or three recent projects showing the questions answered |
| 5.37 Documented operating procedures | Routine operations are written down where operators find them | Runbooks for deploys, restores, on-call and onboarding | Runbooks with owners and review dates, compared with practice |
03 · Assets and handling
Assets and information handling
Know what you hold, how sensitive it is, and how it may move.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 5.9 Inventory of information and other associated assets | Know what information and assets exist, and who owns each | An inventory drawn from device management, cloud accounts and SaaS consoles | The inventory, plus a spot check: the auditor names a laptop or bucket and asks you to find it |
| 5.10 Acceptable use of information and other associated assets | Clear rules for using company systems and data | An acceptable use policy accepted at onboarding | Acceptances for a sample of staff |
| 5.11 Return of assets | Devices and data come back when someone leaves | A return step in every offboarding ticket; courier pickup for remote staff | Leaver tickets matched to device records |
| 5.12 Classification of information | Information is rated by the harm its loss would cause | Three or four levels, such as public, internal, confidential, restricted | The scheme and a few data stores tagged with a level |
| 5.13 Labelling of information | People can tell a document's class at a glance | Header labels, storage tags, sensible defaults in the shared drive | Sampled files and buckets carrying the right label |
| 5.14 Information transfer | Information moving between people or firms stays protected | Approved sharing channels; encrypted transfer for customer data | The transfer rules and the drive's external sharing settings |
04 · Access and identity
Access and identity
The rules for access live here. Theme 8 holds the technical locks (8.2, 8.3, 8.5) that enforce them.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 5.15 Access control | One set of rules for who may reach what | A topic policy built on least privilege and role-based groups | The policy and the roles defined in the identity provider |
| 5.16 Identity management | Every person and system account has one managed identity | Single sign-on as the route into apps; service accounts with named owners | Identity provider user list compared with the HR roster |
| 5.17 Authentication information | Passwords, keys and tokens are issued and kept safely | A password manager, multi-factor sign-in, secrets in a vault not in code | Sign-in settings, secret-scanning results |
| 5.18 Access rights | Access is approved, adjusted on moves, removed on exit, and reviewed | Request tickets for access; quarterly review of production and admin rights | Joiner and leaver samples with timestamps; the last review and what it removed |
05 · Suppliers and cloud
Suppliers and cloud relationships
A software company runs on other companies. These five controls govern that dependency, from selection to exit.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 5.19 Information security in supplier relationships | Decide how suppliers are judged before and during use | A supplier register rated by data access and criticality | The register with ratings and owners |
| 5.20 Addressing information security within supplier agreements | Security duties are written into the contract | Data processing terms, breach notice, rights to reports or audit | Signed terms for the most critical suppliers |
| 5.21 Managing information security in the ICT supply chain | Manage risk arriving through software and hardware you depend on | Dependency scanning; approved sources for packages and images | Scan output and the open-source usage rule |
| 5.22 Monitoring, review and change management of supplier services | Keep checking suppliers after the contract is signed | A yearly read of each critical supplier's SOC 2 report or ISO certificate | Review notes, including what you did about the supplier's exceptions |
| 5.23 Information security for use of cloud services (new in 2022) | Govern how a cloud service is chosen, used and left | A cloud standard covering shared responsibility, regions and exit | The standard, a responsibility matrix, an exit note for the main provider |
06 · Incidents and continuity
Threats, incidents and continuity
The largest group: watch the threat picture, handle what gets through, and keep running while you do.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 5.5 Contact with authorities | Know which authorities to contact, and when | A contact list in the incident plan, including CERT-In and the police | The list with a recent review date |
| 5.6 Contact with special interest groups | Learn from peers and security forums | Membership of an industry group or advisory mailing list | Membership or subscription records |
| 5.7 Threat intelligence (new in 2022) | Turn information about threats into action | A few curated feeds reviewed on a schedule, with actions logged | The feed list and a sample of actions taken |
| 5.24 Information security incident management planning and preparation | A response plan with roles exists before it is needed | A plan, a severity scale and an on-call rota | The plan, the rota, a tabletop exercise record |
| 5.25 Assessment and decision on information security events | Sort events into noise or incidents, consistently | Triage criteria in the plan; a ticket per assessed event | A sample of triaged events and the decision on each |
| 5.26 Response to information security incidents | Handle incidents by the plan | Incident tickets with timeline, owner, containment and closure | Two or three incidents traced end to end |
| 5.27 Learning from information security incidents | Each incident makes the controls stronger | A post-incident review with actions tracked to closure | Review notes and the closed actions |
| 5.28 Collection of evidence | Preserve evidence so it can be relied on later | Log retention, a snapshot procedure, custody notes | The procedure and one example of preserved evidence |
| 5.29 Information security during disruption | Security does not lapse during an outage or crisis | Continuity plans that keep access control and logging running | The plan's security sections and a test result |
| 5.30 ICT readiness for business continuity (new in 2022) | Systems can be recovered within agreed targets | Recovery time and recovery point targets per service; tested restores and failovers | The targets, the last test report and its gaps |
07 · Legal and compliance
Legal and compliance
Know the obligations that apply to you, and check that your own rules are kept.
| Control | What it is for | Typical setup in a software company | What the auditor asks to see |
|---|---|---|---|
| 5.31 Legal, statutory, regulatory and contractual requirements | Know which laws and contracts set security duties | An obligations register: the DPDP Act, CERT-In directions, customer contracts | The register with owners and a review date |
| 5.32 Intellectual property rights | Respect software licences and protect your own work | Licence tracking for paid tools; open-source licence checks | Licence inventory and scan output |
| 5.33 Protection of records | Keep records safe from loss or tampering for as long as required | A retention schedule; write-once storage for key records | The schedule and the storage settings |
| 5.34 Privacy and protection of PII | Protect personal data as law and contracts require | A data map, processing records and privacy notices | The data map and how it ties to the ISMS risk register |
| 5.35 Independent review of information security | Someone independent checks the ISMS at planned intervals | Internal audit by a person who does not run the audited controls | Audit reports and the follow-up on findings |
| 5.36 Compliance with policies, rules and standards for information security | Check that the rules are actually followed | Periodic control checks, automated where possible | Check results and the exceptions raised |
Sources: ISO/IEC 27001:2022 Annex A control numbers and names; ISO/IEC 27002:2022 for the purpose of each control, described in our own words. The standards are copyrighted and are not reproduced here.
Questions about the organizational controls
Do all 37 organizational controls apply to a small SaaS company?
Nearly always. These are the controls few companies can justify leaving out.
Most of theme 5 is governance and routine: policy, roles, suppliers, incidents, legal duties. A small team can meet them lightly, but excluding one needs a reason in the SoA that holds against your scope. Exclusions in this theme are rare.
Why does access control appear in both theme 5 and theme 8?
Theme 5 sets the rules; theme 8 holds the technical enforcement.
Controls 5.15 to 5.18 cover the policy and lifecycle of identities and access rights. Controls 8.2, 8.3 and 8.5 cover privileged access, restriction and sign-in strength in the systems themselves. An auditor usually tests them together.
Is the cloud services control just supplier management again?
It builds on it, and adds shared responsibility and exit.
Controls 5.19 to 5.22 apply to every supplier. Control 5.23 adds what is particular to cloud: which security tasks the provider does and which stay with you, where data sits, and how you would leave the service.
Which organizational controls most commonly produce findings?
Access reviews, leaver timing and supplier reviews.
These leave a record every week or quarter, so a missed review or a late removal is easy to spot. Policies written but never acknowledged, and a supplier register with no review notes, are other common findings.
Can one document cover several of these controls?
Yes, if it clearly does the job of each.
An incident plan can serve 5.24 to 5.28, and one supplier procedure can cover 5.19 to 5.22. Point each SoA line to the section that answers it so the auditor can follow.
Put an owner against every organizational control.
An ISO 27001 gap analysis checks all 37 against how your company runs today, and drafts the Statement of Applicability entries with you.