Annex A Organizational Controls Guide Template (ISO/IEC 27001 A.5)

Annex A Organizational Controls Guide: [Organization name]

A study and working guide to the 37 organizational controls in Annex A of ISO/IEC 27001:2022 + Amd 1:2024 (A.5.1 to A.5.37), with control guidance in ISO/IEC 27002:2022 as the companion reference. For each control it explains, in original wording, what the control is for, how organisations of different sizes typically implement it, which records an auditor usually samples, the most common pitfalls, and which template in this library puts it to work. Use it to train control owners, prepare Statement of Applicability decisions (clause 6.1.3 d) and get ready for internal and certification audits. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose and how to use this guide
2. How organizational controls fit the ISMS
3. Governance, roles and external contacts (A.5.1 to A.5.6)
4. Threat intelligence and projects (A.5.7, A.5.8)
5. Information and asset management (A.5.9 to A.5.14)
6. Identity and access management (A.5.15 to A.5.18)
7. Suppliers and cloud services (A.5.19 to A.5.23)
8. Incident management (A.5.24 to A.5.28)
9. Continuity (A.5.29, A.5.30)
10. Compliance, privacy and assurance (A.5.31 to A.5.37)
11. Size tiers: how the theme scales
12. Self-check questions
13. Records and evidence
14. References

1. Purpose and how to use this guide

The organizational theme is the largest of the four Annex A themes. It holds 37 of the 93 controls and covers everything that is mainly decided and run through policy, process, contracts and governance rather than through technology or physical barriers. Most of these controls touch several departments at once: HR, legal, procurement, IT operations, engineering and top management all own at least one.

This guide serves three uses:

1. Learning. A new ISMS manager, control owner or internal auditor reads one group per session and answers the self-check questions in section 12. The study record in section 13 proves competence under clause 7.2.
2. Designing. During the SoA workshop, the team uses the "typical implementation" and "by tier" notes to decide whether a control is needed and how far to take it, then records the decision in compliance/statement-of-applicability (DOC-ISMS-011).
3. Preparing for audit. Before an internal audit or a certification audit, the control owner checks the "evidence an auditor samples" line against the records actually kept, using isms/control-evidence-matrix (DOC-ISMS-033).

Each control entry has the same six parts: intent (what the control is for, in this library's own words), typical implementation, how it differs by tier, evidence an auditor usually samples, common pitfalls, and the templates that put it to work. The labels next to each control number are short descriptive labels used across this library, not the official titles. The official wording is in ISO/IEC 27001:2022 Annex A, and the implementation guidance is in ISO/IEC 27002:2022.

2. How organizational controls fit the ISMS

ISO/IEC 27001 does not ask an organisation to implement every Annex A control. It asks the organisation to assess risks (clause 6.1.2), choose risk treatment options and determine the controls needed (clause 6.1.3), then compare those controls with Annex A to check that nothing necessary has been left out. The result is the Statement of Applicability: for every one of the 93 controls, whether it is included, why, whether it is implemented, and, for exclusions, why it is not needed.

In practice almost every organisation in scope of an ISMS includes all 37 organizational controls, because they describe basic management practices that any organisation handling information needs. Exclusions are rare and must be defensible. For example, an organisation with no projects at all could not credibly exclude A.5.8, because almost every organisation runs change initiatives of some kind.

ISO/IEC 27002:2022 tags each control with five attribute types: control type (preventive, detective or corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts, operational capabilities and security domains. You can use the attributes to filter and report on your control set, for example to show management how many of your controls are detective. The attributes are optional, and you can define your own.

The flow below shows how a single organizational control moves from risk to evidence. Every entry in sections 3 to 10 sits somewhere on this path.

Three habits make the organizational theme much easier to run:

• One owner per control. Shared ownership means no ownership. Record the owner in the SoA and in the evidence matrix.
• Policy plus proof. A policy says what should happen. An auditor wants to see that it does happen: tickets, logs, signed forms, minutes.
• Link, do not duplicate. Many organizational controls depend on each other (A.5.9 inventory feeds A.5.12 classification, which feeds A.5.13 labelling and A.5.14 transfer). Write each rule once and refer to it.

3. Governance, roles and external contacts (A.5.1 to A.5.6)

A.5.1 Information security policies

• Intent: Without a written, management-backed position on security, every team invents its own rules and nobody can be held to them. This control gives staff one authoritative reference for what the organisation expects and shows that leadership stands behind it.
• Typical implementation: A short top-level policy signed off by top management, a policy index naming each topic policy with its owner and next review date, one intranet page where staff always find the current versions, an acknowledgement step at joining and yearly, and a review cycle (for example yearly, and also after a reorganisation, a major incident or a new regulation).
• By tier: Small: one policy plus 6 to 10 short topic policies. Medium: a full policy index with an owner per policy. Large: a group policy with site or business-unit standards beneath it.
• Evidence an auditor samples: Approved policy with signature or approval record, the policy index with review dates, acknowledgement records, minutes of the last review.
• Common pitfalls: Policies bought off the shelf that describe controls you do not run. Review dates that passed without a recorded review.
• Templates: compliance/information-security-policy (DOC-ISMS-001), isms/isms-policy-framework (DOC-ISMS-005).

A.5.2 Security roles and responsibilities

• Intent: Security work that belongs to everyone tends to be done by no one. The point is that each security task, from approving access to reviewing logs, has a recognisable owner who knows it is theirs and has the authority to act.
• Typical implementation: A RACI across ISMS processes and key controls, security duties written into job descriptions, named deputies for critical roles.
• By tier: Small: one person holds several roles, with documented safeguards against conflicts. Medium: a full-time ISMS manager and a small security team. Large: a CISO, a security office and local security coordinators at each site.
• Evidence an auditor samples: RACI, job descriptions, appointment letters or minutes naming the ISMS manager, interviews with role holders.
• Common pitfalls: A RACI that names departments rather than roles, or roles that nobody holding them recognises.
• Templates: isms/isms-roles-raci (DOC-ISMS-006), isms/isms-competence-training-matrix (DOC-ISMS-026).

A.5.3 Segregation of duties

• Intent: Prevent one person from being able to carry out and hide an error or misuse, by splitting duties that conflict.
• Typical implementation: A conflicting-duties matrix (for example requesting and approving access, writing and deploying code, raising and paying invoices), enforced through roles in systems, with compensating controls such as logging and independent review where splitting is not possible.
• By tier: Small: few people means compensating controls are common, such as peer review and monthly log review by someone else. Medium: role-based separation in key systems. Large: automated conflict checks in identity governance tooling.
• Evidence an auditor samples: The matrix, role definitions, a sample of approvals showing two different people, records of compensating reviews.
• Common pitfalls: Administrators who approve their own access requests. Compensating controls that are written down but never performed.
• Templates: isms/access-control-policy (DOC-ISMS-041), isms/isms-roles-raci (DOC-ISMS-006), ops/access-review.

A.5.4 Management responsibilities for security

• Intent: Security fails quietly when line managers treat it as somebody else's job. This control puts every manager, not only the security team, in the position of setting the example, expecting good practice from their team and following up when it slips.
• Typical implementation: Security duties in manager job descriptions, manager briefings at policy launch, managers confirming team training completion and acting on non-compliance.
• By tier: Small: the leadership team briefs everyone directly. Medium: line managers receive a short briefing pack each year. Large: security objectives in management performance goals and a steering committee with business-unit heads.
• Evidence an auditor samples: Steering committee minutes, manager briefing records, examples of managers following up overdue training.
• Common pitfalls: Confusing this control with clause 5.1 leadership. Clause 5.1 is about top management; A.5.4 is about every manager.
• Templates: isms/isms-steering-committee-charter (DOC-ISMS-007), isms/isms-roles-raci (DOC-ISMS-006), isms/employee-security-handbook (DOC-ISMS-073).

A.5.5 Contact with authorities

• Intent: Know in advance which authorities you may need to contact (regulators, data protection authorities, law enforcement, national CSIRTs, emergency services) and keep the contact routes current.
• Typical implementation: A contact list with authority, purpose, trigger, route and the internal role allowed to make contact, checked at least yearly and linked to incident and breach procedures.
• By tier: Small: one list owned by the ISMS manager. Medium: a list with legal and privacy leads as authorised contacts. Large: a list per country, aligned with each jurisdiction's reporting duties.
• Evidence an auditor samples: The contact list with last verification date, link from the incident response plan.
• Common pitfalls: A list that names people who have left the authority, or no rule on who in the organisation may speak to an authority.
• Templates: isms/authority-special-interest-contacts (DOC-ISMS-069), compliance/incident-response-plan (DOC-ISMS-020).

A.5.6 Contact with special interest groups

• Intent: Attackers share techniques, so defenders benefit from doing the same. Belonging to peer communities gives early warning of new threats, access to practical advice, and a way to benchmark your own practice against similar organisations.
• Typical implementation: A list of memberships with owner, purpose and how information received is used, plus rules on what may be shared externally.
• By tier: Small: one or two free communities and vendor advisories. Medium: membership of a sector information sharing group. Large: several memberships, with participation in working groups.
• Evidence an auditor samples: Membership records, examples of advisories received and acted on.
• Common pitfalls: Memberships that nobody reads, or sharing incident details without a sharing rule.
• Templates: isms/authority-special-interest-contacts (DOC-ISMS-069), isms/threat-intelligence-procedure (DOC-ISMS-045).

4. Threat intelligence and projects (A.5.7, A.5.8)

A.5.7 Threat intelligence (new in 2022)

• Intent: Risk assessments go stale as attackers change tactics. The aim is to turn raw news about attacks, campaigns and exploited weaknesses into decisions that matter to you: which risks have grown, which defences to adjust, and what to watch for.
• Typical implementation: Defined sources (vendor advisories, national CSIRT bulletins, sector groups, commercial feeds where justified), a regular triage meeting, and a log of actions taken, at strategic, tactical and operational levels.
• By tier: Small: monthly review of free sources by the ISMS manager. Medium: weekly triage by the security team with feeds into detection rules. Large: a dedicated function producing reports for management and indicators for the security operations centre.
• Evidence an auditor samples: Source list, triage log, examples of a risk register update or detection rule created from intelligence.
• Common pitfalls: Subscribing to feeds without any analysis, so there is information but no intelligence and no action.
• Templates: isms/threat-intelligence-procedure (DOC-ISMS-045), isms/isms-threat-vulnerability-catalogue (DOC-ISMS-018).

A.5.8 Security in project management

• Intent: Security added after a project goes live is costly and often incomplete. This control makes sure risks are considered at the moments a project can still change course cheaply, whether it is a new system, an office move or a reorganisation.
• Typical implementation: A security checklist at project gates (initiation, design, pre-launch), security requirements in the project plan, risk assessment for significant projects, sign-off by the security role.
• By tier: Small: a one-page checklist in the ticket template. Medium: gates in the project methodology with a security reviewer. Large: a project office that will not close a gate without the security record.
• Evidence an auditor samples: Completed checklists for recent projects, security requirements in project documents.
• Common pitfalls: Applying the checklist only to IT projects, while office moves, mergers and new business processes go unchecked.
• Templates: isms/project-information-security-checklist (DOC-ISMS-046), security/threat-model.

5. Information and asset management (A.5.9 to A.5.14)

A.5.9 Inventory of information and assets

• Intent: You cannot protect, assign or assess what you do not know you have. A maintained list of information and of the things that store or process it, each with an accountable owner, is the starting point for risk assessment and most other controls.
• Typical implementation: An inventory covering information assets, systems, devices, cloud services and key suppliers, each with owner, location, classification and criticality, reconciled with tool data on a schedule.
• By tier: Small: a spreadsheet plus the device management export. Medium: a configuration management database or GRC tool. Large: automated discovery per site, with OT assets in a separate register.
• Evidence an auditor samples: The inventory, owner assignments, last reconciliation record, a sample of assets checked against reality.
• Common pitfalls: Listing hardware only and missing information, SaaS services and data stores.
• Templates: compliance/asset-inventory (DOC-ISMS-012), ops/cmdb-data-model.

A.5.10 Acceptable use of information and assets

• Intent: Tell people clearly how they may and may not use information and the assets that hold it.
• Typical implementation: An acceptable use policy acknowledged at joining and yearly, with handling rules linked to classification.
• By tier: Small: a two-page policy. Medium: a policy plus handling rules per classification level. Large: a group policy with local additions where law requires.
• Evidence an auditor samples: The policy, acknowledgement records for a sample of staff and contractors.
• Common pitfalls: Contractors and temporary staff never asked to acknowledge the policy.
• Templates: compliance/acceptable-use-policy (DOC-ISMS-040), isms/information-labelling-handling-procedure (DOC-ISMS-042).

A.5.11 Return of assets

• Intent: When people leave or contracts end, laptops, tokens, keys and copies of information walk out with them unless someone asks for them back. This control closes that gap at every exit and every role change.
• Typical implementation: A leaver checklist that lists issued assets from the inventory, return confirmation, and follow-up for missing items, including information held on personal devices.
• By tier: Small: the ISMS manager and HR run the checklist. Medium: HR workflow triggers IT tasks. Large: automated leaver workflow across sites with courier returns for remote staff.
• Evidence an auditor samples: Completed leaver checklists matched to HR leaver lists, records of unreturned assets and actions taken.
• Common pitfalls: Forgetting information assets such as paper files, customer data in personal mailboxes, and hardware tokens.
• Templates: isms/offboarding-security-checklist (DOC-ISMS-053).

A.5.12 Information classification

• Intent: Not all information deserves the same effort. Sorting it into a small number of levels, by how much harm its disclosure, corruption or unavailability would cause, lets the organisation spend protection where it matters and gives everyone a shared vocabulary.
• Typical implementation: A scheme with three or four levels, clear criteria and examples, owners who assign the level, and a review when information changes value.
• By tier: Small: three levels (public, internal, confidential). Medium: four levels with examples per department. Large: a group scheme mapped to customer and government schemes where needed.
• Evidence an auditor samples: The scheme, classified entries in the inventory, interviews showing people can apply it.
• Common pitfalls: Too many levels, so nobody uses them, or a scheme that covers confidentiality only.
• Templates: data/data-classification-policy, compliance/asset-inventory (DOC-ISMS-012).

A.5.13 Information labelling

• Intent: Make classification visible so people and systems handle information correctly.
• Typical implementation: Labelling rules per level and format (documents, e-mail, files, physical media), automated labels where tools allow, and exceptions where labelling is impractical.
• By tier: Small: header and footer labels in templates. Medium: default labels in the productivity suite. Large: automated labelling linked to data leakage prevention.
• Evidence an auditor samples: Labelling procedure, samples of labelled documents, tool configuration.
• Common pitfalls: Requiring labels on everything, including public material, so the rule is ignored.
• Templates: isms/information-labelling-handling-procedure (DOC-ISMS-042).

A.5.14 Information transfer

• Intent: Information is most exposed while it is on the move, whether attached to an e-mail, copied to a USB stick, carried by courier or mentioned in a phone call. The goal is that senders know which channel suits its sensitivity and that recipients are bound to protect it.
• Typical implementation: Transfer rules per classification, approved tools for file sharing and secure e-mail, agreements with external parties for regular transfers, and rules for couriers and verbal disclosure.
• By tier: Small: one approved sharing tool and encrypted e-mail. Medium: transfer agreements with key customers and suppliers. Large: managed file transfer and rules for cross-border transfers.
• Evidence an auditor samples: Transfer policy, agreements, tool logs, samples of transfers of confidential data.
• Common pitfalls: Ignoring verbal and physical transfers, and personal file-sharing accounts used for work.
• Templates: isms/information-transfer-policy (DOC-ISMS-043), compliance/transfer-impact-assessment.

6. Identity and access management (A.5.15 to A.5.18)

A.5.15 Access control rules

• Intent: Access decisions made case by case drift towards giving people everything. Written rules on who gets what, and why, give approvers a consistent basis and keep access to the minimum each role needs.
• Typical implementation: An access control policy with role definitions, approval rules, and rules for physical and logical access.
• By tier: Small: roles per main system in one policy. Medium: a role catalogue per application. Large: enterprise roles managed in identity governance tooling.
• Evidence an auditor samples: The policy, role definitions, a sample of user rights compared with role.
• Common pitfalls: Rules that say "least privilege" without defining roles, so every request is judged ad hoc.
• Templates: isms/access-control-policy (DOC-ISMS-041).

A.5.16 Identity lifecycle management

• Intent: Every account is a door. The point is that each one can be traced to a real person or an approved system, exists only as long as that need exists, and never becomes an orphan that an attacker can reuse unnoticed.
• Typical implementation: Unique identities, joiner, mover and leaver processes tied to HR records, rules for shared and service accounts, periodic reconciliation.
• By tier: Small: single sign-on and a monthly check against the staff list. Medium: HR-driven provisioning. Large: automated lifecycle across directories and sites.
• Evidence an auditor samples: Joiner and leaver tickets, a reconciliation of accounts with HR records, service account register.
• Common pitfalls: Orphaned accounts in SaaS tools outside single sign-on, and shared accounts with no owner.
• Templates: isms/access-control-policy (DOC-ISMS-041), ops/onboarding-checklist, isms/offboarding-security-checklist (DOC-ISMS-053).

A.5.17 Authentication information handling

• Intent: Passwords, keys and tokens are what attackers most want to steal. This control makes sure secrets are created, delivered, stored and replaced in a way that keeps them secret, and that people know how to look after the ones they hold.
• Typical implementation: Password and passphrase rules that favour length and screening against known breached passwords over composition rules and fixed-interval changes (change on suspected compromise, in line with NIST SP 800-63B-4), multi-factor authentication, a password manager, secure first-time credential delivery, rules for secrets in code.
• By tier: Small: password manager and multi-factor authentication everywhere. Medium: secrets vault for engineering. Large: phishing resistant authentication for privileged users.
• Evidence an auditor samples: Multi-factor coverage report, password manager enrolment, secret scanning results.
• Common pitfalls: Secrets committed to code repositories, and temporary passwords sent in plain e-mail.
• Templates: isms/access-control-policy (DOC-ISMS-041), security/secrets-management-standard.

A.5.18 Access rights provisioning and review

• Intent: Access that was right when granted becomes wrong as people move, projects end and systems change. The purpose is to keep everyone's rights in step with their current job, through approval at the start, regular checks and prompt removal.
• Typical implementation: Approved requests, periodic reviews by system or information owners, prompt removal on leaving or role change.
• By tier: Small: quarterly reviews of 5 or 6 key systems. Medium: reviews per application with owner sign-off. Large: campaign-based reviews in tooling with evidence exports.
• Evidence an auditor samples: Signed reviews, removal tickets resulting from reviews, time from leaving to account removal.
• Common pitfalls: Reviews that approve everything with no changes, and no follow-up of removals found in the review.
• Templates: ops/access-review, isms/access-control-policy (DOC-ISMS-041).

7. Suppliers and cloud services (A.5.19 to A.5.23)

A.5.19 Security in supplier relationships

• Intent: Every supplier that touches your information or services extends your attack surface. The purpose is to understand what each supplier could put at risk before you depend on it, and to scale the scrutiny to that exposure.
• Typical implementation: A supplier register with risk tier, a pre-contract assessment scaled to risk, and rules for onboarding and offboarding suppliers.
• By tier: Small: register of 20 to 40 suppliers with a short questionnaire for critical ones. Medium: tiered assessments with assurance reports. Large: a third-party risk programme run with procurement.
• Evidence an auditor samples: Supplier register, assessments for critical suppliers, approval records.
• Common pitfalls: Assessing only new suppliers and never the long-standing ones.
• Templates: isms/supplier-register (DOC-ISMS-066), compliance/supplier-security-assessment (DOC-ISMS-067).

A.5.20 Security in supplier agreements

• Intent: Expectations that are not in the contract are hard to enforce. This control turns your security needs into commitments a supplier has accepted, so you have a basis to ask for evidence, demand notification and act when something goes wrong.
• Typical implementation: Standard security clauses or a security schedule covering confidentiality, incident notification, audit rights, subcontracting, data return and deletion.
• By tier: Small: a security addendum for critical suppliers, and acceptance of standard terms for large providers with a recorded risk decision. Medium: clause library negotiated by legal. Large: contract templates per supplier category.
• Evidence an auditor samples: Signed agreements or accepted terms for a sample of suppliers, mapping to requirements.
• Common pitfalls: Signing large providers' standard terms without checking what they actually commit to.
• Templates: isms/supplier-security-agreement-27036 (DOC-ISMS-068), isms/confidentiality-nda (DOC-ISMS-051).

A.5.21 ICT supply chain security

• Intent: Your direct supplier is rarely the whole story: its products contain components, libraries and services from others. The aim is to manage risks hidden further down that chain, such as a compromised software dependency or a counterfeit part.
• Typical implementation: Requirements for suppliers to manage their own suppliers, software bills of materials, dependency scanning, provenance checks for software and hardware.
• By tier: Small: dependency scanning in the build pipeline. Medium: software bills of materials for released products. Large: supplier requirements cascaded through contracts, hardware provenance for OT.
• Evidence an auditor samples: Dependency scan results, software bill of materials, contract clauses on sub-suppliers.
• Common pitfalls: Treating open source components as outside the supply chain.
• Templates: security/supply-chain-security, isms/supplier-security-agreement-27036 (DOC-ISMS-068).

A.5.22 Supplier service monitoring and change

• Intent: A supplier that was sound at signing can weaken later through staff turnover, new subcontractors or cost cutting. Ongoing oversight catches that drift and makes sure changes to its service are assessed before they affect you.
• Typical implementation: Periodic review of critical suppliers (assurance reports, incidents, service levels), change notification rules, reassessment when services change.
• By tier: Small: yearly review of critical suppliers. Medium: quarterly service reviews for top suppliers. Large: continuous monitoring with risk ratings.
• Evidence an auditor samples: Review records, assurance report reviews with bridging letters where needed, actions on findings.
• Common pitfalls: Filing assurance reports without reading the exceptions and the complementary controls they expect you to run.
• Templates: compliance/supplier-security-assessment (DOC-ISMS-067), isms/supplier-register (DOC-ISMS-066).

A.5.23 Security for cloud service use (new in 2022)

• Intent: Cloud services can be switched on in minutes by anyone with a payment card, and responsibilities are split with the provider in ways that are easy to misread. This control brings each cloud service under deliberate decisions, from choosing it through running it to leaving it.
• Typical implementation: A cloud policy with approval rules, the shared responsibility split per service, secure configuration, provider assurance review and exit planning.
• By tier: Small: one main cloud provider with a documented responsibility split and posture checks. Medium: approval process for new SaaS. Large: a cloud centre of excellence with landing zones and guardrails.
• Evidence an auditor samples: Cloud policy, register of cloud services, responsibility matrix, provider assurance review, exit plan.
• Common pitfalls: Assuming the provider is responsible for everything, and no plan for leaving a provider.
• Templates: isms/cloud-services-security-policy (DOC-ISMS-044), isms/cloud-exit-plan (DOC-ISMS-076), isms/cloud-27017-controls (DOC-ISMS-102).

8. Incident management (A.5.24 to A.5.28)

The five incident controls form a single lifecycle. The diagram shows the order in which they normally apply. A.5.28 runs alongside the response, not after it.

A.5.24 Incident management planning

• Intent: Decisions taken in the first hour of an incident are better when they were thought through beforehand. This control is about having the people, procedures, contacts and tools ready before anything happens.
• Typical implementation: An incident response plan with severity levels, roles, contact lists, playbooks for common scenarios, and a yearly exercise.
• By tier: Small: plan plus 3 playbooks and a tabletop exercise. Medium: on-call rota and service provider retainer. Large: a group plan with site plans and a crisis management link.
• Evidence an auditor samples: Approved plan, exercise report, on-call schedule, contact list.
• Common pitfalls: A plan never exercised, so contact details and roles are wrong when needed.
• Templates: compliance/incident-response-plan (DOC-ISMS-020), security/tabletop-exercise.

A.5.25 Assessing security events

• Intent: Not every alert or report is an incident, but treating all of them alike wastes effort or misses real attacks. The purpose is a consistent, recorded judgement on each event, so serious ones are escalated quickly and minor ones are not lost.
• Typical implementation: Triage criteria, a classification scheme, a record of each decision, escalation rules.
• By tier: Small: the ISMS manager triages with a simple decision table. Medium: security team triage within set times. Large: a security operations centre with tiered analysts.
• Evidence an auditor samples: Triage records showing the decision and who made it, classification criteria.
• Common pitfalls: No record of events judged "not an incident", so patterns are missed.
• Templates: isms/security-event-reporting-procedure (DOC-ISMS-023), isms/incident-register (DOC-ISMS-021).

A.5.26 Responding to security incidents

• Intent: Improvised response tends to destroy evidence, miss notification duties and let attackers return. This control makes sure incidents are handled through a known, practised sequence from containment to recovery, with communication along the way.
• Typical implementation: Playbooks, an incident register, decision logs, notification rules for customers and authorities.
• By tier: Small: response led by the ISMS manager with an external responder on call. Medium: in-house team with defined service levels. Large: coordinated response across sites and legal entities.
• Evidence an auditor samples: Incident register, incident tickets, notification records where required.
• Common pitfalls: Closing incidents when service is restored without confirming the cause is removed.
• Templates: compliance/incident-response-plan (DOC-ISMS-020), isms/incident-register (DOC-ISMS-021), compliance/personal-data-breach-assessment.

A.5.27 Learning from incidents

• Intent: An incident that teaches nothing is likely to happen again. The aim is to turn each significant incident into concrete improvements to controls, risk estimates and training.
• Typical implementation: Post-incident reviews for significant incidents, actions tracked to closure, trends reported to management review.
• By tier: Small: short review for every significant incident. Medium: blameless review format with actions in the improvement register. Large: trend analysis across sites.
• Evidence an auditor samples: Post-incident review records, actions and their closure, risk register updates.
• Common pitfalls: Reviews that blame individuals instead of finding control gaps.
• Templates: isms/post-incident-review (DOC-ISMS-022), isms/continual-improvement-register (DOC-ISMS-088).

A.5.28 Evidence collection

• Intent: Evidence handled carelessly may be useless when you need it for a dismissal, a lawsuit, an insurer or a regulator. This control makes sure that, whenever an event may lead to such action, logs, disk images and records are gathered so their integrity can be demonstrated.
• Typical implementation: Evidence handling procedure, chain of custody form, log retention long enough to investigate, specialist support for forensic work.
• By tier: Small: a chain of custody form and an external forensic retainer. Medium: trained staff and forensic tooling. Large: a forensic capability with legal hold procedures per jurisdiction.
• Evidence an auditor samples: Procedure, completed custody forms, log retention settings.
• Common pitfalls: Rebuilding an affected system before evidence is captured.
• Templates: security/forensic-evidence-record, compliance/incident-response-plan (DOC-ISMS-020).

9. Continuity (A.5.29, A.5.30)

A.5.29 Security during disruption

• Intent: Under pressure, people are tempted to share passwords, skip approvals or move data to personal tools just to keep going. This control plans ahead so protection stays proportionate while the organisation is working in crisis mode.
• Typical implementation: Security measures written into continuity plans (access during emergencies, secure alternate sites, protected communications), with tests that include security.
• By tier: Small: security notes in the continuity plan. Medium: emergency access procedures and backup communication channels. Large: integration with an existing ISO 22301 management system.
• Evidence an auditor samples: Continuity plan sections on security, test reports, emergency access records.
• Common pitfalls: Emergency procedures that bypass access control with no logging or later review.
• Templates: compliance/business-continuity (DOC-ISMS-121), isms/crisis-management-communications-plan (DOC-ISMS-078).

A.5.30 ICT readiness for business continuity (new in 2022)

• Intent: Business continuity plans assume that systems will come back in time. This control tests that assumption: the technology, people and procedures needed to restore ICT services are prepared and proven against the recovery targets the business has set.
• Typical implementation: Business impact analysis setting recovery time and recovery point objectives, ICT recovery plans, redundancy, and recovery tests with results compared with objectives.
• By tier: Small: a second cloud region as recovery site with a yearly failover test. Medium: recovery plans per service and a colocation recovery path. Large: recovery tiers per application linked to the group continuity programme.
• Evidence an auditor samples: Business impact analysis, recovery plans, test reports with achieved times.
• Common pitfalls: Recovery objectives set by IT without business input, or tests that never measure the achieved time.
• Templates: isms/ict-readiness-business-continuity-plan (DOC-ISMS-047), compliance/business-impact-analysis (DOC-ISMS-120), ops/dr-test-report.

10. Compliance, privacy and assurance (A.5.31 to A.5.37)

A.5.31 Legal, regulatory and contractual requirements

• Intent: Laws, regulations and contracts impose security duties whether or not you know about them. The aim is a current, shared understanding of which obligations apply and how the organisation meets each one, so none is missed or discovered only during an investigation.
• Typical implementation: A register with requirement, source, owner, affected controls and review date, updated when laws or contracts change.
• By tier: Small: register built with outside counsel, reviewed twice a year. Medium: legal and privacy leads maintain it. Large: one register per country with a group summary.
• Evidence an auditor samples: Register, review records, link from requirements to controls.
• Common pitfalls: A list of law names with no statement of what each requires of the organisation.
• Templates: compliance/legal-register (DOC-ISMS-014).

A.5.32 Intellectual property rights

• Intent: Respect intellectual property, including software licences and third-party content, and protect your own.
• Typical implementation: Software licence inventory, open source licence policy and scanning, rules on copying content, protection of own source code and designs.
• By tier: Small: licence list and open source scanning in the pipeline. Medium: software asset management. Large: licence compliance programme with procurement.
• Evidence an auditor samples: Licence inventory, open source scan results, approval of exceptions.
• Common pitfalls: Unlicensed tools installed by users and open source licences with obligations nobody checked.
• Templates: compliance/legal-register (DOC-ISMS-014), compliance/asset-inventory (DOC-ISMS-012), isms/outsourced-development-security (DOC-ISMS-077).

A.5.33 Protection of records

• Intent: Some records must survive for years and remain trustworthy: contracts, financial entries, audit trails, HR files. The purpose is that such records stay complete, authentic and retrievable for as long as law, contracts or the business require, and are disposed of properly afterwards.
• Typical implementation: A retention schedule, storage with access control and integrity protection, controlled disposal at the end of retention.
• By tier: Small: retention rules in the documented information register. Medium: retention settings in document and e-mail systems. Large: records management function with legal holds.
• Evidence an auditor samples: Retention schedule, storage settings, disposal records.
• Common pitfalls: Keeping everything forever, which creates privacy and discovery risk.
• Templates: isms/isms-documented-information-register (DOC-ISMS-028), data/data-retention-deletion-standard.

A.5.34 Privacy and PII protection

• Intent: Personal data carries legal duties, and mishandling it causes real harm to people. This control ensures the organisation knows which privacy obligations apply to the personal data it handles and builds the security measures needed to honour them.
• Typical implementation: A privacy programme with records of processing, data protection impact assessments, processor agreements, data subject request handling and breach procedures.
• By tier: Small: processor obligations from customer agreements tracked in one register. Medium: privacy lead with impact assessments and a plan for a privacy information management system. Large: a privacy office per region.
• Evidence an auditor samples: Records of processing, impact assessments, processor agreements, request logs.
• Common pitfalls: Treating privacy as a legal topic only, with no link to the security controls that protect personal data.
• Templates: compliance/gdpr-ropa, compliance/dpia, isms/pims-27701-scope-roles (DOC-ISMS-100).

A.5.35 Independent review of security

• Intent: People who design and run controls are poorly placed to spot their own blind spots. A fresh look by someone independent, repeated over time and after major change, gives management an objective view of whether the approach to security still works.
• Typical implementation: Independent reviews by internal audit, an external assessor or a peer from another unit, with findings reported to management.
• By tier: Small: an external reviewer once a year. Medium: internal audit plus an external review every year or two. Large: group internal audit and external assessments per site.
• Evidence an auditor samples: Review reports, reviewer independence, actions on findings.
• Common pitfalls: A review carried out by the person who designed the controls.
• Templates: isms/independent-security-review-checklist (DOC-ISMS-048), isms/audit-findings-register (DOC-ISMS-086).

A.5.36 Compliance with security policies and standards

• Intent: Policies drift from practice over time. Routine checks by managers and control owners reveal where actual behaviour or configuration has departed from the rules, so the gap is corrected or formally accepted rather than tolerated silently.
• Typical implementation: Scheduled compliance checks by control owners and managers, technical compliance scans, an exception process with expiry dates.
• By tier: Small: quarterly checks on a short list. Medium: control self-assessment by owners. Large: continuous control monitoring with dashboards per site.
• Evidence an auditor samples: Check results, exceptions register, corrective actions.
• Common pitfalls: Permanent exceptions with no expiry or risk owner.
• Templates: isms/independent-security-review-checklist (DOC-ISMS-048), security/security-exception-request (DOC-ISMS-122), isms/control-evidence-matrix (DOC-ISMS-033).

A.5.37 Documented operating procedures

• Intent: Operations that depend on memory break when the expert is on holiday or has left. Written, current instructions for routine and recovery tasks let any competent operator perform them correctly and consistently.
• Typical implementation: Runbooks for backups, patching, user administration, monitoring and recovery, under version control, with owners and review dates.
• By tier: Small: runbooks in the engineering wiki. Medium: controlled procedures per service. Large: standard procedures per site with local variations recorded.
• Evidence an auditor samples: A sample of procedures, review dates, operators who can find and follow them.
• Common pitfalls: Procedures that exist only in one engineer's head, or documents that no longer match the system.
• Templates: isms/security-operating-procedure (DOC-ISMS-049).

11. Size tiers: how the theme scales

The controls are the same for every organisation. What changes with size is formality, tooling, the number of owners and how evidence is produced. The table shows how the three fictional settings used across this library approach the organizational theme. All rows are Example.

Practical advice per tier:

• Small. Combine roles, but write down who reviews whose work to keep segregation credible (A.5.3). Use the cloud provider's assurance reports for A.5.19 to A.5.23 and spend your effort on the parts you control.
• Medium. Name one owner per control and give each owner an evidence list from isms/control-evidence-matrix. The supplier and privacy controls usually need the most new work, especially where the organisation is a processor for customers.
• Large or multi-site. Decide which controls are run centrally and which locally, and record it. Reuse existing management system processes (document control, internal audit, continuity) rather than building parallel ISMS versions.

12. Self-check questions

Answer each question in your own words, then compare with the control entry above.

1. Why does ISO/IEC 27001 ask you to compare your selected controls with Annex A instead of implementing all of Annex A?
2. A small team cannot separate deployment and approval duties. What does A.5.3 expect instead, and what record would prove it?
3. What is the difference between leadership in clause 5.1 and management responsibilities in A.5.4?
4. Name three sources you would use for threat intelligence (A.5.7) and one action that intelligence could trigger.
5. Which four controls form the chain from knowing an asset to moving it safely, and in which order do they depend on each other?
6. What does an auditor look for when sampling access reviews under A.5.18?
7. A critical supplier will not sign your security addendum. What options do you have under A.5.20, and how do you record the decision?
8. What is the difference between A.5.29 and A.5.30?
9. Why should events judged "not an incident" still be recorded?
10. Who can carry out an independent review under A.5.35 in a 46-person company?

13. Records and evidence

This guide produces two kinds of records. First, records of learning, which support clause 7.2 competence evidence for ISMS roles. Second, local annotations that connect each control to your own documents, which help keep the SoA and evidence matrix consistent. The evidence that each control operates is tracked in isms/control-evidence-matrix (DOC-ISMS-033), not in this guide.

Study record:

14. References

Related templates: isms/isms-learning-path, isms/isms-glossary, isms/iso-27001-clauses-explained, isms/annex-a-people-physical-controls-guide, isms/annex-a-technological-controls-guide, isms/isms-self-test, compliance/statement-of-applicability, isms/control-evidence-matrix, isms/isms-policy-framework, compliance/risk-methodology.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 Annex A (controls A.5.1 to A.5.37) and with the control guidance in ISO/IEC 27002:2022. The intents, implementation notes, tier advice, pitfalls and questions are original text written for this library. No ISO or IEC control text, guidance, official titles, tables or definitions are reproduced; the labels next to control numbers are short descriptive labels, and you need the official standards, sold by ISO, IEC and national standards bodies, to implement the controls. Editions change: check the current edition of each standard on iso.org before you rely on this guide. This guide does not promise certification, which is decided by an accredited certification body. Template licence: MIT.