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.

There is a regulatory reason as well as an operational one. Article 21 of Directive (EU) 2022/2555, the NIS2 Directive, applies to essential and important entities. It requires appropriate and proportionate technical, operational and organisational measures for the risks to the network and information systems those entities use ¹. Proportionality is judged on the entity's exposure to risk, its size, and the likelihood and severity of incidents. Paragraph 2 then lists ten areas the measures must at least cover ²:

• policies on risk analysis and information system security;
• incident handling;
• business continuity, including backup management, disaster recovery and crisis management;
• supply chain security, including the relationships with direct suppliers and service providers;
• security in acquisition, development and maintenance, including vulnerability handling and disclosure;
• policies and procedures to assess the effectiveness of the measures;
• basic cyber hygiene practices and cybersecurity training;
• policies and procedures on cryptography and, where appropriate, encryption;
• human resources security, access control policies and asset management;
• multi-factor or continuous authentication and secured communications, where appropriate.

Every item on that list is a process with an owner and a record.

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

Six terms account for most arguments between a security team and its assessor. 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 3
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 4
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 5
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 6
Management review	Top management's scheduled check that the system still fits, suffices and works, with defined inputs and recorded results. A status presentation with no decisions recorded does not meet it.	Clause 9.3 7
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 8

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. The eighth is the calendar holding them 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 ⁹.

• 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.

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, and section 6 gives the finding it produces. 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: access reviews completed on schedule, leaver accounts disabled on time. Risk indicators say exposure is rising: overdue critical vulnerabilities, 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" ²².

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.

• 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 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.

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; the defaults shown suit a three-year certification cycle.

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

5. What the auditor will ask#

Every clause named below carries its verified reference in section 7. An assessor opens with 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, then to interviews, is where a desk product fails.

6. Failure modes and how they surface as findings#

Five patterns account for most avoidable findings, each with the wording it produces in a report and the smallest change that removes it.

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

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.

Related#

• Control ownership and the control catalogue — who owns each selected control.
• Policy architecture people can find — the document set of step 3.4.
• The security operating model — the forums this rhythm runs in.

References#

Primary sources only. The two standards were read on the ISO Online Browsing Platform, where clause and control titles are visible without purchase; the directive at the EU Publications Office.

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 ⁴⁶
3. European Parliament and Council. Directive (EU) 2022/2555 of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). OJ L 333, 27.12.2022, p. 80. Article 21 read at https://publications.europa.eu/resource/celex/32022L2555 ⁴⁷

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