# ISMS Worked Walkthrough: [Organization name]

> Narrative worked example that follows one fictional small company,
> Quillmere Analytics Ltd, from the decision to build an information
> security management system (ISMS) to an ISO/IEC 27001:2022 + Amd 1:2024
> certificate in about six months. At each step it shows a filled
> extract of the key record (scope statement, risk entry, Statement of
> Applicability rows, objective, internal audit finding, management
> review decision, Stage 2 finding and closure) and points to the
> library template that holds the full format. Use it to see how the
> documents connect, then write your own project diary in section 17.
> Every company detail, date, figure and ID is fictional and marked
> *Example*. Replace every `[bracketed]` value and every row marked
> *Example* when you reuse a format.

<!--
Guidance: How to use this template
- Use it at the start of an ISMS project, to show top management and the
  project team what "done" looks like at each step, and again before the
  internal audit, to check that your own records link up the same way.
- Fill first: Document control (as the owner of your own copy) and the
  project diary in section 17. Read sections 2 to 13 in order; each
  extract names the template to open for the full format.
- Main pitfall: copying the Quillmere extracts as if they were your
  records. They show the level of detail an auditor expects, not your
  risks, controls or decisions. An auditor will notice text that does
  not match how your organization works.
- The extracts follow the shared fictional facts of the library:
  Quillmere Analytics Ltd has 46 staff (38 employees, 8 contractors),
  one office plus remote staff, production on one public cloud provider
  in two regions, processes customer personal data as a processor, and a
  part-time ISMS manager (0.5 FTE, the Head of Engineering Operations).
- Related templates: `isms/isms-learning-path`,
  `isms/certification-audit-explained`, `isms/isms-implementation-roadmap`,
  `compliance/ms-scope`, `compliance/risk-register`,
  `compliance/statement-of-applicability`, `compliance/objectives-register`,
  `isms/isms-internal-audit-report`, `compliance/management-review`,
  `isms/certification-findings-action-plan`.
-->

## Document control

<!-- Guidance: Learning-path documents use LRN-ISMS IDs. If you turn section 17 into your own project diary, keep this document under control so the diary has an owner and a version. -->

| Field | Value |
|---|---|
| Document ID | LRN-ISMS-09 |
| Version | [1.0] |
| Status | [Draft / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@project-sponsor], [@internal-audit-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024; certification process per ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024 |
| Fictional organization | Quillmere Analytics Ltd (small tier) *(Example)* |
| Narrative period | 2027-01-04 to 2027-06-15 *(Example)* |
| Next scheduled review | [Yearly, or when the linked templates change] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| Project sponsor | [@ceo] | [Approved for team briefings] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | 2027-01-11 | [@isms-manager] | Walkthrough shared with the project team at kick-off |
| [x.y] | YYYY-MM-DD | [@author] | [Change] |

## Contents

1. About Quillmere Analytics Ltd
2. Timeline at a glance
3. Month 1: decide and start
4. Month 1: context and scope
5. Month 2: risk assessment and treatment
6. Month 2 to 3: Statement of Applicability
7. Month 2 to 3: objectives and control implementation
8. Month 3: internal audit
9. Month 4: management review
10. Month 4: Stage 1 audit
11. Month 5: Stage 2 audit
12. Month 6: findings closure and certification decision
13. After the certificate
14. Lessons learned
15. Size tiers: the same story at other sizes
16. Records and evidence
17. Your own project diary
18. References

## 1. About Quillmere Analytics Ltd

<!-- Guidance: Purpose: set the facts every extract relies on. Questions to answer for your own copy: what does the organization do, how many persons are in scope, where is information processed, which roles does it play for personal data? Pitfall: a profile that differs from the scope document. -->

Quillmere Analytics Ltd *(Example)* sells a business-to-business SaaS
analytics platform to retail customers. It has 46 staff: 38 employees
and 8 contractors. Everyone works from one office or remotely.
Production runs on one public cloud provider in two regions, a primary
region and a disaster recovery (DR) region. The platform holds customer
datasets that include personal data, which Quillmere processes as a
processor under data processing agreements; GDPR is one example of the
data protection law its customers rely on.

Two enterprise customers made an accredited ISO/IEC 27001 certificate a
condition of their contract renewals, due in the summer of 2027. The
CEO decided on 2027-01-04 to build an ISMS and seek certification within
six months. The Head of Engineering Operations became ISMS manager for
half of their time (0.5 FTE). No consultant ran the project; an
external auditor was contracted for the internal audit only.

Quillmere was not starting from nothing. It already had single sign-on
for most tools, encrypted laptops, cloud backups, a leaver process run
by HR and an engineering metrics dashboard reviewed monthly. The ISMS
project gave these practices owners, documents and records, and filled
the gaps around them.

## 2. Timeline at a glance

<!-- Guidance: Purpose: show the whole path on one page. Keep the chart consistent with the sections that follow (same steps, same dates). Pitfall: a plan with the internal audit and management review squeezed into the week before Stage 1, leaving no time to act. -->

```mermaid
gantt
  title Quillmere Analytics Ltd, decision to certificate (Example)
  dateFormat YYYY-MM-DD
  section Start
  Decision and business case :d0, 2027-01-04, 7d
  Gap assessment and CB selection :g0, 2027-01-11, 21d
  Context and scope approved :c0, 2027-01-18, 12d
  section Plan
  Risk assessment and treatment plan :r0, 2027-02-01, 28d
  Statement of Applicability v1.1 :soa, 2027-02-22, 17d
  Objectives set :ob, 2027-02-15, 14d
  section Operate
  Control implementation and records :im, 2027-02-15, 70d
  Internal audit fieldwork :ia, 2027-03-15, 3d
  Internal audit report issued :milestone, iar, 2027-03-29, 0d
  Management review :mr, 2027-04-06, 1d
  section Certify
  Stage 1 audit :s1, 2027-04-12, 2d
  Close Stage 1 areas of concern :aoc, 2027-04-16, 21d
  Stage 2 audit :s2, 2027-05-10, 3d
  Findings response :fr, 2027-05-13, 30d
  Certification decision :milestone, cd, 2027-06-15, 0d
```

| Milestone *(Example)* | Date | Record |
|---|---|---|
| Decision to certify | 2027-01-04 | Business case DOC-ISMS-029, project charter DOC-ISMS-009 |
| Scope approved | 2027-01-29 | DOC-ISMS-002 v1.0 |
| Risk treatment plan drafted | 2027-02-26 | DOC-ISMS-013 (not yet signed by risk owners; see section 11) |
| SoA approved | 2027-03-10 | DOC-ISMS-011 v1.1 |
| Internal audit report issued | 2027-03-29 | DOC-ISMS-084, IA-2027-01 |
| Management review held | 2027-04-06 | DOC-ISMS-085, MR-2027-01 |
| Stage 1 (1.5 audit days) | 2027-04-12 to 2027-04-13 | CB Stage 1 report, received 2027-04-16 |
| Stage 1 areas of concern closed | 2027-05-07 | DOC-ISMS-091 section 9 |
| Stage 2 (3.5 audit days) | 2027-05-10 to 2027-05-12 | CB Stage 2 report, findings CBF-2027-01 to 08 |
| Major nonconformity verified closed | 2027-06-09 | DOC-ISMS-093 |
| Certification decision | 2027-06-15 | Certificate, expiry 2030-06-14 |

From decision to certification decision took 162 days, a little over
five months, inside the six-month target.

## 3. Month 1: decide and start

<!-- Guidance: Purpose: show the decisions that must exist before work starts. Questions to answer: why certify, what is the budget, who owns the project, which CB? Pitfall: starting with policies before the scope and the risk method exist. Auditor check: top management commitment (clause 5.1) visible in dated decisions. -->

In the first week the CEO signed a two-page business case
(`isms/isms-business-case`, DOC-ISMS-029) built on the two contract
renewals and a list of security questionnaires that took engineers
about a day each. The project charter (`isms/isms-project-charter`,
DOC-ISMS-009) named the CEO as sponsor, the Head of Engineering
Operations as ISMS manager and project lead, and the leadership team as
the steering committee meeting every two weeks.

A gap assessment against clauses 4 to 10 and Annex A
(`compliance/iso-27001-gap-assessment`, DOC-ISMS-098) took the ISMS
manager four days. The main gaps were the ones most young companies
share: no documented scope, no risk methodology or register, no SoA, no
internal audit, no management review, an informal process for
contractor leavers and a supplier list that covered only paid
infrastructure services.

Quillmere compared three accredited certification bodies with
`isms/certification-body-selection` (DOC-ISMS-090), checked that each
held ISO/IEC 27001 accreditation from a signatory of the Global ACI MRA
(formerly IAF MLA), and selected the one shown as Bidder B in that
template's worked example. The CB set audit time from ISO/IEC 27006-1:
1.5 days for Stage 1 and 3.5 days for Stage 2, 5.0 audit days for the
initial audit *(Example)*. The roadmap (`isms/isms-implementation-roadmap`, DOC-ISMS-030) was then
fixed around the CB's available dates.

## 4. Month 1: context and scope

<!-- Guidance: Purpose: show a scope that an auditor can test. Questions to answer: which activities, sites, people and systems are inside, which interfaces cross the boundary? Pitfall: a scope wider than the controls can cover in six months, or so narrow that customers do not value it. Auditor check: clause 4.3, and whether the certificate wording will match. -->

The context and interested parties record (`isms/isms-context-interested-parties`,
DOC-ISMS-003) listed issues such as customer demands for certification,
dependence on one cloud provider, a tight labour market for security
skills and data protection obligations as processor. Following Amd 1:2024
to clause 4.1, the team considered whether climate change was a relevant
issue; they judged it relevant only through the cloud provider's
regional resilience, already covered by the DR region.

**Extract 1: scope statement and interfaces** *(Example)*. Full format:
`compliance/ms-scope` (DOC-ISMS-002), sections 4 and 5.

> Scope statement *(Example)*: "The information security management
> system covering the development, operation and support of the
> Quillmere Analytics SaaS platform, including the office, remote staff
> and the production and DR environments hosted by a public cloud
> provider."

| ID | Interface or dependency | Direction | Party | Control |
|---|---|---|---|---|
| INT-01 *(Example)* | Infrastructure, platform services and physical data centres for production and DR | Into scope | Public cloud provider | Shared responsibility matrix, provider assurance report review, A.5.23 |
| INT-02 *(Example)* | Customer datasets uploaded for analysis | Into scope | Customers (controllers) | Data processing agreements, A.5.34, encryption A.8.24 |
| INT-03 *(Example)* | Payroll and accounting | Out of scope, outsourced | Accounting firm | Supplier agreement, no access to customer data |
| INT-04 *(Example)* | Support ticketing and code repository tools | Into scope | SaaS suppliers | Supplier register DOC-ISMS-066, A.5.19 to A.5.22 |

The scope was approved at the steering committee on 2027-01-29 as
DOC-ISMS-002 v1.0. Every person working on the platform, all 46, fell
inside it.

## 5. Month 2: risk assessment and treatment

<!-- Guidance: Purpose: show one risk traced from description to acceptance. Questions to answer: does each risk have an owner, inherent and residual scores on the agreed scale, a treatment decision and, where needed, an acceptance at the right level? Pitfall: a register with treatments but no approval by risk owners. Auditor check: clauses 6.1.2, 6.1.3, 8.2 and 8.3. -->

The ISMS manager adapted the methodology (`compliance/risk-methodology`,
DOC-ISMS-010): likelihood 1 to 5 times impact 1 to 5, score 1 to 25,
bands Low 1-4, Medium 5-9, High 10-16, Critical 17 to 25 (in practice 20
and 25). Risk criteria and
appetite went into `isms/isms-risk-appetite-criteria` (DOC-ISMS-015),
and workshops with each team produced the register (`compliance/risk-register`,
DOC-ISMS-016) using the threat and vulnerability catalogue
(`isms/isms-threat-vulnerability-catalogue`, DOC-ISMS-018).

**Extract 2: risk register entry** *(Example)*. Full format:
`compliance/risk-register` (DOC-ISMS-016), section 3; acceptance in
`isms/isms-risk-acceptance-record` (DOC-ISMS-019), worked example ACC-001.

| ID | Category | Asset or process | Source | Risk description (cause, event, consequence) | Appetite | Inherent L | Inherent I | Inherent score and level | Treatment | Controls (Annex A) | Residual L | Residual I | Residual score and level | Owner | Accepted on and expiry | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| R-018 *(Example)* | Confidentiality of customer and personal data | Legacy scheduled export service | THR-006, VUL-013, VUL-001 | The service uses local accounts instead of the identity provider, so a leaver's account could stay usable and export customer datasets (confidentiality) | Averse | 3 | 4 | 12 High | Modify with compensating controls, then accept; replace the service in Q3 2027 (RTP-019) | A.8.5 secure authentication, A.5.18 access rights review, A.8.16 monitoring activities, A.8.3 information access restriction | 2 | 4 | 8 Medium | Head of Product | 2027-03-31, expires 2027-09-30 (ACC-001) | Accepted |

Because the category appetite was Averse, the appetite rules escalated
acceptance one level, and the CEO accepted the residual risk on
2027-03-31 after the ISMS manager's review. The scores add up on the
5 x 5 scale: 3 x 4 = 12 (High) before, 2 x 4 = 8 (Medium) with the
compensating controls, and a target of 1 x 4 = 4 (Low) once the service
is replaced.

R-018 was the one acceptance that was fully documented at this stage.
The treatment plan (`compliance/risk-treatment-plan`, DOC-ISMS-013) was
drafted on 2027-02-26, but the team did not obtain risk owners'
approval of the plan or their acceptance of the other residual risks.
That gap returns in section 11.

## 6. Month 2 to 3: Statement of Applicability

<!-- Guidance: Purpose: show SoA rows with real justifications and evidence. Questions to answer: is each control linked to a risk, law, contract or business reason, and does each exclusion have a reason? Pitfall: "Implemented" in every row with no evidence reference. Auditor check: clause 6.1.3 d and sampled controls at Stage 2. -->

The SoA compared the controls chosen in risk treatment with all 93
Annex A controls (37 organizational, 8 people, 14 physical, 34
technological). Each row gives a basis code: R (risk), L (law), C
(contract), B (business need).

**Extract 3: Statement of Applicability rows** *(Example)*. Full format:
`compliance/statement-of-applicability` (DOC-ISMS-011), section 4.

| Control | Short label (not official title) | Applicable | Basis | Justification | Status | Reference document | Evidence |
|---|---|---|---|---|---|---|---|
| A.5.18 *(Example)* | Access rights provisioning and review | Yes | R, C | Leaver and privilege risks (R-018); customer contracts require timely removal of access | Implemented | Access control policy DOC-ISMS-041 | Quarterly access review records, HR leaver list reconciliation |
| A.5.23 *(Example)* | Security for cloud service use (new in 2022) | Yes | R, C | Production and DR hosted on one public cloud provider (INT-01) | Implemented | Cloud services security policy DOC-ISMS-044 | Provider assurance report review |
| A.7.4 *(Example)* | Physical security monitoring (new in 2022) | Yes | R | Office holds network equipment and laptops in storage; data centres are covered by the cloud provider under A.5.23 | Implemented | Physical security policy DOC-ISMS-055 | Badge access logs, alarm monitoring contract |
| A.8.13 *(Example)* | Information backup | Yes | R, C | Customer datasets and configuration must be recoverable in the DR region | Implemented | Backup policy DOC-ISMS-061 | Backup and restore test log DOC-ISMS-071 |
| A.8.30 *(Example)* | Outsourced development | No | B | All code is written by staff under Quillmere's direct supervision; no development is outsourced (confirmed against the supplier register) | Not applicable | SoA section 5 | Supplier register DOC-ISMS-066 |

The SoA was approved as DOC-ISMS-011 v1.1 on 2027-03-10. The evidence
column was the start of the control evidence matrix
(`isms/control-evidence-matrix`, DOC-ISMS-033), which later saved hours
at Stage 2.

## 7. Month 2 to 3: objectives and control implementation

<!-- Guidance: Purpose: show a measurable objective with a plan. Questions to answer: what will be done, by whom, with which resources, by when, and how results are evaluated? Pitfall: objectives without a baseline, so progress cannot be shown. Auditor check: clause 6.2 and the link to monitoring in 9.1. -->

Six objectives went into the objectives register (`compliance/objectives-register`,
DOC-ISMS-024) in February. Most work in months 2 and 3 went into
implementing treatment actions: connecting more tools to single sign-on,
writing the access control policy (`isms/access-control-policy`,
DOC-ISMS-041), the backup policy, the supplier register and the
security event reporting procedure, and running awareness training for
all staff.

**Extract 4: objective and plan** *(Example)*. Full format:
`compliance/objectives-register` (DOC-ISMS-024), sections 1 and 2.

| ID | Objective | Source (policy or risk) | Metric | Baseline | Target | Due | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| OBJ-IS-02 *(Example)* | Remove all access of leavers within 1 business day | Access control policy DOC-ISMS-041; risk R-018 | Percentage of leavers whose access to every in-scope system is removed within 1 business day of the last working day | 78% (7 of 9 leavers, 2026-09-01 to 2027-02-28) | 100% | 2027-09 | Head of Engineering Operations | At risk (April 2027) |

| Objective | What will be done | Resources | Who | When | How results are evaluated |
|---|---|---|---|---|---|
| OBJ-IS-02 *(Example)* | Route contractor leaver requests through HR; connect remaining tools to single sign-on; reconcile the HR leaver list with active accounts monthly | 10 engineer days, ISMS manager time | Head of Engineering Operations | 2027-04 to 2027-09 | Monthly reconciliation report, quarterly access review |

The baseline was added after the internal audit (section 8): at first,
four of the six objectives had targets but no baseline.

## 8. Month 3: internal audit

<!-- Guidance: Purpose: show a well-written finding: requirement, evidence, extent, statement, effect. Questions to answer: is the auditor independent of the area, does the audit cover all clauses and the sampled controls? Pitfall: an internal audit run by the person who wrote the documents, or one held too late to act on. Auditor check: clause 9.2, and whether findings were followed through. -->

An external contract auditor carried out the first internal audit
(IA-2027-01) from 2027-03-15 to 2027-03-17 against clauses 4 to 10 and
30 Annex A controls, using `isms/isms-internal-audit-checklist`
(DOC-ISMS-083). The report, issued on 2027-03-29, recorded 0 major
nonconformities, 2 minor nonconformities, 1 observation and 1
opportunity for improvement.

**Extract 5: internal audit finding** *(Example)*. Full format:
`isms/isms-internal-audit-report` (DOC-ISMS-084), section 7; tracked in
`isms/audit-findings-register` (DOC-ISMS-086).

| Field | Content *(Example)* |
|---|---|
| Finding | AF-2027-002, minor nonconformity, control A.5.18 as implemented by the access control policy |
| Requirement | SoA DOC-ISMS-011 marks A.5.18 Implemented; DOC-ISMS-041 requires all access of a leaver to be removed within 1 business day of the last working day |
| Evidence | HR leaver list and identity provider audit log export of 2027-03-16. Seven employee leavers removed on the last working day; two contractor leavers removed 4 and 6 business days late, requested by the engineering manager, not HR |
| Extent | 2 of 9 leavers (both contractors, 2 of 2 contractor leavers) |
| Statement | Access of departing contractors is not removed within the time the policy requires |
| Risk or effect | Former contractors kept access to the code repository and the support tool after leaving; linked risk R-018 |
| Owner and due | Head of Engineering Operations, with Finance for contractor contracts; response due 2027-04-28 |
| Follow-up | Corrective action NC-2027-005 (contractor leavers routed through HR); closure verified by the lead auditor on 2027-05-20 |

The other minor nonconformity (AF-2027-001) found that monthly metric
results were collected but not analysed for three months; the
opportunity for improvement (AF-2027-004) produced the objective
baselines shown in section 7.

## 9. Month 4: management review

<!-- Guidance: Purpose: show decisions, not a slide summary. Questions to answer: were all clause 9.3.2 inputs covered, and do the results cover improvement, changes to the ISMS and resources? Pitfall: missing inputs (for example interested party feedback or the climate change decision), which an auditor spots by comparing the agenda with the clause. Auditor check: clause 9.3 and the follow-up of decisions. -->

The first management review (MR-2027-01) took place on 2027-04-06, a
week after the internal audit report, with the CEO, the leadership team
and the ISMS manager. Inputs included the audit results, the risk
register summary, objective status, supplier issues and the first
security events.

**Extract 6: management review decisions** *(Example)*. Full format:
`compliance/management-review` (DOC-ISMS-085), sections 4 and 5.

| ID | Result type | Decision | Owner | Due |
|---|---|---|---|---|
| MR-D-01 *(Example)* | Continual improvement | Fix the monthly metric review in the ISMS calendar with a named deputy, so that AF-2027-001 cannot recur | ISMS manager | 2027-04-30 |
| MR-D-02 *(Example)* | Change to the management system | Approve access control policy DOC-ISMS-041 v1.1: contractor leaver requests come from HR, not from line managers | Head of Engineering Operations | 2027-04-15 |
| MR-D-03 *(Example)* | Resource needs | Approve 10 engineer days to connect the remaining tools with local accounts to single sign-on, scheduled for Q3 2027 | CEO | 2027-09-30 |
| MR-D-04 *(Example)* | Change to the management system | Confirm readiness for Stage 1 on 2027-04-12 | CEO | 2027-04-12 |

Two weaknesses in this review shaped later events. The agenda did not
record a review of the climate change decision from clause 4.1, which
the Stage 1 auditor noted (section 10). And MR-D-03 scheduled the single
sign-on work for Q3, after Stage 2, so tools with local accounts stayed
outside the leaver process during the audit (section 11).

## 10. Month 4: Stage 1 audit

<!-- Guidance: Purpose: show what Stage 1 produced and how it was closed. Questions to answer: what did the auditor flag, who closed it, by when? Pitfall: treating areas of concern as optional; open ones often become Stage 2 nonconformities. Auditor check: readiness for Stage 2. -->

Stage 1 ran on 2027-04-12 and 2027-04-13 (1.5 audit days), largely
remotely. The ISMS manager had
assembled the documents with `isms/stage-1-readiness-pack` (DOC-ISMS-091):
scope, policy, methodology, risk register and treatment plan, SoA,
objectives, competence records, the internal audit report and the
management review minutes.

The auditor confirmed the scope, the 46 persons in scope and the Stage 2
plan: 3.5 audit days from 2027-05-10 to 2027-05-12 (for example a lead
auditor for three days and a second auditor for half a day), on site at
the office with remote demonstrations of the cloud environment. The
Stage 1 report, received on 2027-04-16, raised three areas of concern:
the climate change decision from clause 4.1 was neither recorded in the
context record nor reviewed at the management review (AOC-01), the
management review had not covered feedback from interested parties
(AOC-02), and two persons in scope had not completed awareness training
(AOC-03). Quillmere copied them into the tracker in section 9 of the
readiness pack, logged the climate change item as AF-2027-005 in the
audit findings register, updated the context record and the management
review agenda, and closed all three by 2027-05-07, before Stage 2.

The auditor did not raise the unsigned treatment plan at Stage 1.
Stage 1 is a readiness review, not a complete audit; silence at Stage 1
is not clearance.

## 11. Month 5: Stage 2 audit

<!-- Guidance: Purpose: show real certification findings and a response the CB accepts. Questions to answer: what is the correction, the extent, the root cause, the corrective action, the effectiveness criterion and the evidence? Pitfall: answering a major with a correction only. Auditor check: the CB accepts the plan and verifies majors before the decision. -->

The CB audit team spent 3.5 audit days over three calendar days,
2027-05-10 to 2027-05-12,
interviewing the CEO, the ISMS manager, engineers, HR and support staff,
and sampling records across the SoA, guided by
`isms/stage-2-audit-evidence-index` (DOC-ISMS-092). At the closing
meeting the lead auditor reported 1 major nonconformity, 3 minor
nonconformities and 4 opportunities for improvement, and recommended
certification subject to verified closure of the major.

**Extract 7: Stage 2 findings and closure** *(Example)*. Full format:
`isms/certification-findings-action-plan` (DOC-ISMS-093), sections 4
and 6.

| Element | CBF-2027-01, major *(Example)* |
|---|---|
| Finding | Clause 6.1.3: no record that risk owners approved the risk treatment plan or accepted residual risks; 14 High risks without acceptance |
| Correction | Risk owners reviewed DOC-ISMS-013 v1.0 on 2027-05-19; top management accepted the 14 High residual risks with treatment decisions on 2027-05-21, each recorded as an acceptance record (ACC-NNN) in DOC-ISMS-019 |
| Extent check | All 62 risks in DOC-ISMS-016 checked: 14 High lacked acceptance (the finding), 48 Low and Medium had acceptance recorded at the DOC-ISMS-010 authority (risk owner for Low, risk owner plus department head for Medium), 0 Critical open. 14 + 48 = 62 |
| Root cause | The procedure described the approval step but named no one to trigger it and no deadline; the project plan ended risk work at "plan drafted" |
| Corrective actions | CA-01 approval step with a named trigger added to DOC-ISMS-010; CA-02 "risk owner approval and acceptance" fixed in the ISMS calendar DOC-ISMS-032 and the management review agenda; CA-03 all 9 risk owners briefed |
| Effectiveness criterion | Next two plan updates approved within 10 working days, checked by internal audit in Q4 2027 |
| CB result | Verified by document review on 2027-06-09 |

| Element | CBF-2027-02, minor *(Example)* |
|---|---|
| Finding | Control A.5.18: 1 of 10 sampled leavers kept access to the support ticketing tool for 9 days |
| Correction | Account disabled on 2027-05-12 during the audit; tool audit log reviewed, no activity after the leaving date |
| Extent check | 11 leavers in 12 months checked across 6 systems with customer data: 2 late removals out of 66 leaver-system pairs (11 x 6 = 66) |
| Root cause | The offboarding checklist listed only systems connected to single sign-on; the ticketing tool and code repository used local accounts |
| Corrective actions | CA-04 connect both tools to single sign-on by 2027-06-30 (brought forward from Q3); CA-05 "systems with local accounts" line added to `isms/offboarding-security-checklist`; CA-06 monthly HR leaver reconciliation from 2027-07-01 |
| CB result | Plan accepted 2027-06-03; implementation to be checked at surveillance 1 |

The second finding is the same story as R-018, AF-2027-002 and MR-D-03:
the internal audit fixed the contractor route, but tools outside single
sign-on were still invisible to the leaver process. Following one risk
through every record would have found it earlier.

## 12. Month 6: findings closure and certification decision

<!-- Guidance: Purpose: show the submission and decision steps. Questions to answer: what deadlines did the CB set, what was sent, when, and with which versions? Pitfall: missing a CB deadline, which can mean repeating Stage 2. Auditor check: the CB's decision maker reviews the response file. -->

The CB's *Example* deadlines were 30 days for the plan (2027-06-11)
and 90 days for evidence of the major (2027-08-10). Quillmere submitted
the plan on 2027-05-26 and the major's evidence on 2027-06-02, both
well inside the limits. The CB verified the major closed on 2027-06-09,
and its independent decision maker, who had not been on the audit team,
granted certification on 2027-06-15. The certificate expires on
2030-06-14 and references the SoA version the CB audited.

The first certification-year CB fees in the *Example* came to USD 8,100
for 5.0 audit days and the annual fee (see `isms/certification-cycle-plan`, section 11; use local currency).
Quillmere then published its certificate under the CB's mark rules
(`isms/certification-mark-usage`, DOC-ISMS-097) and sent it to both
enterprise customers ahead of renewal.

## 13. After the certificate

<!-- Guidance: Purpose: show that certification starts a cycle. Questions to answer: when is surveillance 1, what must be done before it? Pitfall: the project team disbands and records stop. Auditor check: surveillance confirms continued operation. -->

The certification cycle plan (`isms/certification-cycle-plan`, DOC-ISMS-094)
set the next steps *(Example)*:

| Event | Planned date *(Example)* | Why |
|---|---|---|
| CA-04 to CA-06 implemented | 2027-07-01 | Minor nonconformity CBF-2027-02 checked at surveillance 1 |
| R-018 acceptance review | 2027-09-01 | Acceptance ACC-001 expires 2027-09-30; legacy service replacement due Q3 2027 |
| Internal audit cycle 1 | 2028-02-01 | Includes the effectiveness check of CA-01 to CA-03 |
| Management review | 2028-03-20 | Inputs include all certification findings |
| Surveillance 1 | 2028-05-15 to 2028-05-16 | Before 2028-06-15, 12 months from the decision date |
| Surveillance 2 | 2029-05-14 to 2029-05-15 | Surveillance in calendar year 2029 |
| Recertification audit | 2030-03-11 to 2030-03-13 | Decision needed before expiry on 2030-06-14 |

Eight weeks before surveillance 1, the ISMS manager runs
`isms/surveillance-readiness-health-check` (DOC-ISMS-096).

## 14. Lessons learned

<!-- Guidance: Purpose: turn the story into rules you can apply. Questions to answer: which of these apply to us, and where in our plan do we act on them? Pitfall: reading lessons without changing the plan. -->

| Lesson *(Example)* | What Quillmere would do differently | Template that helps |
|---|---|---|
| Approval is part of the risk process | Put risk owner approval and acceptance on the project plan as tasks with dates, not as a side effect of drafting | `compliance/risk-treatment-plan`, `isms/isms-risk-acceptance-record` |
| Follow one risk through every record | Before Stage 1, trace two or three High risks from register to SoA, controls, records, audit and review | `isms/control-evidence-matrix` |
| Fix the class, not the instance | When the internal audit found contractor leavers, check every route out of the leaver process, including tools with local accounts | `compliance/capa-nonconformity` |
| Resource decisions have audit dates | Schedule work that closes a known gap before Stage 2, not after | `compliance/management-review` |
| Cover every management review input | Compare the agenda with clause 9.3.2 before the meeting | `compliance/management-review` |
| Stage 1 silence is not clearance | Self-check every clause before Stage 2 even if Stage 1 did not raise it | `isms/stage-2-audit-evidence-index` |
| Baselines make progress visible | Record a baseline when each objective is set | `compliance/objectives-register` |

## 15. Size tiers: the same story at other sizes

<!-- Guidance: Purpose: show what changes when the organization is larger. These tiers are the library's working tiers, not official definitions; figures are Example values. Auditor check: none. -->

| Step | Small: Quillmere Analytics Ltd *(Example)* | Medium: Quillmere Health Systems *(Example)* | Large or multi-site: Quillmere Group *(Example)* |
|---|---|---|---|
| Profile | 46 staff, one office plus remote staff, SaaS on one public cloud in two regions | 320 staff, two offices and one colocation suite, processor and controller | 2,400 staff, 6 sites in 4 countries, OT and IT, ISO 9001 and ISO 22301 certified |
| Target | Certificate in 6 months | ISO/IEC 27001 in 10 months, ISO/IEC 27701 the year after | Group certificate in 15 months, phased by site |
| Team | Part-time ISMS manager (0.5 FTE) | Full-time ISMS manager plus a 3-person security team | CISO with a 14-person security office, integrated management system |
| Scope extract | One paragraph, four interfaces | Both offices, colocation suite, managed service; privacy roles stated | Group scope with a site list and wave plan (`isms/scope-extension-multisite-plan`) |
| Risk assessment | Team workshops, one register | Register per service with a central roll-up | Site registers including OT, group roll-up to the integrated risk process |
| Internal audit | One external auditor, three days | Internal audit programme over several months | Rolling programme covering every site before certification |
| Management review | Leadership meeting | Security steering committee feeding the review | Integrated review with ISO 9001 and ISO 22301 |
| Typical findings | Missing approvals, one person holding many roles | Different practice between the two offices | Sites at different maturity, OT exceptions |

## 16. Records and evidence

<!-- Guidance: Purpose: list the records each step produced, so you can check your own set. Auditor check: the records exist, are approved and are retrievable. Link to the control evidence matrix. -->

| Step | Record *(Example)* | Owner | Where kept | Retention *(Example)* |
|---|---|---|---|---|
| Decide | Business case DOC-ISMS-029, charter DOC-ISMS-009 | CEO | ISMS repository | 3 years after project close |
| Scope | DOC-ISMS-002 v1.0 and steering minute of 2027-01-29 | ISMS manager | ISMS repository | Current plus superseded for 3 years |
| Risk | DOC-ISMS-016 export, DOC-ISMS-013, acceptance ACC-001 in DOC-ISMS-019 | Risk owners, ISMS manager | GRC folder | 3 years after the risk is closed |
| SoA | DOC-ISMS-011 v1.1 | ISMS manager | ISMS repository | Current plus superseded for 3 years |
| Objectives | DOC-ISMS-024 with monthly results | ISMS manager | ISMS repository | 3 years |
| Internal audit | DOC-ISMS-084 IA-2027-01, DOC-ISMS-086 | Lead auditor, ISMS manager | Audit folder | Certification cycle plus 3 years |
| Management review | DOC-ISMS-085 MR-2027-01 and action log | CEO | ISMS repository | Certification cycle plus 3 years |
| Certification | Stage 1 and 2 reports, DOC-ISMS-093, decision letter, certificate | ISMS manager | Certification folder | Certificate validity plus 3 years |

Map each record to its clause or control in `isms/control-evidence-matrix`
(DOC-ISMS-033) and list it in `isms/isms-documented-information-register`
(DOC-ISMS-028).

## 17. Your own project diary

<!-- Guidance: Purpose: turn the walkthrough into a log of your own project. Fill one row per milestone as it happens, with the record ID and the lesson. Pitfall: writing the diary at the end from memory. Auditor check: none required, but the diary helps answer "how did you get here?" at Stage 2. -->

| Milestone | Planned date | Actual date | Record (ID and version) | Owner | Lesson or issue |
|---|---|---|---|---|---|
| Decision to certify | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-029 [v] | [@sponsor] | [note] |
| Scope approved | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-002 [v] | [@isms-manager] | [note] |
| Risk assessment and treatment plan approved by risk owners | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-016, DOC-ISMS-013 [v] | [@risk-owners] | [note] |
| SoA approved | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-011 [v] | [@isms-manager] | [note] |
| Objectives set with baselines | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-024 [v] | [@isms-manager] | [note] |
| Internal audit report issued | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-084 [ref] | [@lead-auditor] | [note] |
| Management review held | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-085 [ref] | [@ceo] | [note] |
| Stage 1 | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-091, CB report | [@isms-manager] | [note] |
| Stage 2 | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-092, CB report | [@isms-manager] | [note] |
| Findings closed | YYYY-MM-DD | YYYY-MM-DD | DOC-ISMS-093 | [@isms-manager] | [note] |
| Certification decision | YYYY-MM-DD | YYYY-MM-DD | Certificate [number] | CB | [note] |

## 18. References

<!-- Guidance: Cite editions exactly and check for newer editions before use. -->

| Reference | Edition and link | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | https://www.iso.org/standard/82875.html ; Amd 1: https://www.iso.org/standard/88435.html | Requirements followed in the walkthrough |
| ISO/IEC 27002:2022 | https://www.iso.org/standard/75652.html | Control guidance behind the SoA rows |
| ISO/IEC 27005:2022 | https://www.iso.org/standard/80585.html | Risk management guidance behind the risk entry |
| ISO/IEC 17021-1:2015 | https://www.iso.org/standard/61651.html | Certification stages, findings and decision |
| ISO/IEC 27006-1:2024 | https://www.iso.org/standard/82908.html | Audit time and ISMS-specific CB rules |
| ISO 19011:2026 | https://www.iso.org/standard/88984.html | Auditing guidance for the internal audit |

Related templates: `isms/certification-audit-explained` (LRN-ISMS-07),
`isms/isms-business-case` (DOC-ISMS-029), `isms/isms-project-charter`
(DOC-ISMS-009), `compliance/iso-27001-gap-assessment` (DOC-ISMS-098),
`isms/certification-body-selection` (DOC-ISMS-090),
`isms/isms-implementation-roadmap` (DOC-ISMS-030),
`isms/isms-context-interested-parties` (DOC-ISMS-003),
`compliance/ms-scope` (DOC-ISMS-002), `compliance/risk-methodology`
(DOC-ISMS-010), `isms/isms-risk-appetite-criteria` (DOC-ISMS-015),
`compliance/risk-register` (DOC-ISMS-016), `compliance/risk-treatment-plan`
(DOC-ISMS-013), `isms/isms-risk-acceptance-record` (DOC-ISMS-019),
`compliance/statement-of-applicability` (DOC-ISMS-011),
`compliance/objectives-register` (DOC-ISMS-024),
`isms/isms-internal-audit-report` (DOC-ISMS-084),
`isms/audit-findings-register` (DOC-ISMS-086),
`compliance/management-review` (DOC-ISMS-085),
`isms/stage-1-readiness-pack` (DOC-ISMS-091),
`isms/stage-2-audit-evidence-index` (DOC-ISMS-092),
`isms/certification-findings-action-plan` (DOC-ISMS-093),
`isms/certification-cycle-plan` (DOC-ISMS-094),
`isms/control-evidence-matrix` (DOC-ISMS-033).

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 and with the
certification process that ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024
set for certification bodies. The narrative, extracts and lessons are
original; Quillmere Analytics Ltd and every figure, date and ID are
fictional. No ISO or IEC text is reproduced; control labels are short
descriptions, not official titles. Read the official standards (purchase
or licensed access from ISO, IEC or your national standards body) before
relying on any statement here, and check the current edition of each
standard before use. Certification decisions are made only by the
accredited certification body. This is a learning example, not
certification or legal advice. Template licence: MIT.