Building an ISMS people actually use

Scope: the ISO/IEC 27001 management system, end to end · Who: the officer who owns it · Prerequisites: a named sponsor and a defined boundary · First result: one quarter

1. Why this exists (the failure mode it prevents)#

Most management systems fail in the same way. The documents exist and nobody uses them.

A sponsor signs the policy. Someone populates the risk register in a fortnight. The Statement of Applicability lists every reference control with a one-line justification. Then the system stops. Twelve months later the certification body asks for records: access reviews, supplier reassessments, triaged incidents, measured objectives. There are none, because no process ever produced any.

The finding is predictable in its wording. The organisation cannot demonstrate that the management system has been operated as documented. That is a major nonconformity, and writing more documents does not close it.

Practitioners call this a desk product: an artefact built for an assessment rather than a mechanism the organisation runs. The test is simple. Remove the ISMS owner for a quarter and watch what still happens. In a working system, access reviews fall due, the change board asks the security question, the incident log fills and the forum meets. In a desk product, everything stops.

This playbook turns the second into the first. Each clause becomes a recurring activity with an owner, an input and a named output. Evidence then appears as a by-product of the activity, not as an effort mounted in the weeks before an audit.

2. Definitions (only the ones that cause disputes)#

Six terms account for most arguments between a security team and its assessor. Each is given in working language, with the clause it sits in. Requirement text is copyright and is paraphrased throughout, never reproduced.

Term	Working definition	Source
ISMS scope	The boundary the system covers, expressed as organisational units, locations, services and information, plus every interface that crosses it. Exclusions are defensible only when the interface to what sits outside is described and governed.	Clause 4.3 1
Interested parties	Parties whose requirements the system has to satisfy, from customers and regulators to insurers and certification bodies, recorded with the specific requirement each one imposes. A list of names without requirements is not a determination.	Clause 4.2 2
Statement of Applicability	The record of which controls are necessary, why each is included, whether it is implemented, and why any control in the reference set is excluded. A set of accountable judgements, not a checklist.	Clause 6.1.3 3
Risk owner	The role accountable for a risk, for approving its treatment and for accepting residual risk. Usually a business or function head, and usually not the person who operates the control.	Clause 6.1.2 4
Management review	Top management's scheduled review of the system's continuing suitability, adequacy and effectiveness, with defined inputs and recorded results. A status presentation with no decisions recorded does not meet it.	Clause 9.3 5
Internal audit vs certification audit	Internal audit is the organisation's own planned conformity check, performed with objectivity and impartiality. A certification audit is a third-party assessment against the same requirements, and it samples the records the internal programme should already have produced.	Clause 9.2 6

3. The method — numbered steps, each with input, activity, output and owner#

Eight steps. The first seven follow the clause order of the standard, because that order is the dependency order. Scope constrains risk. Risk selects controls. Controls need documents, documents need a rhythm, and the rhythm produces evidence. The eighth step is the calendar holding the other seven together.

3.1 Fix the boundary (clause 4)#

Scope is the first decision and the one most often deferred. A boundary around the whole legal entity creates work a small function cannot sustain. A boundary around one server room produces a certificate no customer values. The usable boundary is the smallest that still covers the information interested parties care about.

Clause 4 asks four things in sequence: what internal and external issues matter, who the interested parties are and what they require, where the boundary sits, and that the system itself is established and maintained.

• Input: organisation chart, service catalogue, contractual and regulatory obligations, hosting and location list.
• Activity: record internal and external issues; list interested parties against their requirements; draw the boundary; name the counterparty and governing control for every interface that crosses it.
• Output: ISMS scope statement, one page, approved; interested parties and requirements register.
• Owner: ISMS owner drafts; top management approves.

The scope statement is the first document an assessor reads, and every later inconsistency is measured against it. A certificate scope reading "cloud platform operations" beside a risk register full of office printers is visible in the first hour.

3.2 Turn leadership into decisions, not a signature (clause 5)#

Clause 5 is where most systems are thinnest, because a signature is cheap and a decision is not. The standard's three sub-clauses are leadership and commitment, policy, and organisational roles, responsibilities and authorities ⁷. Read together they ask for evidence that named people hold named authority and use it.

• Input: draft policy, proposed role model, proposed risk criteria, resourcing estimate.
• Activity: top management approves the policy; assigns responsibility and authority for the system and for reporting on its performance; commits the resources; establishes the security forum with a quorum, a cadence and a decision log.
• Output: information security policy, signed and dated; roles and authorities matrix; security forum terms of reference and decision log.
• Owner: top management; the ISMS owner prepares the material.

One separation keeps the rest of the system honest. Risk owners are accountable for outcomes and sit in the business. Control owners operate the mechanisms and sit in engineering, human resources, legal or facilities. The register should say when they differ.

3.3 Run the risk engine until it produces the Statement of Applicability (clause 6)#

This is the load-bearing step. Clause 6.1 covers actions to address risks and opportunities, and clause 6.2 covers information security objectives and planning to achieve them ⁸. The sequence inside 6.1 matters more than any other ordering in the standard. Define the criteria, identify and analyse risk, then evaluate against those criteria. Choose treatment next. Only after that, compare the chosen controls against the reference set to test for omissions.

Reversing that sequence is the most common structural defect. A team copies the reference controls, writes a justification for each, then reconstructs risks to fit. The resulting Statement of Applicability reads as generic because it is. An assessor detects it by picking one applicable control and asking which risk made it necessary.

• Input: approved scope, information and asset inventory, threat sources, incident history, risk criteria proposal.
• Activity: approve the acceptance and assessment criteria; identify risks and assign each an owner; analyse and evaluate; select treatment; determine the necessary controls; compare against the reference set for gaps; produce the Statement of Applicability and the treatment plan; obtain risk-owner approval of residual risk.
• Output: risk assessment and treatment methodology; risk register; risk treatment plan; Statement of Applicability; information security objectives with measures and target dates.
• Owner: ISMS owner runs the process; risk owners approve treatment and residual risk.

The reference control set is ISO/IEC 27002:2022, organised as organisational, people, physical and technological controls ⁹. Treat it as a completeness check on a decision already made, never as the starting inventory.

Clause 6.2 is where objectives collapse into slogans. An objective that cannot be measured cannot be reviewed, so clause 9.3 has nothing to consider. "Improve security awareness" is a slogan. "Every joiner completes induction training before system access is granted, measured monthly" is an objective.

3.4 Build a document set people can find (clause 7)#

Clause 7 covers resources, competence, awareness, communication and documented information ¹⁰. The documentation sub-clauses are 7.5.1 General, 7.5.2 Creating and updating, and 7.5.3 Control of documented information ¹¹.

Four layers keep the set navigable. One policy at the top, approved by top management. Below it, the topic-specific policies that cover access control, cryptography, supplier security, acceptable use and incident handling. Those correspond to reference control 5.1 "Policies for information security" ¹². Below those, procedures that say who does what and when, corresponding to control 5.37 "Documented operating procedures" ¹³. At the bottom, records: tickets, minutes, review results, training completions, test reports.

• Input: the control decisions from step 3.3, existing operational procedures already used by other functions.
• Activity: write the smallest set that makes each process consistent; reuse existing joiner, change and procurement procedures; establish version control, approval, distribution, retention and disposal; control externally sourced documents too; record competence and awareness activity.
• Output: policy, topic-specific policies, procedures, document control register, competence and training records.
• Owner: ISMS owner for the register; each process owner for their own procedure.

Three questions decide whether a document should exist. Does the standard require it? Would the process be inconsistent without it? Will anyone read it? Three negatives mean it should not be written. Assessors award nothing for volume and penalise every gap between document and practice.

Competence and awareness are separate requirements, at clauses 7.2 and 7.3, with reference control 6.3 "Information security awareness, education and training" ¹⁴. One induction deck satisfies neither. A layered programme with a record per person does.

3.5 Give the system an operating rhythm (clauses 8 and 9)#

Clause 8 covers operational planning and control, risk assessment and risk treatment as running activities rather than one-off projects ¹⁵. Clause 9.1 covers monitoring, measurement, analysis and evaluation ¹⁶. The rhythm is what converts both into records.

A workable cadence has three loops. Monthly, control owners report measures and open actions move. Quarterly, the forum reviews risk changes, supplier assurance, incidents and audit findings, and records decisions. Annually or half-yearly, top management performs the review clause 9.3 defines and records the decisions.

• Input: measurement definitions, control-owner reports, incident and change records, supplier assessment status, audit findings, previous review actions.
• Activity: collect measures on a fixed date; publish a short pack; hold the forum and record decisions with owners and dates; run the management review against its input list and record decisions, not observations.
• Output: measurement results; forum minutes and decision log; management review record.
• Owner: ISMS owner convenes; control owners supply measures; top management performs the review.

Measures split into two families. Performance measures say how well a control runs: time to remediate critical vulnerabilities, access reviews completed on schedule, leaver accounts disabled on time. Risk indicators say exposure is rising: overdue critical vulnerabilities, orphaned privileged accounts, suppliers without current assurance. A set that is always green is itself a warning sign.

Supplier assurance belongs in this rhythm, not in procurement alone. The reference controls run from 5.19 "Information security in supplier relationships" through 5.22 "Monitoring, review and change management of supplier services" ¹⁷. A questionnaire at onboarding leaves the monitoring requirement with no evidence.

3.6 Audit the system before anyone else does (clause 9.2)#

Clause 9.2 requires a planned internal audit programme, with audit criteria and scope defined for each audit, and auditors selected so that objectivity and impartiality are preserved ¹⁸. In practice this means the person who runs a process does not audit it, and the ISMS owner does not audit the clauses they operate.

Plan the programme over the whole certification cycle, not one year at a time, weighted by risk and by the age of the last finding. Cover clauses 4 to 10 and every applicable control once per cycle. Cover the volatile areas yearly: access management, change, supplier assurance, incident handling.

• Input: approved programme, previous findings, process documentation, sampling plan.
• Activity: confirm criteria and scope per audit; sample records rather than reading documents; interview the people who do the work; classify findings; report results to the relevant management; feed nonconformities into step 3.7.
• Output: internal audit programme; audit plan and report per audit; finding register entries.
• Owner: an auditor independent of the audited process; the ISMS owner owns the programme.

The reference control for the independent view is 5.35 "Independent review of information security" ¹⁹. Routine checking sits at 5.36 "Compliance with policies, rules and standards for information security" ²⁰. Small organisations often trade auditors with a peer function, or use an external auditor who is not the implementation consultant.

3.7 Close findings so they stay closed (clause 10)#

Clause 10 has two parts, continual improvement and nonconformity and corrective action ²¹. The distinction that matters operationally is between correction and corrective action. Correction fixes the instance. Corrective action removes the cause so the instance does not recur.

A finding register with a "fixed" column and nothing else is not enough. Each entry needs the nonconformity, the correction, the cause, the action on that cause, an owner, a date, and the later check that the action worked.

• Input: findings from internal audit, incidents, supplier assessments, management review, external assessment.
• Activity: record and classify the nonconformity; correct the instance; analyse the cause; check whether comparable nonconformities exist elsewhere; act on the cause; verify effectiveness later; update the register and affected documents.
• Output: finding register entries with cause, action, verification and closure date; updated documents.
• Owner: the process owner where the finding sits; the ISMS owner tracks closure.

The incident side of the same loop uses reference controls 5.24 to 5.27 ²². The set runs from "Information security incident management planning and preparation" to "Learning from information security incidents". Learning is a separate control precisely because most organisations stop at recovery.

3.8 The first-year calendar#

The calendar assumes a defined boundary and an appointed sponsor on day one. It produces what an external assessment cannot proceed without: a full internal audit cycle and a completed management review, both supported by records that predate them.

Quarter	Focus	Artefacts completed	Gate before moving on
Q1	Mandate, boundary, leadership	Scope statement; interested parties register; policy; roles and authorities matrix; forum terms of reference	Top management has approved the scope and the policy in a recorded decision
Q2	Risk engine and control selection	Risk methodology; risk register with named owners; risk treatment plan; Statement of Applicability; objectives with measures	Every applicable control traces to at least one risk, and every exclusion has a reason
Q3	Documents and operation	Topic-specific policies; procedures; document control register; competence and awareness records; first measurement cycle	Control owners have produced one full month of records without prompting
Q4	Verification and review	Internal audit programme and first full audit; finding register with cause analysis; management review record	Findings from the audit are closed or have dated plans, and the review recorded decisions

Two months of operating records before the external assessment is the practical minimum, and a quarter is safer. A system whose records begin the week before the assessment produces the nonconformity described in section 1.

4. Deliverables#

The list below is the documented information ISO/IEC 27001:2022 requires, named as it will be named in the evidence set. Retention periods are organisational choices rather than requirements of the standard; the defaults shown suit a three-year certification cycle and belong in the document control register.

Deliverable	Required by	Format	Retention
ISMS scope statement	Clause 4.3 1	document	current plus one cycle
Information security policy	Clause 5.2 23	document	current plus one cycle
Risk assessment and risk treatment methodology	Clauses 6.1.2 and 6.1.3 24	document	current plus one cycle
Statement of Applicability	Clause 6.1.3 3	spreadsheet or register	every version, whole cycle
Information security objectives	Clause 6.2 25	register	whole cycle
Competence records	Clause 7.2 26	records	duration of employment plus statutory period
Document control register	Clause 7.5.3 27	register	whole cycle
Risk assessment results	Clause 8.2 28	register	every version, whole cycle
Risk treatment results and residual risk approvals	Clause 8.3 29	register plus signed approvals	whole cycle
Measurement results	Clause 9.1 16	reports	whole cycle
Internal audit programme, plans and reports	Clause 9.2.2 18	documents	whole cycle
Management review record	Clause 9.3.3 30	minutes with decisions	whole cycle
Finding register with cause, action and verification	Clause 10.2 31	register	whole cycle

Templates for the risk register and the finding tracker ship with later playbooks in this series; template pending.

5. What the auditor will ask#

Every clause named below is registered with its verified reference in section 7. The phrasing follows how an assessor opens a line of enquiry: a request for a record, then a request for the decision behind it.

An assessment that stays at document level is going well. One that moves to records and then to interviews is where a desk product fails: the records are absent and the interviewees have never seen the procedure.

6. Failure modes and how they surface as findings#

Five patterns account for most avoidable findings. Each is given as the pattern, the wording it produces in a report, and the smallest change that removes it.

The root is the same in all five: an artefact produced for the assessment rather than for the operation has no upstream input and no downstream consumer.

7. Mapping to the standard#

Every clause and control title below was read from the publisher's own contents listing on the ISO Online Browsing Platform on the date shown. Requirement text is paraphrased; only titles are quoted.

Clause	Title	Deliverable	Evidence an assessor samples	Verified
4.1	Understanding the organization and its context	Context record	Issues list reviewed in the cycle	32
4.2	Understanding the needs and expectations of interested parties	Interested parties register	Rows traced to controls or obligations	2
4.3	Determining the scope of the information security management system	ISMS scope statement	Approved scope with interface table	1
5.1	Leadership and commitment	Sponsor mandate	Minutes showing top management decisions	33
5.2	Policy	Information security policy	Signed, dated, distributed	23
5.3	Organizational roles, responsibilities and authorities	Roles and authorities matrix	Named holders; reporting line	34
6.1.2	Information security risk assessment	Risk methodology; risk register	Risks with owners; criteria applied	4
6.1.3	Information security risk treatment	Statement of Applicability; treatment plan	Applicability traced to risks	3
6.2	Information security objectives and planning to achieve them	Objectives register	Measure, target, date, latest result	25
7.2	Competence	Competence records	Records per role	26
7.3	Awareness	Awareness programme	Attendance and comprehension	35
7.5.3	Control of documented information	Document control register	Version, approval, distribution, retention	27
8.1	Operational planning and control	Operating plan; change records	Planned activity recorded	36
8.2	Information security risk assessment	Risk assessment results	Dated output for the current period	28
8.3	Information security risk treatment	Treatment results; residual approvals	Risk-owner approval per acceptance	29
9.1	Monitoring, measurement, analysis and evaluation	Measurement definitions and results	Consecutive reporting periods	16
9.2.2	Internal audit programme	Audit programme, plans, reports	Cycle coverage; auditor independence	18
9.3.2	Management review inputs	Review input pack	Every required input present	37
9.3.3	Management review results	Management review record	Decisions with owners and dates	30
10.1	Continual improvement	Improvement backlog	Changes made and their source	38
10.2	Nonconformity and corrective action	Finding register	Cause, action, verification, closure	31
Annex A	Information security controls reference	Statement of Applicability	Every reference control judged	39
27002 5.1	Policies for information security	Topic-specific policies	Approved set, reviewed in period	12
27002 5.2	Information security roles and responsibilities	Roles and authorities matrix	Allocation recorded	40
27002 5.19	Information security in supplier relationships	Supplier assurance process	Assessment record per supplier	41
27002 5.22	Monitoring, review and change management of supplier services	Supplier monitoring schedule	Dated reassessments	42
27002 5.35	Independent review of information security	Independent review plan	Reviewer independence recorded	19
27002 5.37	Documented operating procedures	Procedures	Procedure matches observed practice	13
27002 6.3	Information security awareness, education and training	Awareness programme	Per-person completion records	14

8. Checklist#

Each item is observable. "Reviewed" is not; a dated approval in a register is.

• The scope statement is approved, dated, and lists every interface crossing the boundary.
• The interested parties register names a specific requirement against each party.
• The policy is signed by top management and its current version is distributed.
• The roles and authorities matrix names a holder for every ISMS responsibility.
• The security forum has terms of reference, a quorum, a cadence and a decision log.
• Risk acceptance criteria are approved and applied consistently across the register.
• Every risk entry has a named owner who is not the control operator.
• Every control marked applicable traces to at least one risk register entry.
• Every excluded reference control carries a reason specific to this organisation.
• The risk treatment plan carries dated risk-owner approval of residual risk.
• Each objective has a measure, a target, a date and a recorded latest result.
• The document control register shows version, approver, distribution and retention.
• Competence and awareness records exist per person, not per session.
• Measurement results exist for at least three consecutive periods.
• The internal audit programme covers clauses 4 to 10 and every applicable control.
• Each audit records its criteria, scope and the auditor's independence.
• The management review record contains decisions with owners and dates, not observations.
• Every finding carries a cause analysis, an action on the cause and a verification date.
• Supplier assurance shows reassessment after onboarding, with dates.

References#

Primary sources only. Both were read on the ISO Online Browsing Platform, where clause and control titles are visible without purchase.

1. ISO/IEC. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO/IEC 27001:2022. Published by ISO and IEC. Contents and clause titles read at https://www.iso.org/obp/ui/#iso:std:iso-iec:27001:ed-3:v1:en ⁴³
2. ISO/IEC. Information security, cybersecurity and privacy protection — Information security controls. ISO/IEC 27002:2022. Published by ISO and IEC. Contents and control titles read at https://www.iso.org/obp/ui/#iso:std:iso-iec:27002:ed-3:v2:en ⁴⁴

Retention periods, forum cadences and calendar timings above are organisational choices rather than requirements of either standard.