Annex A Control Implementation Library

Documents all 93 Annex A controls with implementation guidance, typical evidence and the artifact in the CISO Times catalogue that supports each.

Available soon

Format: Excel
Size: 85 KB
Length: 10 sheets
Version: 1.0
Updated: 28 Sep 2026

What's inside

Instructions
Control Library
Our Controls
Summary
Lists
Definitions
Framework References

Preview

The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.

Instructions

How to use this workbook

Step	What to do
1	Read the Control Library. Each row is one Annex A control: its number and title as ISO/IEC 27001:2022 gives them, its theme, and our guidance. Filter on Theme, Usually applies or Has a CISO Times document to see the controls you want.
2	Do not treat the library as a list to implement from top to bottom. Controls must be chosen from the risk assessment, not from the Annex A list; the Statement of Applicability must justify every inclusion and exclusion. (IS-03) Decide applicability in the Statement of Applicability Template, from your risk assessment and your scope.
3	For a control marked "Depends on scope", answer the deciding question for your organisation. If the answer is no, the control may be excluded in the Statement of Applicability, with a justification that follows from your risk assessment and scope. 81 of the 93 controls are marked "Almost always": an exclusion of one of these will be challenged.
4	Give each applicable control's owner its row. The implementation steps are a starting point for a small or mid-sized organisation; the evidence column is what an auditor will usually ask to sample, so make sure those records exist and are kept.
5	Use the CISO Times documents named against a control where they fit. Documents counted as "more planned" are coming and are not yet available.
6	On Our Controls, delete the EXAMPLE rows, then add a row for each control you are implementing: choose the control and its title, theme and applicability fill in. Record the owner, how you implement it (the policy, procedure or system) and where the evidence is kept. Clear every Check that does not say OK.
7	Review the library when you review the Statement of Applicability, and at least every 12 months. Record changes to your copy on the Changelog sheet.

Legend

Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.

EXAMPLE

Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval.

The library rows are the template's content, not examples: keep, add to or change the guidance as you tailor it, but keep control numbers and titles as they are. Only the rows on Our Controls marked EXAMPLE are to be deleted.

EXAMPLE rows on Our Controls: a software services company with 240 staff in two offices, an NIS2 important entity, using the documents in its policy register from the Security Policy Management pack, as at 2026-09-30.

Titles are ISO's; everything else in the library is our guidance and reproduces no text of the standard. Read the standard, and ISO/IEC 27002 for detailed control guidance, before you finalise an implementation.

Tailoring — small organisation: one person may own many controls, and that is fine. Keep the implementation to what your risks need; a one-page procedure the team follows beats a long one nobody reads. Where two duties cannot be separated, record the compensating check (A.5.3).

Tailoring — regulated entity: ISO/IEC 27001:2022 is the requirement for certification. Laws such as NIS2 or DORA may set obligations the library does not cover, such as reporting deadlines or specific testing; list them under A.5.31 and map them to controls. Certification is evidence for a regulator, not compliance with the law.

Tailoring — IT run by a service provider: many technical controls are carried out by the provider. The control is still yours: record the provider in the owner or implementation column, put the requirement in the contract (A.5.20) and check it through supplier monitoring (A.5.22) and the provider's own certificate or report, confirming that it covers the service you buy.

Control Library

All 93 Annex A controls: 37 organizational controls, 8 people controls, 14 physical controls, 34 technological controls. Numbers and titles are ISO's; the guidance is ours. Filter by theme with the arrow on the Theme header.

Control	Control title (ISO/IEC 27001:2022)	Theme	What it is for	Implementation steps for a small or mid-sized organisation	Typical evidence an auditor samples	Typical owner	Common mistakes	Usually applies	The question that decides	CISO Times documents that support it	Coming	Has a CISO Times document
A.5.1	Policies for information security	A.5 Organizational controls	Gives everyone one approved statement of what the organisation expects on security, so later rules and decisions have something to point back to.	Write a short top-level policy signed by top management, then a small set of topic policies for the areas your risks need. Publish them in one place staff can reach, get them acknowledged, and review each at least every 12 months or after a significant change.	The approved policy set with version and approval dates; acknowledgement records for a sample of staff; minutes or records of the last review.	ISMS manager, with top management approving the top policy	Forty policies bought as a toolkit that nobody has read; no evidence of acknowledgement; review dates passed without a recorded review.	Almost always		P04-A01 Security Policy Management Pack — Guide P04-A02 Policy Framework Standard P04-A03 Policy Lifecycle Operating Procedure P04-A04 Security Policy Document Template P04-A05 Security Policy Hierarchy & Document Map P04-A06 Policy Register & Review Schedule P04-A07 Policy Attestation & Acknowledgement Tracker P04-A08 Policy Coverage Gap Assessment P04-A10 Policy Health & Attestation Reporting Workbook	3 more planned	Yes
A.5.2	Information security roles and responsibilities	A.5 Organizational controls	Makes sure every security task has someone who knows it is theirs, so nothing falls between teams.	List the security activities the ISMS and your controls need, and assign each to a role, not a name. Record it in a responsibility matrix, put it in job descriptions where it matters, and tell the people concerned.	A responsibility matrix or role descriptions; a sample of named role holders who can explain their duties; appointment records for the ISMS manager.	ISMS manager, approved by top management	Everything assigned to 'IT'; roles written down but never communicated; a matrix that still names people who have left.	Almost always		P02-A09 Exception & SoD Responsibility Matrix P04-A09 Policy Development & Approval Responsibility Matrix	5 more planned	Yes
A.5.3	Segregation of duties	A.5 Organizational controls	Stops one person from being able to both do something wrong and hide it, which is where most fraud and many serious errors come from.	Identify the duty combinations that matter (for example requesting and approving access, or developing and deploying code) and split them between people. Where the team is too small to split, add a check by someone else after the event and record it as an approved exception.	A segregation of duties matrix; access listings showing the conflicting rights are not held together; records of the compensating reviews.	ISMS manager, with each process owner	Assuming a small team cannot comply; compensating controls that exist on paper but are never performed; administrators approving their own changes.	Almost always		P02-A01 Security Exception, Waiver & SoD Toolkit — Guide P02-A07 Segregation of Duties Conflict Matrix P02-A08 SoD Conflict Review & Compensating Control Procedure P02-A09 Exception & SoD Responsibility Matrix	1 more planned	Yes
A.5.4	Management responsibilities	A.5 Organizational controls	Turns security from a document into something managers actually require of their teams.	Make following the policies part of every manager's responsibilities and include it in their objectives. Give managers what they need to check their teams: training completion, access reviews, incidents. Raise non-compliance through the normal management line.	Management communications on security; managers' objectives or appraisals mentioning it; evidence managers act on training or access review results.	Top management	Security left entirely to the security team; managers who have never seen their team's training or access figures.	Almost always		None yet	1 more planned	No
A.5.5	Contact with authorities	A.5 Organizational controls	Means you know who to call, and are ready to call them, when an incident or a legal duty requires it.	List the authorities you may need — regulator, data protection authority, national cyber-security authority or CSIRT, police — with contact routes and who may contact them. Link the list to your incident and breach notification procedures and check it every 12 months.	The contact list with its review date; the incident procedure referring to it; records of any notifications made.	ISMS manager, with Legal or the Data Protection Officer	A list with out-of-date numbers; nobody authorised to make the call out of hours; notification deadlines not written into the incident procedure.	Almost always		None yet	8 more planned	No
A.5.6	Contact with special interest groups	A.5 Organizational controls	Keeps your security people learning from peers and specialists, so you hear about threats and good practice early.	Join one or two relevant groups — an industry information-sharing group, a professional body, a vendor security forum — and record them. Decide who attends and how useful information is passed on to the team.	The list of memberships; examples of information received and acted on, such as an advisory that led to a patch.	ISMS manager	Memberships that exist only on paper; nothing to show that information from the groups was ever used.	Almost always		None yet		No
A.5.7	Threat intelligence	A.5 Organizational controls	Gives you advance warning of the threats most likely to reach you, so defences are tuned to real attacks rather than guesses.	Pick a few sources that fit your size — national cyber-security authority alerts, vendor advisories, your managed security provider's reports. Assign someone to review them on a set cycle (for example weekly), decide what is relevant and feed it into vulnerability management, detection rules and the risk assessment.	The list of sources; a log or tickets showing intelligence reviewed and the actions taken; risk assessment updates that cite threat information.	ISMS manager or security operations lead	Subscribing to many feeds and reading none; no record of what was done with the information; treating a threat feed product as the whole control.	Almost always		P05-A02 Risk Assessment Methodology & Scoring Model	1 more planned	Yes
A.5.8	Information security in project management	A.5 Organizational controls	Catches security needs at the start of a project, when they are cheap to meet, rather than after go-live.	Add a short security checkpoint to your project method: a risk question set at initiation and a sign-off before go-live. Keep it proportionate — one page for small projects — and involve the ISMS manager for projects that change systems, data or suppliers.	The project method or checklist showing the security step; completed checklists or risk notes for a sample of recent projects.	Project or programme managers, with the ISMS manager	A checkpoint only for IT projects when business projects also change data and suppliers; sign-off after go-live.	Almost always		None yet	1 more planned	No
A.5.9	Inventory of information and other associated assets	A.5 Organizational controls	You cannot protect what you do not know you have; an inventory is the base for ownership, classification and every technical control.	Build an inventory of information assets and the systems, services and devices that hold them, each with an owner. Pull what you can automatically (device management, cloud accounts, software licences) and reconcile it at least every quarter.	The inventory with owners; a sample of assets traced from the inventory to reality and back; evidence of the last reconciliation.	Head of IT, with information owners	A spreadsheet of laptops only, with no information assets or cloud services; owners who do not know they are owners; no reconciliation since it was built.	Almost always		P01-A05 Scan Coverage & Asset Scope Register P07-A04 Access Review Scope & System Inventory	6 more planned	Yes
A.5.10	Acceptable use of information and other associated assets	A.5 Organizational controls	Tells people plainly what they may and may not do with the organisation's information and equipment, so misuse is clear and can be acted on.	Write a short acceptable use policy covering email, internet, devices, cloud services and personal use. Get it acknowledged at joining and once a year, and align it with your classification and handling rules.	The approved policy; acknowledgement records for a sample of staff and contractors.	Head of IT, with HR	A policy only employees sign, not contractors; rules nobody can follow, such as banning all personal use.	Almost always		None yet	2 more planned	No
A.5.11	Return of assets	A.5 Organizational controls	Makes sure devices, data and access cards come back when someone leaves or a contract ends, so information does not leave with them.	Put asset return on the leaver checklist, driven by the inventory of what each person holds. Cover information on personal devices and supplier-held assets too, and have HR or the line manager confirm return before the final day.	Leaver checklists for a sample of leavers matched to the asset inventory; records for any unreturned assets and what was done.	HR, with the Head of IT	Laptops returned but data on personal phones forgotten; no record of what the leaver held to check against.	Almost always		None yet		No
A.5.12	Classification of information	A.5 Organizational controls	Lets people see at a glance how carefully a piece of information must be handled, so protection matches value.	Adopt a simple scheme of three or four levels (for example Public, Internal, Confidential, Restricted) with plain examples of each. Make information owners responsible for classifying, and link each level to handling rules.	The classification scheme; the inventory showing classifications; staff able to explain the levels.	ISMS manager, with information owners	Too many levels; a scheme that exists but is never applied; no link between level and handling rules.	Almost always		None yet	6 more planned	No
A.5.13	Labelling of information	A.5 Organizational controls	Makes a document's classification visible to whoever handles it, so the right rules are followed without guesswork.	Decide how each level is marked: headers and footers in documents, subject tags in email, labels in your collaboration tools, physical labels for media. Automate with default labels where your tools allow, and state what needs no label (for example Internal by default).	The labelling procedure; a sample of documents and emails showing labels; tool settings for default labels.	ISMS manager	Requiring every item to be labelled by hand, so nobody does; labels that do not match the scheme.	Almost always		None yet	3 more planned	No
A.5.14	Information transfer	A.5 Organizational controls	Protects information while it moves — by email, file transfer, courier or conversation — which is when it is often most exposed.	Set rules for each transfer method by classification: approved tools, encryption, who may send what to whom. Put transfer terms into agreements with parties you exchange information with regularly.	The transfer rules; tool settings (for example email encryption, sharing restrictions); agreements with regular exchange partners.	Head of IT	Rules for email only, ignoring file-sharing links and messaging apps; external sharing left open by default.	Almost always		None yet	6 more planned	No
A.5.15	Access control	A.5 Organizational controls	Sets the principles for who may reach which information and systems, so access decisions are consistent instead of ad hoc.	Write an access control policy based on need-to-know and least privilege, covering request, approval, review and removal. Define standard role-based access for common jobs, so most requests are routine.	The approved access control policy; role definitions; a sample of access grants traced to approvals under the policy.	Head of IT	A policy that says 'least privilege' but no roles defined; approval by the person who grants the access.	Almost always		P07-A02 Access Review Methodology	3 more planned	Yes
A.5.16	Identity management	A.5 Organizational controls	Ensures every account belongs to a known person or purpose, so actions can be traced and orphan accounts do not linger.	Create identities only from an authorised trigger (HR record, contractor approval), one per person, in a central directory. Keep shared and service accounts to a minimum, each with a named owner, and disable identities promptly when the trigger ends.	Directory listings compared with HR records; the register of shared and service accounts with owners; joiner and leaver records.	Head of IT	Accounts created from an email request; shared accounts with no owner; test accounts left active.	Almost always		None yet	3 more planned	No
A.5.17	Authentication information	A.5 Organizational controls	Protects passwords, keys and tokens, because stolen credentials are the most common way in.	Issue initial credentials securely and force a change at first use. Set password rules in line with current guidance (length over complexity, check against breached lists), provide a password manager, and tell users how to report a credential they think is exposed.	Password and authentication settings in the directory; the password manager deployment; the user guidance on credentials.	Head of IT	Forced 30-day password changes that push people to weak patterns; default vendor passwords on devices; credentials shared in chat.	Almost always		None yet		No
A.5.18	Access rights	A.5 Organizational controls	Keeps access matched to what people need today, through approval at the start, changes when roles change, and regular review.	Run joiner, mover and leaver steps from HR triggers, with approval by the line manager or system owner. Review privileged access every 3 months, systems supporting critical services every 6 months and the rest every 12 months (the cycle the User Access Review pack uses), and remove what is no longer needed.	Approval records for a sample of grants; leaver removals with dates; completed access reviews with the changes they led to.	System owners, with the Head of IT	Reviews that rubber-stamp everything; movers keeping old access; leaver accounts disabled days or weeks late.	Almost always		P07-A01 User Access Review Pack — Guide P07-A02 Access Review Methodology P07-A03 Access Review Campaign Operating Procedure P07-A04 Access Review Scope & System Inventory P07-A05 Reviewer Instruction Pack & Campaign Communications P07-A06 Access Review Campaign Workbook P07-A07 Access Review Findings & Revocation Tracker P07-A08 Access Review Evidence & Audit File Checklist P07-A09 Access Review Outcome Report Template	6 more planned	Yes
A.5.19	Information security in supplier relationships	A.5 Organizational controls	Manages the security risk that comes with every supplier who touches your information or services.	Keep a supplier list tiered by the risk each one brings. Assess the higher tiers before contracting and on a cycle, and set the security requirements each tier must meet.	The tiered supplier register; completed assessments for a sample of higher-tier suppliers; the supplier security policy.	Procurement, with the ISMS manager	Assessing only new suppliers; treating a certificate as proof without checking that it covers the service you buy.	Almost always		P06-A01 Third-Party Security Risk Pack — Guide P06-A02 Third-Party Security Policy P06-A03 Supplier Security Assessment Procedure P06-A04 Supplier Criticality & Tiering Model P06-A05 Tiered Supplier Security Questionnaire P06-A06 Supplier Due Diligence Evidence Checklist P06-A08 Supplier Security Risk Register P06-A09 Supplier Security Review Report Template	2 more planned	Yes
A.5.20	Addressing information security within supplier agreements	A.5 Organizational controls	Makes a supplier's security obligations enforceable, because what is not in the contract usually cannot be required later.	Keep standard security clauses by supplier tier: confidentiality, incident notification times, audit or evidence rights, sub-contractor rules, data return and deletion at exit. Check each new or renewed contract against them before signature.	The clause set; a sample of contracts with higher-tier suppliers showing the clauses; records of deviations accepted.	Procurement or Legal, with the ISMS manager	Accepting the supplier's standard terms without reading them; no incident notification time; no right to evidence.	Almost always		P06-A02 Third-Party Security Policy P06-A07 Supplier Contract Security Clause Library	2 more planned	Yes
A.5.21	Managing information security in the ICT supply chain	A.5 Organizational controls	Extends supplier security to the suppliers behind your suppliers, where much of today's software and cloud risk sits.	Ask critical technology suppliers how they manage their own suppliers and components, and require notice of significant sub-contractor changes. For software you buy or build on, ask for vulnerability handling commitments and, where it matters, a list of components.	Questionnaire answers on supply chain practice; contract clauses on sub-contractors; supplier notices of changes.	Procurement, with the ISMS manager	Stopping at the first-tier supplier; no idea which cloud or software providers your critical suppliers rely on.	Almost always		P06-A03 Supplier Security Assessment Procedure P06-A05 Tiered Supplier Security Questionnaire		Yes
A.5.22	Monitoring, review and change management of supplier services	A.5 Organizational controls	Checks that suppliers keep doing what they promised, and catches changes that alter the risk.	Reassess each supplier on a cycle set by its tier (for example every 12 months for the highest). Track their findings to closure, review their service reports and certificates as they renew, and treat a major change or incident at the supplier as a trigger to reassess.	Reassessment dates against the tier cycle; findings tracked to closure; renewed certificates and reports on file.	Supplier business owners, with Procurement and the ISMS manager	An assessment at onboarding and never again; expired certificates nobody noticed; findings with no follow-up.	Almost always		P06-A04 Supplier Criticality & Tiering Model P06-A06 Supplier Due Diligence Evidence Checklist P06-A08 Supplier Security Risk Register P06-A10 Third-Party Risk Dashboard	2 more planned	Yes
A.5.23	Information security for use of cloud services	A.5 Organizational controls	Deals with the particular risks of cloud services: shared responsibility, configuration errors and dependence on one provider.	Keep a list of the cloud services you use and who owns each. For each important one, record which security tasks are yours and which the provider's, check the provider's assurance reports, configure it to your baseline, and plan how you would leave.	The cloud service list; shared-responsibility notes for key services; configuration reviews; provider assurance reports; exit plans for critical services.	Head of IT or cloud platform lead	Assuming the provider secures everything; services bought on a card outside procurement; no exit plan for the platform the business runs on.	Almost always		None yet	3 more planned	No
A.5.24	Information security incident management planning and preparation	A.5 Organizational controls	Gets you ready before an incident happens, so the response is fast and orderly instead of improvised.	Write an incident management procedure with roles, severity levels, escalation and contact lists. Train the people involved and run at least one tabletop exercise every 12 months.	The procedure; the incident team roster; exercise records with lessons and actions.	ISMS manager	A procedure written but never exercised; nobody on call outside office hours; no link to legal notification duties.	Almost always		None yet	8 more planned	No
A.5.25	Assessment and decision on information security events	A.5 Organizational controls	Separates real incidents from noise quickly and consistently, so serious ones get full attention and trivial ones do not.	Define criteria for deciding whether an event is an incident and how severe it is. Record each assessment and who made it, and escalate by severity.	The classification criteria; a sample of logged events showing the decision and its timing.	Security operations lead or ISMS manager	Only 'major' incidents recorded, so trends are invisible; severity decided differently each time.	Almost always		None yet	3 more planned	No
A.5.26	Response to information security incidents	A.5 Organizational controls	Contains and resolves incidents in a way that limits damage and keeps the record needed afterwards.	Follow the procedure: contain, eradicate, recover, communicate. Keep a timeline in the incident record, notify customers, authorities or insurers where required, and close only when the cause is understood.	Incident records with timelines and actions; notifications made and their timing; closure approvals.	Incident manager for each incident, with the ISMS manager	Fixing the symptom without finding the cause; no record kept for smaller incidents; notification deadlines missed.	Almost always		None yet	14 more planned	No
A.5.27	Learning from information security incidents	A.5 Organizational controls	Makes each incident pay for itself by preventing the next one.	Hold a short blameless review after every significant incident and look at smaller ones as a group each quarter. Turn lessons into tracked actions and feed them into the risk assessment and training.	Post-incident review records; actions raised and closed; risk register or training changes that trace back to incidents.	ISMS manager	Reviews that assign blame; actions agreed and never tracked; the same incident type recurring.	Almost always		None yet	4 more planned	No
A.5.28	Collection of evidence	A.5 Organizational controls	Keeps evidence usable if an incident leads to disciplinary action, a claim or a prosecution.	Decide in advance how evidence is preserved: who collects it, how logs and disk images are copied and protected, how chain of custody is recorded. Where specialist forensics may be needed, arrange a retained provider.	The evidence handling procedure; chain-of-custody records from a past incident; the forensic provider arrangement.	ISMS manager, with Legal	Rebuilding a compromised machine before copying it; logs that roll over before anyone saves them.	Almost always		None yet	1 more planned	No
A.5.29	Information security during disruption	A.5 Organizational controls	Keeps security working when the organisation is running in crisis mode, when shortcuts are most tempting.	In continuity plans, say which security controls must keep operating during disruption and how (for example emergency access with logging, alternate secure communications). Test this when continuity plans are exercised.	Continuity plans with the security provisions; exercise records covering them.	Business continuity lead, with the ISMS manager	Continuity plans that bypass access controls entirely; emergency accounts never reviewed after use.	Almost always		None yet	5 more planned	No
A.5.30	ICT readiness for business continuity	A.5 Organizational controls	Makes sure the technology the business depends on can be restored within the time the business can survive without it.	Set recovery time and recovery point objectives from a business impact analysis. Design backups and redundancy to meet them, and test recovery of critical systems at least every 12 months against those objectives.	The business impact analysis with objectives; recovery test reports showing times achieved against targets.	Head of IT, with business owners	Recovery objectives nobody tested; backups that exist but have never been restored under time pressure.	Almost always		None yet	9 more planned	No
A.5.31	Legal, statutory, regulatory and contractual requirements	A.5 Organizational controls	Ensures you know which laws, regulations and contracts set security obligations for you, so none is missed.	Keep a register of legal, regulatory and contractual security requirements with an owner for each and how you meet it. Review it at least every 12 months and when a law or major contract changes.	The requirements register with owners and review dates; examples of requirements traced to controls.	Legal or compliance, with the ISMS manager	Listing laws without saying what they require of you; customer contract security schedules missing from the register.	Almost always		None yet	7 more planned	No
A.5.32	Intellectual property rights	A.5 Organizational controls	Avoids legal and financial exposure from using software, content or code you are not licensed to use, and protects your own.	Track software licences against installations and cloud subscriptions. Set rules on open-source licences for code you ship, and on copying third-party content.	Licence records reconciled with the inventory; the open-source policy and scan results where you develop software.	Head of IT, with Legal	Unlicensed copies on old devices; open-source components with licences incompatible with your product.	Almost always		None yet		No
A.5.33	Protection of records	A.5 Organizational controls	Keeps the records the organisation must keep — financial, contractual, personnel, legal — complete, unaltered and available for as long as required, and no longer.	Build a retention schedule listing record types, retention periods and legal basis. Store records where they cannot be silently altered, and delete them when the period ends.	The retention schedule; storage settings (retention locks, access); evidence of deletion at end of retention.	Legal or records owner, with the Head of IT	Keeping everything forever; retention periods nobody enforces; records editable by anyone.	Almost always		None yet		No
A.5.34	Privacy and protection of PII	A.5 Organizational controls	Aligns the ISMS with your privacy obligations, so personal data is protected as the law and your customers expect.	Identify where personal data is processed and the laws that apply. Link the privacy programme (records of processing, impact assessments, breach notification) to the ISMS risk assessment and controls, and name who is responsible.	Records of processing; privacy impact assessments; the breach notification procedure; the named privacy lead.	Data Protection Officer or privacy lead	Treating privacy as a separate world from security; personal data found in systems missing from the records of processing.	Almost always		None yet	11 more planned	No
A.5.35	Independent review of information security	A.5 Organizational controls	Gives management an independent view of whether security is working, from someone who did not build it.	Arrange independent reviews of the ISMS at planned intervals and after major change — an internal audit function, a contracted auditor or a peer from another department. Report results to top management and track the actions.	Review or audit reports; evidence of the reviewer's independence; actions tracked to closure.	Top management, with the ISMS manager	The ISMS manager reviewing their own work; reports that go nowhere.	Almost always		P08-A08 ISMS Internal Audit Programme & Procedure	3 more planned	Yes
A.5.36	Compliance with policies, rules and standards for information security	A.5 Organizational controls	Checks that policies are actually followed day to day, not just written.	Have managers and the ISMS manager check compliance on a schedule: configuration checks, access reviews, spot checks of procedures. Record results, fix non-compliance and handle justified deviations as approved exceptions.	Compliance check records; the exception register; actions taken on non-compliance.	ISMS manager, with managers	Waiting for the external audit to find non-compliance; deviations agreed informally with no record.	Almost always		P01-A02 Vulnerability & Exposure Management Standard P02-A01 Security Exception, Waiver & SoD Toolkit — Guide P02-A02 Security Exception & Waiver Standard P02-A03 Exception Lifecycle Operating Procedure P02-A04 Security Exception Request & Approval Form P02-A05 Exception Risk Scoring & Expiry Model P02-A06 Security Exception Register P02-A08 SoD Conflict Review & Compensating Control Procedure P02-A10 Exception Ageing & Expiry Dashboard P05-A08 Risk Acceptance Form & Approval Record	8 more planned	Yes
A.5.37	Documented operating procedures	A.5 Organizational controls	Writes down how important operational tasks are done, so they are done the same way by whoever is on duty.	Identify the operational tasks where a mistake would hurt — backups, deployments, user administration, incident handling. Document them as short procedures kept where the people doing the work find them, and review them when systems change.	The procedures with owners and review dates; staff following them when observed; procedures matching current systems.	Head of IT and process owners	Procedures describing systems retired years ago; everything documented in one engineer's head.	Almost always		P04-A03 Policy Lifecycle Operating Procedure		Yes
A.6.1	Screening	A.6 People controls	Reduces the chance of trusting someone whose background makes them unsuitable for the access they will have.	Set proportionate checks by role, within the law where people work: identity and right to work for all, references and qualifications for most, deeper checks for privileged or finance roles. Apply the same to contractors, and record completion before access starts.	The screening standard by role; completion records for a sample of recent joiners, including contractors.	HR Director	Checks done after access is already granted; contractors not screened; checks that break local employment law.	Almost always		None yet		No
A.6.2	Terms and conditions of employment	A.6 People controls	Makes security responsibilities part of the deal everyone signs, so they can be enforced.	Include confidentiality and security responsibilities in employment contracts and contractor agreements, referring to the policies. Make sure obligations that continue after leaving are stated.	Contract templates with the clauses; signed contracts for a sample of staff and contractors.	HR Director, with Legal	Old contract templates without security terms still in use; contractors engaged on the agency's paperwork alone.	Almost always		None yet	1 more planned	No
A.6.3	Information security awareness, education and training	A.6 People controls	Makes people the first line of defence rather than the easiest way in.	Give everyone security awareness training at joining and at least every 12 months, with extra training for roles with higher risk (administrators, developers, finance). Use short, regular reminders and phishing exercises, and track completion.	The training plan; completion records; phishing exercise results and follow-up.	ISMS manager, with HR	One annual video and nothing else; no role-based training; completion never chased.	Almost always		P04-A07 Policy Attestation & Acknowledgement Tracker P07-A05 Reviewer Instruction Pack & Campaign Communications	11 more planned	Yes
A.6.4	Disciplinary process	A.6 People controls	Makes clear that serious or deliberate security breaches have consequences, applied fairly.	Make sure the HR disciplinary procedure covers security policy breaches and is referenced from the policies. Apply it consistently, taking intent and impact into account.	The disciplinary procedure referring to security; policies stating consequences.	HR Director	A procedure that exists but is never linked to security; applied only to junior staff.	Almost always		None yet		No
A.6.5	Responsibilities after termination or change of employment	A.6 People controls	Makes sure security obligations that outlast employment are known and enforced, and access ends when the role does.	At exit or role change, remind the person of continuing confidentiality duties and record it. Remove or adjust access on the last day of the role, and cover contractors and suppliers' staff the same way.	Leaver and mover checklists with the reminder; access removal dates matched to HR dates.	HR Director, with the Head of IT	No exit reminder; movers keeping previous access; supplier staff leaving without anyone telling you.	Almost always		None yet	2 more planned	No
A.6.6	Confidentiality or non-disclosure agreements	A.6 People controls	Protects confidential information shared with people and organisations outside your direct control.	Keep standard confidentiality agreements for staff, contractors and third parties, reviewed by Legal. Record who has signed and review the templates when needs change.	The agreement templates; signed agreements for a sample of third parties with access to confidential information.	Legal	Agreements with no end date or return clause; information shared before the agreement is signed.	Almost always		None yet		No
A.6.7	Remote working	A.6 People controls	Keeps information safe when people work from home, while travelling or from other places outside the office.	Set rules for remote work: managed devices, secure connection, screen privacy, where confidential work may be done. Enforce what you can technically (device encryption, conditional access) and cover the rest in the remote working rules.	The remote working rules; device management and conditional access settings; acknowledgements.	Head of IT	Rules that assume a VPN no one uses any more; personal devices with no controls accessing company data.	Almost always		None yet		No
A.6.8	Information security event reporting	A.6 People controls	Gets suspected incidents reported quickly, because early reports shrink damage.	Give staff one simple way to report a suspected incident or weakness (a mailbox, a button, a phone number) and publicise it. Make reporting blame-free, and acknowledge each report.	The reporting route; reports received and how they were handled; staff able to say how they would report.	ISMS manager	Several routes nobody watches; people punished for reporting their own mistakes, so they stop reporting.	Almost always		None yet	2 more planned	No
A.7.1	Physical security perimeters	A.7 Physical controls	Marks out where your information and equipment are, so physical protection has a clear boundary.	Identify the premises and areas in scope, including offices, shared buildings and any equipment rooms. Define the boundary for each and the protection it needs, and for premises you rely on but do not run (a landlord or cloud provider) record whose control applies.	Site list with defined perimeters; site walk-through; landlord or provider assurance for areas not under your control.	Facilities Manager	Ignoring shared building areas; no account of cloud provider premises that hold your data.	Almost always		None yet		No
A.7.2	Physical entry	A.7 Physical controls	Lets only authorised people into your premises and more sensitive areas, and shows who went in.	Control entry with badges or keys, a visitor process (sign-in, escort, badge) and deliveries kept away from sensitive areas. Remove access when people leave and review access lists at least every 6 months.	Access control system reports; visitor logs; badge removals matched to leavers.	Facilities Manager	Tailgating accepted as normal; badges of leavers still active; visitors left unescorted.	Almost always		None yet		No
A.7.3	Securing offices, rooms and facilities	A.7 Physical controls	Protects offices and rooms where sensitive information is handled from casual access and overlooking.	Decide which rooms need extra protection (HR, finance, equipment rooms) and lock them. Avoid signs that advertise what is inside, and keep screens and whiteboards out of view from outside.	Site walk-through; lock and key records; room access lists.	Facilities Manager	Equipment rooms used as storerooms and left open; confidential whiteboards visible from the corridor.	Almost always		None yet		No
A.7.4	Physical security monitoring	A.7 Physical controls	Detects unauthorised physical access so you can respond, rather than finding out afterwards.	Use monitoring proportionate to the site: intruder alarm, CCTV at entrances, access system alerts. Check it works, decide who responds, and keep footage for a set period (for example 30 calendar days) within privacy law.	Alarm and CCTV maintenance records; response arrangements; retention settings.	Facilities Manager	Cameras nobody reviews and that were broken for months; no one named to respond to an alarm.	Depends on scope	Do you have premises of your own in scope that hold sensitive equipment or information worth watching?	None yet		No
A.7.5	Protecting against physical and environmental threats	A.7 Physical controls	Protects premises and equipment from fire, flood, power surges and similar hazards.	Assess the environmental threats at each site. Put in fire detection and suppression, water detection where equipment sits, and surge protection, relying on the landlord where they provide it and confirming they do.	Site risk assessment; fire system test records; landlord confirmations.	Facilities Manager	Network equipment under a water pipe; assuming the landlord tests systems without asking for proof.	Almost always		None yet		No
A.7.6	Working in secure areas	A.7 Physical controls	Sets rules for behaviour inside the most sensitive areas, so protection is not undone by the people allowed in.	For each secure area, set simple rules: who may work alone, whether photos or personal devices are allowed, supervision of third parties. Post the rules at the entrance and brief those with access.	The secure area rules; access lists; supervision records for third-party work.	Facilities Manager	Defining secure areas but giving everyone access; contractors working unsupervised in equipment rooms.	Depends on scope	Have you defined secure areas — equipment rooms, secure offices — within scope, or do such areas exist only at your providers?	None yet		No
A.7.7	Clear desk and clear screen	A.7 Physical controls	Stops information being read or taken from unattended desks and screens.	Set a clear desk and clear screen rule: lock screens when away (enforce automatic locking after a few minutes), clear confidential paper at the end of the day, collect printouts promptly. Provide lockable storage and secure print release.	Screen lock settings; clear desk walk-round results; secure printing configuration.	ISMS manager, with Facilities	A policy with no checks; screen lock set to 60 minutes or not at all.	Almost always		None yet		No
A.7.8	Equipment siting and protection	A.7 Physical controls	Places and protects equipment so it is not damaged, overlooked or tampered with.	Site equipment in suitable locations: network gear in locked cabinets, screens not overlooked, printers for sensitive output in controlled areas. Protect against heat, dust and liquids where equipment is critical.	Site walk-through; equipment locations recorded in the inventory.	Head of IT, with Facilities	Network switches in open corridors; a server under someone's desk.	Depends on scope	Do you keep servers, network equipment or other shared equipment on your own premises?	None yet		No
A.7.9	Security of assets off-premises	A.7 Physical controls	Protects laptops, phones and other equipment when they leave the building, where most loss and theft happens.	Encrypt all portable devices and manage them centrally so they can be locked or wiped. Set rules for travel and home use, and require quick reporting of loss or theft.	Device management reports showing encryption and management status; loss reports and remote wipes.	Head of IT	Unencrypted older laptops; loss reported days later; no way to wipe phones with company email.	Almost always		None yet		No
A.7.10	Storage media	A.7 Physical controls	Controls removable media and storage so information is not lost, copied without authority or left on discarded disks.	Limit removable media to where the business needs it, block or encrypt USB storage by policy, and track media holding confidential information. Dispose of media securely.	Device control settings; the media register where used; disposal certificates.	Head of IT	USB storage open to all with no encryption; old backup tapes in a cupboard.	Almost always		None yet		No
A.7.11	Supporting utilities	A.7 Physical controls	Keeps equipment running through failures of power, cooling or communications that it depends on.	Identify critical equipment on your premises and give it what it needs: uninterruptible power, generator where justified, cooling, a second internet link. Test and maintain these on the supplier's schedule; for hosted services, rely on the provider's assurance.	UPS and generator test records; maintenance contracts; provider assurance reports for hosted equipment.	Facilities Manager, with the Head of IT	UPS batteries never replaced; one internet line for a site that cannot work without it.	Depends on scope	Do you run equipment on your own premises that must keep working through a power or cooling failure?	None yet		No
A.7.12	Cabling security	A.7 Physical controls	Protects the cables that carry power and data from interception, interference and damage.	Keep network cabling within controlled spaces or conduits, label it, and secure patch panels. Separate power from data cabling where interference matters, and rely on landlord or provider assurance for cabling outside your control.	Site walk-through of cabinets and cable routes; cabling records.	Facilities Manager, with the Head of IT	Open patch panels in public areas; no record of which cables carry what.	Depends on scope	Do you own or control power or network cabling that carries in-scope information?	None yet		No
A.7.13	Equipment maintenance	A.7 Physical controls	Keeps equipment working and prevents maintenance from becoming a route to your information.	Maintain equipment to the manufacturer's schedule, using authorised people. Supervise third-party maintenance, and remove or protect information before equipment goes off-site for repair.	Maintenance logs and contracts; records of equipment sent for repair and how data was protected.	Head of IT, with Facilities	Laptops sent for repair with unencrypted drives; maintenance engineers left unsupervised.	Almost always		None yet		No
A.7.14	Secure disposal or re-use of equipment	A.7 Physical controls	Makes sure no information survives on equipment you dispose of or reuse.	Wipe or destroy storage before disposal or reuse, using a method suited to the media. Use a certified disposal company for volume, get certificates, and update the inventory.	Disposal certificates matched to the inventory; wipe logs for reused devices.	Head of IT	Devices given to staff or charities without a wipe; certificates that do not list serial numbers.	Almost always		None yet	1 more planned	No
A.8.1	User endpoint devices	A.8 Technological controls	Keeps laptops, phones and tablets that reach company information in a known, protected state.	Enrol every device that accesses company data in device management. Enforce encryption, screen lock, updates and malware protection, and block access from devices that do not comply; set rules for personal devices.	Device management compliance reports; conditional access rules; the personal device rules.	Head of IT	Company email on unmanaged personal phones; devices out of compliance for months with no action.	Almost always		None yet	1 more planned	No
A.8.2	Privileged access rights	A.8 Technological controls	Limits and watches the powerful accounts that can change systems or reach everything, because they are attackers' first target.	Give administrator rights only to named people who need them, on separate admin accounts with multi-factor authentication. Grant them for a limited time where you can, log their use, and review privileged access at least every 3 months.	The list of privileged accounts with owners and approvals; review records; admin activity logs.	Head of IT	Daily work done on admin accounts; everyone in IT a global administrator; shared admin passwords.	Almost always		None yet	10 more planned	No
A.8.3	Information access restriction	A.8 Technological controls	Makes systems enforce who can see and change which information, so the access policy is not just a promise.	Configure applications and file stores to grant access by role and restrict by default. Remove open 'everyone' permissions, restrict sharing outside the organisation, and check permissions on important data stores.	Permission reports for key systems and shares; sharing settings; results of permission reviews.	System owners, with the Head of IT	File shares open to all staff; public sharing links on confidential documents.	Almost always		None yet		No
A.8.4	Access to source code	A.8 Technological controls	Protects source code from unauthorised change or theft, since it is valuable and a route to attack your products.	Keep code in a managed repository with access by role, multi-factor authentication and branch protection. Log access, remove leavers promptly, and keep secrets out of code.	Repository access lists and settings; branch protection rules; secret scanning results.	Head of Engineering	All staff with write access to every repository; credentials committed to code.	Depends on scope	Do you hold source code — your own, or a supplier's under escrow or licence?	None yet		No
A.8.5	Secure authentication	A.8 Technological controls	Makes sure people and systems are who they claim to be before they get in.	Use single sign-on and multi-factor authentication for email, remote access, cloud consoles and every system holding confidential information. Prefer phishing-resistant methods for administrators, and limit failed login attempts.	Identity provider settings; the list of systems behind single sign-on and multi-factor authentication; exceptions and their approvals.	Head of IT	Multi-factor authentication on email but not on the cloud console; legacy protocols left open that bypass it.	Almost always		None yet	1 more planned	No
A.8.6	Capacity management	A.8 Technological controls	Prevents outages and slowdowns caused by running out of capacity — storage, compute, bandwidth or people.	Monitor the capacity of critical systems, set alerts well before limits, and review trends at least every quarter to plan ahead. For cloud services, set quotas and budget alerts.	Monitoring dashboards and alert thresholds; capacity review records.	Head of IT or platform lead	Finding out a disk is full when the service stops; cloud auto-scaling with no cost or limit alerts.	Almost always		None yet		No
A.8.7	Protection against malware	A.8 Technological controls	Stops malicious software from getting in and spreading, and detects it quickly if it does.	Run endpoint protection on all devices and servers with central alerting, filter email attachments and links, and restrict who can install software. Combine this with user awareness and prompt patching.	Endpoint protection coverage and status reports; email filtering settings; alerts and how they were handled.	Head of IT	Servers without protection 'for performance'; alerts nobody reads; coverage below the device count.	Almost always		None yet	2 more planned	No
A.8.8	Management of technical vulnerabilities	A.8 Technological controls	Finds and fixes weaknesses in your systems before attackers use them.	Scan all in-scope systems on a schedule, subscribe to vendor advisories, and fix by severity within set deadlines (for example critical within 14 calendar days). Track exceptions and report coverage and overdue items to management.	Scan coverage against the inventory; remediation times against deadlines; the exception register.	Head of IT, with the ISMS manager	Scanning only part of the estate; deadlines with no tracking; cloud and container images missed.	Almost always		P01-A01 Vulnerability Management Operating Pack — Guide P01-A02 Vulnerability & Exposure Management Standard P01-A03 Vulnerability Triage & Remediation Operating Procedure P01-A04 Vulnerability Risk Rating & SLA Model P01-A05 Scan Coverage & Asset Scope Register P01-A06 Vulnerability Remediation Tracker P01-A07 Vulnerability Scanner Configuration Review Checklist P01-A08 Vulnerability Management Metrics Workbook P01-A09 Vulnerability Programme Maturity Self-Assessment	9 more planned	Yes
A.8.9	Configuration management	A.8 Technological controls	Keeps systems in a known secure state, so misconfiguration — a leading cause of breaches — is prevented and caught.	Define secure baseline settings for each system type, starting from a published benchmark. Apply them through automation where you can, detect drift, and control changes to the baseline.	The baselines; compliance reports against them; drift alerts and fixes.	Head of IT or platform lead	A baseline written once and never checked; cloud settings changed by hand with no record.	Almost always		P01-A07 Vulnerability Scanner Configuration Review Checklist	9 more planned	Yes
A.8.10	Information deletion	A.8 Technological controls	Removes information once it is no longer needed, reducing what can be lost and meeting legal duties.	Apply the retention schedule in your systems with automatic deletion where possible. Handle deletion requests and supplier deletion at contract end, and keep proof of deletion where it matters.	Retention settings in systems; deletion records; supplier deletion confirmations.	Information owners, with the Head of IT	Nothing ever deleted; deletion from live systems but not from backups or supplier copies, with no plan for either.	Almost always		None yet	1 more planned	No
A.8.11	Data masking	A.8 Technological controls	Limits exposure of sensitive data by hiding it wherever the full value is not needed.	Identify where sensitive data is used beyond its main purpose (test environments, reports, support tools). Mask, pseudonymise or truncate it there, and restrict who can see unmasked data.	Masking rules and where they apply; a sample of test or reporting data showing masking.	Head of Engineering or data owner	Copying production databases into test as they are; masking that can be easily reversed.	Depends on scope	Do you use personal or confidential data where a masked or pseudonymised copy would do — in testing, analytics or support?	None yet		No
A.8.12	Data leakage prevention	A.8 Technological controls	Detects and blocks information leaving the organisation without authority.	Start with the channels that matter: email, cloud sharing, removable media, uploads to personal services. Apply restrictions and alerts in the tools you already have, then add dedicated tooling if the risk justifies it.	Sharing and upload restrictions; data loss prevention rules and alerts; how alerts were handled.	ISMS manager, with the Head of IT	Buying a tool and leaving it in monitor mode for ever; rules so noisy that alerts are ignored.	Almost always		None yet		No
A.8.13	Information backup	A.8 Technological controls	Means you can get information and systems back after deletion, corruption, ransomware or failure.	Back up in line with recovery objectives, keep at least one copy offline or immutable, and include cloud and software-as-a-service data. Monitor backup jobs and test restores on a schedule, at least every quarter for critical systems.	Backup schedules and job reports; restore test records; immutable or offline copy settings.	IT Operations Manager	Backups never test-restored; software-as-a-service data assumed to be backed up by the provider; backups reachable with the same admin account as production.	Almost always		None yet	9 more planned	No
A.8.14	Redundancy of information processing facilities	A.8 Technological controls	Keeps critical services available when a component fails, by having more than one of what matters.	From the availability requirements, identify single points of failure in critical services. Add redundancy where justified — multiple availability zones, a second connection, failover — and test that failover works.	Architecture showing redundancy; failover test records.	Head of IT or platform lead	Redundancy designed but never tested; a single region or single connection for a service promised as always-on.	Almost always		None yet	1 more planned	No
A.8.15	Logging	A.8 Technological controls	Records what happens on your systems, so incidents can be detected, investigated and proven.	Decide which events to log (logins, admin actions, security alerts, access to sensitive data) and send logs to a central store that administrators cannot alter. Keep them for a set period (for example 12 months) and protect access to them.	Logging standard; central log configuration; retention settings; a sample of log entries for a test event.	Head of IT	Logs kept only on the system that produced them; retention too short to investigate; no logs from cloud services.	Almost always		None yet	1 more planned	No
A.8.16	Monitoring activities	A.8 Technological controls	Watches networks, systems and applications for unusual behaviour, so attacks are noticed while they can still be stopped.	Define what should raise an alert, based on your threats — impossible logins, admin changes, malware, large data movements. Route alerts to someone who acts on them, or to a managed detection service, and check coverage periodically.	Alert rules; alert handling records; the managed service contract and reports where used.	Security operations lead or Head of IT	Alerts going to an unread mailbox; monitoring only office hours; no alerts for cloud consoles.	Almost always		None yet		No
A.8.17	Clock synchronization	A.8 Technological controls	Keeps timestamps consistent across systems, so events can be put in order during an investigation.	Point all systems at the same reliable time sources, and check that cloud services and network devices use them too. Record the time zone used in logs.	Time source settings on a sample of systems; logs from different systems with matching timestamps.	Head of IT	Network devices drifting by minutes; logs in mixed time zones with none recorded.	Almost always		None yet		No
A.8.18	Use of privileged utility programs	A.8 Technological controls	Controls tools that can bypass normal security, so they are not used to get round your controls.	Identify tools that can override controls (system utilities, database admin tools, remote administration software). Restrict them to authorised administrators, log their use, and remove them where not needed.	The list of restricted utilities; installation and access restrictions; usage logs.	Head of IT	Remote administration tools installed everywhere and never inventoried.	Almost always		None yet		No
A.8.19	Installation of software on operational systems	A.8 Technological controls	Stops unapproved or harmful software from being installed on systems you depend on.	Restrict installation rights to administrators or a managed software catalogue. Approve new software through a simple request, and use application allow-listing on servers and critical systems where feasible.	Installation rights settings; the software catalogue or allow-list; requests and approvals.	Head of IT	All users local administrators; server software installed by hand with no change record.	Almost always		None yet	1 more planned	No
A.8.20	Networks security	A.8 Technological controls	Protects the networks that carry your information from misuse and attack.	Keep network diagrams current, manage network devices securely (admin access, updates, configuration backups), and filter traffic at boundaries. Apply the same thinking to cloud networks: security groups, private endpoints, no open management ports.	Network diagrams; firewall and security group rules with review records; device configuration standards.	Head of IT or network lead	Firewall rules nobody can explain; management interfaces reachable from the internet.	Almost always		None yet		No
A.8.21	Security of network services	A.8 Technological controls	Makes sure the network services you buy — internet, connectivity, DNS, managed networks — are secured to the level you need.	Identify your network service providers and the security features you depend on (encryption, availability, filtering). Put them into agreements and check the provider meets them.	Service agreements with security and service levels; provider reports or reviews.	Head of IT	No agreed service levels; DNS or domain registration held in a personal account.	Almost always		None yet		No
A.8.22	Segregation of networks	A.8 Technological controls	Divides networks so a problem in one part cannot spread freely to the rest.	Separate networks by trust and purpose: guest wireless apart from corporate, production apart from development, management interfaces on their own segment. Control and log traffic between segments.	Network design showing segments; rules between segments; tests showing guests cannot reach internal systems.	Head of IT or network lead	A flat office network where guests and printers sit with everything else; production reachable from any laptop.	Almost always		None yet		No
A.8.23	Web filtering	A.8 Technological controls	Reduces exposure to malicious and inappropriate websites, a common route for malware and phishing.	Filter web access by category and threat reputation, on and off the office network (through the endpoint or a cloud service). Block known malicious sites and decide which categories to block by policy.	Web filtering configuration and coverage; block reports.	Head of IT	Filtering only in the office, so remote workers are unprotected.	Almost always		None yet		No
A.8.24	Use of cryptography	A.8 Technological controls	Uses encryption correctly so information stays confidential and unaltered, and keys do not become the weak point.	Set rules for where encryption is required (devices, data in transit, sensitive data at rest, backups) and which algorithms are allowed. Manage keys and certificates: who holds them, where they are stored, when they expire and are rotated.	The cryptography standard; encryption settings on a sample of systems; the certificate and key inventory with expiry dates.	Head of IT or platform lead	Certificates expiring unnoticed; keys stored beside the data they protect; outdated protocols still enabled.	Almost always		None yet		No
A.8.25	Secure development life cycle	A.8 Technological controls	Builds security into how software is made, instead of testing it in at the end.	Define a secure development life cycle: security requirements at design, secure coding rules, code review, automated testing and controlled release. Keep it proportionate and embedded in the tools teams already use.	The secure development standard; pipeline configuration showing required steps; a sample of changes that followed it.	Head of Engineering	A standard nobody follows; security steps skipped under deadline pressure with no record.	Depends on scope	Do you develop or configure software yourself, including scripts, integrations and low-code applications?	None yet	2 more planned	No
A.8.26	Application security requirements	A.8 Technological controls	Makes sure applications you build or buy are specified with the security they need before work or purchase starts.	For each new application or major change, set security requirements from its data and risks: authentication, access control, logging, data protection. Include them in specifications, tenders and acceptance criteria.	Requirements documents or tender criteria showing security requirements; acceptance records checking them.	Business owner of the application, with the ISMS manager	Security requirements added after the contract is signed; one generic list used for everything.	Almost always		None yet	5 more planned	No
A.8.27	Secure system architecture and engineering principles	A.8 Technological controls	Designs systems so they are secure by construction — layered defences, least privilege, fail-safe defaults.	Write down a small set of security design principles and apply them to new systems and architecture changes. Review designs of significant systems against them before building.	The design principles; design review records for recent significant changes.	Head of Engineering or chief architect	Principles written but no design ever reviewed against them.	Almost always		None yet		No
A.8.28	Secure coding	A.8 Technological controls	Reduces the vulnerabilities developers introduce, which are cheaper to prevent than to fix.	Adopt secure coding guidance for your languages, train developers in it, and use automated code and dependency scanning in the pipeline. Require peer review before merge.	Secure coding guidance; training records; scanning results and how findings were handled; review enforcement settings.	Head of Engineering	Scanning tools whose findings nobody triages; vulnerable dependencies left for months.	Depends on scope	Do you write code yourself — products, internal tools, scripts or infrastructure as code?	None yet		No
A.8.29	Security testing in development and acceptance	A.8 Technological controls	Checks that security requirements are actually met before a system or change goes live.	Include security tests in development and acceptance: automated tests in the pipeline, and penetration testing for significant releases or at least every 12 months for exposed systems. Test acquired systems against their security requirements before acceptance.	Test plans and results; penetration test reports and remediation; acceptance sign-offs.	Head of Engineering, with the ISMS manager	Penetration test findings left open until the next test; acceptance with no security testing.	Almost always		None yet	2 more planned	No
A.8.30	Outsourced development	A.8 Technological controls	Keeps security standards in force when someone else writes your software.	Put your secure development requirements into contracts with development suppliers, including code ownership, testing and vulnerability fixing. Review their work (code review, test results) and monitor delivery.	Contracts with development suppliers; evidence of reviews and testing of delivered code.	Head of Engineering, with Procurement	Accepting delivered code without review; no right to see the supplier's testing.	Depends on scope	Do you pay anyone outside the organisation to develop or change software for you?	None yet		No
A.8.31	Separation of development, test and production environments	A.8 Technological controls	Stops development and testing from damaging live systems or exposing live data.	Keep development, test and production separate: different accounts or subscriptions, separate credentials, restricted production access. Move changes to production only through the controlled release process.	Environment design; access lists showing separation; release records.	Head of Engineering or platform lead	Developers with standing production admin rights; tests run against production.	Depends on scope	Do you develop, test or configure systems before they go live, in environments of your own?	None yet		No
A.8.32	Change management	A.8 Technological controls	Makes changes to systems deliberately — assessed, approved, tested and reversible — because unmanaged change causes many incidents.	Define a change process proportionate to risk: standard changes pre-approved, normal changes assessed and approved, emergency changes reviewed after the event. Record every change to production with its approval and test evidence.	The change procedure; a sample of change records traced to approvals and deployments; emergency change reviews.	Head of IT, with the Head of Engineering	Changes in production that have no record; emergency changes used as the normal route.	Almost always		None yet	3 more planned	No
A.8.33	Test information	A.8 Technological controls	Protects the data used in testing, which is often copied from live systems with weaker controls around it.	Use synthetic or masked data by default. Where live data is essential, get approval, protect the test environment to the same level, and delete the data afterwards.	Test data rules; approvals for any use of live data; deletion records.	Head of Engineering	Full production copies in test environments with wide access, never deleted.	Depends on scope	Do you test systems with data — and could that data include live or confidential information?	None yet		No
A.8.34	Protection of information systems during audit testing	A.8 Technological controls	Makes sure audits and technical tests do not disrupt live systems or expose information.	Agree the scope, timing and access for audits and technical tests in advance, with read-only access where possible. Monitor testers' activity and remove their access when the test ends.	Test and audit plans with agreed scope; access granted and removed; approval for any testing on live systems.	ISMS manager, with the Head of IT	Penetration testers given standing admin accounts that stay active after the test.	Almost always		None yet		No

Our Controls

One row per control you implement: owner, how, and where the evidence is. Yellow columns are yours; the rest calculate. Delete the 5 EXAMPLE rows first.

Example	Control	Control title (calc)	Theme (calc)	Usually applies (calc)	Our owner	How we implement it (policy, procedure or system)	Where the evidence is kept	Notes	Check (calc)
EXAMPLE	A.5.15	Access control	A.5 Organizational controls	Almost always	Head of IT	ACP-001 Access Control Policy v2.0 (approved 2026-01-20); standard roles set up as groups in the identity provider	Identity provider group reports; access request tickets in the IT service desk	Roles reviewed with each quarterly access review	OK
EXAMPLE	A.5.19	Information security in supplier relationships	A.5 Organizational controls	Almost always	Head of Procurement	SUP-001 Supplier Security Policy v1.0 (awaiting approval); supplier register kept by Procurement	Supplier register; assessments of the cloud platform provider and the payroll provider	Policy with the Executive Committee; not in force until approved	OK
EXAMPLE	A.6.5	Responsibilities after termination or change of employment	A.6 People controls	Almost always	HR Director	JML-PRC Joiner, Mover, Leaver Procedure v2.2 (approved 2025-02-03); leaver checklist in the HR system	Leaver checklists matched to account disable dates	Add the confidentiality reminder to the exit interview form	OK
EXAMPLE	A.8.8	Management of technical vulnerabilities	A.8 Technological controls	Almost always	Head of IT	VMS-001 Vulnerability & Exposure Management Standard v1.0 (approved 2026-09-10); weekly authenticated scans of the cloud platform	Scan coverage report against the asset inventory; remediation tracker	Container images added to the scan scope this quarter	OK
EXAMPLE	A.8.13	Information backup	A.8 Technological controls	Almost always	IT Operations Manager	BKP-001 Backup Standard v1.3 (approved 2025-08-15; review overdue since 2026-08-15); daily snapshots with an immutable copy in a second region	Backup job reports; quarterly restore test records	Standard past its review date: review before the Stage 1 audit	OK

Summary

Library summary

Calculated from the Control Library and Our Controls. The expected counts per theme are ISO/IEC 27001:2022's; a Check other than OK means a row has been removed or changed.

Controls per theme

Theme	Controls	Expected	Almost always	Depends on scope	With a CISO Times document	Only planned documents	No CISO Times document yet	Check
A.5 Organizational controls	37	37	37	0	14	18	5	OK
A.6 People controls	8	8	8	0	1	3	4	OK
A.7 Physical controls	14	14	9	5	0	1	13	OK
A.8 Technological controls	34	34	27	7	2	13	19	OK
All themes	93	93	81	12	17	35	41	OK

"With a CISO Times document" counts controls with at least one CISO Times document in draft or published; "Only planned documents" counts controls whose support is still coming.

Our Controls

Measure	Result	What it means
Controls listed	5	Distinct Annex A controls with a row on Our Controls.
Of those, marked "Almost always"	5	Out of 81 such controls in the library.
Rows with a check to resolve	0	Rows whose Check does not say OK.

EXAMPLE rows are counted until you delete them.

Lists

Theme	Applies	YesNo
A.5 Organizational controls	Almost always	Yes
A.6 People controls	Depends on scope	No

A.7 Physical controls

A.8 Technological controls

Definitions

Definitions

Term	Meaning in this workbook
Annex A	The list of 93 information security controls in ISO/IEC 27001:2022, grouped in four themes. Organisations compare the controls their risk treatment needs against it (clause 6.1.3); it is a reference, not a list every organisation must implement.
Control	The control's number in Annex A, such as A.5.15. It is the stable ID in this library, the Statement of Applicability and the other P08 documents.
Control title	The title ISO/IEC 27001:2022 gives the control. The control text itself is in the standard and is not reproduced here.
Theme	The Annex A theme the control belongs to: A.5 Organizational controls, A.6 People controls, A.7 Physical controls, A.8 Technological controls.
What it is for	Why an organisation uses the control: the harm it prevents or the outcome it gives. Our words, not the standard's.
Implementation steps	A practical way to put the control in place in a small or mid-sized organisation. A starting point, not the only way.
Typical evidence	The records an auditor usually asks to see or samples to test that the control operates. Make sure they exist and are kept.
Typical owner	The role that usually owns the control. The ISMS manager (e.g. Head of Information Security) co-ordinates; the owner runs it.
Almost always	The control applies to nearly every organisation. Excluding it needs a strong justification from your risk assessment and scope.
Depends on scope	Whether the control applies depends on what your organisation does and what is in scope. The deciding question says what to ask.
CISO Times documents	Documents in the CISO Times catalogue that support the control, shown when they are available in draft or published. Coming: how many more are planned and not yet available.
Statement of Applicability	The record of which Annex A controls you need, why, whether they are implemented, and why any are excluded (clause 6.1.3). See the Statement of Applicability Template.
Risk assessment	The process that identifies and evaluates information security risks (clause 6.1.2). Controls are chosen to treat the risks it finds (IS-03).
Scope	The boundaries of the information security management system: the organisation, locations, services and interfaces it covers (clause 4.3, IS-02).
EXAMPLE row	A worked example on Our Controls: a software services company with 240 staff in two offices, an NIS2 important entity, as at 2026-09-30. Delete before approval.
IS-nn	Rule numbers in the ISO 27001 Implementation Methodology & Project Plan.
(calc)	A column the workbook calculates. Do not type or paste over it.

Framework References

Framework references

These references indicate relevance only and do not reproduce the text of any standard.

Framework	Reference	Supported by
ISO/IEC 27001:2022	Clause 6.1.3 — Information security risk treatment	The library as a whole: the Annex A controls compared against the controls risk treatment needs, and whether each usually applies
ISO/IEC 27001:2022	Annex A 5.1 — Policies for information security	Control Library, A.5.1, and the P04 policy documents named against controls throughout
ISO/IEC 27001:2022	Annex A 5.36 — Compliance with policies, rules and standards for information security	Typical evidence and common mistakes: how compliance with each control is checked; Our Controls
NIST CSF 2.0	GV.OC-03 — “Legal, regulatory, and contractual requirements regarding cybersecurity - including privacy and civil liberties obligations - are understood and managed”	A.5.31 and the regulated-entity tailoring note: legal, regulatory and contractual requirements mapped to controls
NIST CSF 2.0	GV.PO-01 — “Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced”	Implementation steps and CISO Times documents: the policies and procedures that put each control in place

Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0