# Certification Findings Action Plan: [Organization name]

> Action plan for responding to the findings a certification body (CB)
> raises in an ISO/IEC 27001:2022 + Amd 1:2024 audit: Stage 1, Stage 2,
> surveillance, recertification or a special audit. It applies clause
> 10.2 (nonconformity and corrective action) to external findings and
> follows the audit process that ISO/IEC 17021-1:2015 and ISO/IEC
> 27006-1:2024 set for certification bodies. It records each finding,
> the correction, the root cause, the corrective action, the evidence
> sent to the CB, the deadlines the CB set and the verification result.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it from the closing meeting of any certification audit until the
  CB confirms that every nonconformity is closed. Open one plan per
  audit (for example "Stage 2, 2027-05") and keep it with the audit
  report.
- Fill first: the audit details in Document control, the findings log
  (section 4) copied word for word from the CB's report, and the
  deadlines the CB stated in writing (section 3). Then work each major
  finding before the minors.
- Main pitfall: sending a correction ("we fixed the missing review")
  without a root cause and a corrective action that stops it happening
  again. CBs reject these responses, and a rejected response for a major
  nonconformity delays the certification decision.
- Grading belongs to the CB. Discuss a grade at the closing meeting or
  through the CB's documented clarification or appeal process, never by
  ignoring the deadline.
- Related templates: `isms/audit-findings-register` (all findings from
  all sources), `compliance/capa-nonconformity` (one record per
  nonconformity), `isms/stage-2-audit-evidence-index`,
  `isms/certification-cycle-plan`, `isms/surveillance-readiness-health-check`,
  `isms/certification-body-selection`, `isms/control-evidence-matrix`,
  `isms/certification-audit-explained` (how the audit works).
-->

## Document control

<!-- Guidance: One plan per CB audit. The Document ID is the library's type ID; add the audit reference to tell plans apart. Status moves to Closed only when the CB confirms closure in writing. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-093 [audit reference, e.g. DOC-ISMS-093-2027-S2] |
| Version | [1.0] |
| Status | [Draft / Submitted to CB / Accepted by CB / Closed] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ceo or top management sponsor], [@ciso], [@process-owners] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (clause 10.2); CB process per ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024 |
| Certification body | [CB name], accreditation body [name] (signatory of the Global ACI MRA, formerly the IAF MLA), accreditation number [n] |
| Audit type and dates | [Stage 1 / Stage 2 / Surveillance 1 / Surveillance 2 / Recertification / Special], YYYY-MM-DD to YYYY-MM-DD |
| CB audit report reference | [report number, date received] |
| ISMS scope reference | DOC-ISMS-002 [version] |
| SoA reference | DOC-ISMS-011 [version cited by the CB] |
| Next scheduled review | [Weekly until closed, then at the next surveillance] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| Top management sponsor | [@ceo] | [Approved for submission] | YYYY-MM-DD |
| Process owners of affected controls | [@owners] | [Agreed actions and dates] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 *(Example)* | 2027-05-13 | [@isms-manager] | Findings copied from the closing meeting summary |
| 1.0 *(Example)* | 2027-05-26 | [@isms-manager] | Corrections, root causes and corrective action plan submitted to the CB |
| 1.1 *(Example)* | 2027-06-09 | [@isms-manager] | CB verified closure of the major nonconformity |
| [x.y] | YYYY-MM-DD | [@author] | [Change] |

## Contents

<!-- Guidance: Sections 1 to 3 set the rules, 4 to 8 are the working record the CB sees, 9 to 12 keep it controlled. -->

1. Purpose and scope
2. Finding types and what each needs
3. Roles and deadlines
4. Findings log
5. Response method
6. Worked responses
7. Submission log
8. Verification and closure
9. Escalation, clarification and appeal
10. Size tiers
11. Records and evidence
12. References

## 1. Purpose and scope

<!-- Guidance: Name the audit, the CB and the scope this plan covers. Questions to answer: which audit raised the findings, which certificate (or certification decision) depends on them, and who signs the response? Auditor check: the response is approved by management, not sent by one person on their own. -->

This plan records how [Organization name] responds to the findings
raised by [CB name] during the [audit type] audit of the ISMS defined in
DOC-ISMS-002, held on [dates]. It exists to:

- keep every finding, from every auditor, in one controlled list that
  matches the CB report;
- make sure each nonconformity gets a correction, a root cause, a
  corrective action and evidence, in the format and by the dates the CB
  set;
- give top management a single view of what blocks the certification
  decision or threatens the existing certificate;
- feed the internal corrective action process (clause 10.2), the audit
  findings register and the next management review (clause 9.3).

The plan covers findings in the CB report only. Findings from internal
audits, customer audits and incidents go to `isms/audit-findings-register`
and `compliance/capa-nonconformity`. When an external finding repeats an
internal one, link both records so the CB can see that the internal
process failed to close it, and treat that as part of the root cause.

## 2. Finding types and what each needs

<!-- Guidance: Use the CB's own terms from its report and its certification rules. Do not regrade a finding in this plan. Pitfall: treating opportunities for improvement as optional forever; the CB will ask what was done with them at the next audit. -->

Certification bodies grade findings under ISO/IEC 17021-1:2015 and their
own published rules. The labels below are the common ones; copy the
exact terms your CB uses.

| Grade | What it usually means | What the CB usually expects | Effect on certification |
|---|---|---|---|
| Major nonconformity | A serious gap: something the standard needs is absent, or broken badly enough that the auditor can no longer rely on the ISMS working | Correction, root cause analysis, corrective action plan, and evidence of implementation that the CB verifies (document review or follow-up visit) | Blocks an initial or recertification decision until verified; at surveillance it can lead to suspension if not resolved in time |
| Minor nonconformity | A one-off lapse or partial gap; the ISMS as a whole still works | Correction, root cause analysis and corrective action plan accepted by the CB; implementation checked at the next audit | Plan must be accepted before the decision; repeated or unresolved minors can be raised to major |
| Opportunity for improvement (OFI) or observation | Not a nonconformity; a weakness or a risk of a future nonconformity | No formal response required by most CBs; record a decision (adopt, adapt or decline with a reason) | None directly; the CB may follow it up |
| Stage 1 concern or area of concern | Issue found in Stage 1 that could be graded as a nonconformity in Stage 2 | Resolve before Stage 2; the CB reviews it at Stage 2 | Unresolved concerns often become Stage 2 nonconformities |

Each nonconformity needs four distinct elements. Do not merge them.

1. **Correction**: action to remove the detected nonconformity itself,
   for example performing the missed access review now.
2. **Extent check**: a search for other instances of the same problem in
   other systems, sites or periods, so the correction is complete.
3. **Root cause**: why the management system allowed the nonconformity,
   stated as a cause the organization can change.
4. **Corrective action**: change to the system that removes the root
   cause, with an owner, a due date and a measurable effectiveness
   criterion.

Clause 10.2 also asks the organization to review whether similar
nonconformities exist or could occur, to review the effectiveness of the
action, to update risks and opportunities if needed, to change the ISMS
if needed, and to keep documented information on all of it. The response
method in section 5 covers each of these points.

## 3. Roles and deadlines

<!-- Guidance: Record the deadlines exactly as the CB wrote them, with the source (report page, e-mail, certification agreement clause). The day counts below are Example values. Auditor check: dates in the submission log match these deadlines. -->

### 3.1 Roles

| Activity | ISMS manager | Process owner | Top management | CB lead auditor |
|---|---|---|---|---|
| Confirm the wording and grade of findings at the closing meeting | R | C | A | R |
| Copy findings into the log and assign owners | R, A | I | I | |
| Correction and extent check | C | R, A | I | |
| Root cause analysis | R (facilitates) | R | A | |
| Corrective action plan and dates | R | R | A | |
| Submit response to the CB | R | C | A | I |
| Review and accept the response | I | I | I | R, A |
| Verify implementation (major findings) | C | C | I | R, A |
| Internal effectiveness review | R | C | A | |

R responsible, A accountable, C consulted, I informed.

### 3.2 Deadlines set by the CB

| Item | Deadline rule in the CB's documents | Due date for this audit | Source |
|---|---|---|---|
| Correction and corrective action plan for all nonconformities | *Example*: within 30 days of the last audit day, as set by the CB | *Example*: 2027-06-11 | [Certification rules section n / audit report page n] |
| Evidence of implementation for major nonconformities | *Example*: within 90 days of the last audit day, as set by the CB | *Example*: 2027-08-10 | [source] |
| CB verification of major nonconformities | *Example*: off-site document review, or a follow-up visit if the CB decides | [date booked] | [source] |
| Implementation of minor corrective actions | *Example*: before the next surveillance audit, checked by the CB on site | *Example*: before 2028-05-15 | [source] |

ISO/IEC 17021-1:2015 places an outer limit on initial certification:
if the CB cannot verify the corrections and corrective actions for every
major nonconformity within six months after the last day of Stage 2, it
must conduct another Stage 2 before recommending certification (as
explained in European co-operation for Accreditation (EA) guidance on the
standard; confirm the period in your CB's rules). The CB's own deadlines
are usually much shorter. Plan to the CB's dates, not to the outer limit.

## 4. Findings log

<!-- Guidance: One row per finding, in the CB's numbering, with the requirement and the CB's wording copied exactly. Pitfall: paraphrasing the finding so that the response answers a different problem from the one the auditor raised. -->

| Finding ID | CB ref | Grade | Requirement | Finding as written by the CB (summary of evidence) | Owner | Status |
|---|---|---|---|---|---|---|
| CBF-2027-01 *(Example)* | NC-01 | Major | Clause 6.1.3 (risk owner approval of the treatment plan and acceptance of residual risk) | No record that risk owners approved the risk treatment plan or accepted residual risks; plan DOC-ISMS-013 v0.9 unsigned, 14 High risks with no acceptance record | [@isms-manager] | Closed (CB verified 2027-06-09) |
| CBF-2027-02 *(Example)* | NC-02 | Minor | Control A.5.18 (access rights review and removal) | 1 of 10 sampled leavers kept access to the support ticketing tool for 9 days after the leaving date | [@it-lead] | Plan accepted, action implemented, awaiting surveillance |
| CBF-2027-03 *(Example)* | NC-03 | Minor | Control A.5.19 (supplier relationship security) | Supplier register DOC-ISMS-066 omits 2 SaaS tools that process customer data | [@procurement-lead] | Plan accepted, in progress |
| CBF-2027-04 *(Example)* | NC-04 | Minor | Clause 7.2 (evidence of competence) | No competence evidence for 2 of 8 engineers on the production on-call rota | [@head-eng-ops] | Plan accepted, in progress |
| CBF-2027-05 *(Example)* | OFI-01 | OFI | Clause 9.1 | Metrics report lists measures but not the target for each | [@isms-manager] | Adopted, see CI-2027-07 |
| CBF-2027-06 *(Example)* | OFI-02 | OFI | Control A.8.16 | Alert triage notes are kept in chat threads, which are hard to retrieve | [@security-lead] | Adopted |
| CBF-2027-07 *(Example)* | OFI-03 | OFI | Control A.5.7 | Threat intelligence inputs are not linked to risk register updates | [@security-lead] | Adapted |
| CBF-2027-08 *(Example)* | OFI-04 | OFI | Clause 7.4 | Communication plan does not say who talks to customers after an incident | [@isms-manager] | Declined: covered by DOC-ISMS-078 crisis communications plan, reference added to DOC-ISMS-027 |
| [CBF-YYYY-NN] | [ref] | [grade] | [clause or control] | [finding] | [@owner] | [status] |

*Example* summary for this audit: 8 findings in total, 1 major, 3 minor,
4 OFIs. All 4 nonconformities must have accepted responses before the
certification decision, and the major one must also be verified.

## 5. Response method

<!-- Guidance: Work each nonconformity through the same steps so the CB sees a consistent quality of response. Questions to answer: what exactly was wrong, how far does it go, why did the system allow it, what changes, and how will we know the change worked? Auditor check: the root cause explains every instance found in the extent check. -->

```mermaid
flowchart TD
  A["Finding raised at closing meeting"] --> B["Copy wording and grade into findings log"]
  B --> C["Correction: fix the detected instance"]
  C --> D["Extent check: other systems, sites, periods"]
  D --> E["Root cause analysis"]
  E --> F["Corrective action plan with owner, date, effectiveness criterion"]
  F --> G["Management approval"]
  G --> H["Submit response to CB by the CB deadline"]
  H --> I{"CB accepts response?"}
  I -- "No" --> E
  I -- "Yes" --> J{"Major nonconformity?"}
  J -- "Yes" --> K["Submit implementation evidence, CB verifies"]
  J -- "No" --> L["Implement before next audit"]
  K --> M["Internal effectiveness review"]
  L --> M
  M --> N["Close in findings log and audit findings register"]
```

### 5.1 Correction and extent check

Correct the instance the auditor found first: it shows control and
reduces risk at once. Then search for the same problem elsewhere. Define
the search before running it: which population (all leavers in the last
12 months, all suppliers, all on-call engineers), which source (HR
system, finance records, rota), and who ran it. Record the result even
when nothing else is found, because "no other instances" is a statement
the CB may test.

### 5.2 Root cause analysis

Use a method proportionate to the grade. For minors, five whys is usually
enough. For majors, combine five whys with a cause categories review
(process, people and competence, tools, information, management
oversight, supplier). A useful root cause:

- names something in the management system (a process step, a control
  design, an ownership gap, a missing trigger, a tool limitation);
- explains every instance found in the extent check;
- is something the organization can change.

Reject these as root causes: "human error", "oversight", "lack of time",
"the employee did not follow the procedure". They describe what happened,
not why the system allowed it. Ask the next "why".

### 5.3 Corrective action and effectiveness criterion

Each corrective action needs an owner, a due date that respects the CB
deadline, the evidence that will prove implementation, and an
effectiveness criterion stated in advance (for example "next two
quarterly access reviews complete on time with zero leavers holding
access after day 1"). Where the root cause touches risk, update the risk
register (`compliance/risk-register`); where it touches a control
decision, update the SoA (`compliance/statement-of-applicability`); where
it touches a document, raise a change under the documented information
process (DOC-ISMS-028).

### 5.4 Response quality checklist

Before management approves a response, confirm:

- [ ] The finding wording matches the CB report exactly.
- [ ] The correction is complete and evidenced with dated records.
- [ ] The extent check population, source and result are stated.
- [ ] The root cause passes the three tests in 5.2.
- [ ] Each corrective action addresses the root cause, not only the symptom.
- [ ] Owners and dates are realistic and inside the CB deadline.
- [ ] Effectiveness criteria are measurable.
- [ ] Risk register, SoA and documents are updated where affected.
- [ ] Evidence files are named, dated and free of unnecessary personal data.

## 6. Worked responses

<!-- Guidance: Show one major and one minor in full so owners can copy the depth. Replace the Example rows with your own. Pitfall: evidence lists that name a document but not the version or date. -->

### 6.1 CBF-2027-01, major *(Example)*

| Element | Response |
|---|---|
| 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 in 14 DOC-ISMS-019 acceptance records (among them ACC-003 and ACC-005) on 2027-05-21 |
| Extent check | All 62 risks in DOC-ISMS-016 checked for owner and acceptance status: 14 High lacked acceptance (the finding); 48 Low and Medium had acceptance recorded in the register at the DOC-ISMS-010 authority (risk owner for Low, risk owner plus department head for Medium); 0 Critical risks open. 14 + 48 = 62 |
| Root cause | The risk treatment procedure described the approval step but did not assign who triggers it or when; the project plan ended the risk work at "plan drafted", so approval never became a task |
| Corrective actions | CA-01: add an approval step with a named trigger (ISMS manager, within 10 working days of plan update) to DOC-ISMS-010, owner [@isms-manager], due 2027-05-28. CA-02: add "risk owner approval and acceptance" as a fixed item in the ISMS annual calendar DOC-ISMS-032 and in the management review agenda, due 2027-05-28. CA-03: brief all 9 risk owners on acceptance duties, due 2027-06-02 |
| Effectiveness criterion | Next two plan updates approved within 10 working days, checked by internal audit in Q4 2027 |
| Evidence sent | DOC-ISMS-013 v1.0 signed, the 14 DOC-ISMS-019 acceptance records (among them ACC-003 and ACC-005), DOC-ISMS-010 v1.3, calendar extract, briefing attendance record |
| CB result | Verified by document review on 2027-06-09 |

### 6.2 CBF-2027-02, minor *(Example)*

| Element | Response |
|---|---|
| Finding | Control A.5.18: 1 of 10 sampled leavers kept ticketing tool access 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 | All 11 leavers in the last 12 months checked across the 6 systems with customer data: 1 further late removal (code repository, 3 days, no activity). Total 2 late removals out of 66 leaver-system pairs (11 x 6 = 66) |
| Root cause | The offboarding checklist listed systems connected to single sign-on only; the ticketing tool and code repository used local accounts and were not on the checklist |
| Corrective actions | CA-04: connect both tools to single sign-on, due 2027-06-30. CA-05: add a "systems with local accounts" line to the offboarding checklist (`isms/offboarding-security-checklist`), due 2027-06-04. CA-06: add a monthly comparison of HR leavers against active accounts, due 2027-07-01 |
| Effectiveness criterion | Zero leavers with access after the leaving date in the next two quarterly reviews |
| Evidence to be checked | SSO configuration record, checklist v2.0, monthly comparison reports from July 2027 |
| CB result | Plan accepted 2027-06-03; implementation to be checked at surveillance 1 |

## 7. Submission log

<!-- Guidance: Every exchange with the CB about findings goes here: what was sent, when, how, and the CB's answer. Auditor check: the dates prove deadlines were met. Pitfall: sending evidence in scattered e-mails with no index. -->

| Submission ID | Date sent | Findings covered | Content | Channel | CB response | Response date |
|---|---|---|---|---|---|---|
| SUB-2027-01 *(Example)* | 2027-05-26 | CBF-2027-01 to 04 | Corrections, root causes, corrective action plan (this plan v1.0) | CB client portal | Plan accepted for minors; major needs implementation evidence | 2027-06-03 |
| SUB-2027-02 *(Example)* | 2027-06-02 | CBF-2027-01 | Implementation evidence, 5 files listed in 6.1 | CB client portal | Major verified and closed | 2027-06-09 |
| SUB-2027-03 *(Example)* | 2027-06-10 | CBF-2027-05 to 08 | OFI decisions (for information) | E-mail to lead auditor | Acknowledged | 2027-06-11 |
| [SUB-YYYY-NN] | YYYY-MM-DD | [IDs] | [content] | [channel] | [response] | YYYY-MM-DD |

Both submission deadlines in the *Example* were met: the plan was sent on
2027-05-26 against a 2027-06-11 deadline, and the major evidence on
2027-06-02 against a 2027-08-10 deadline. In the *Example*, the CB's
certification decision followed on 2027-06-15.

## 8. Verification and closure

<!-- Guidance: Closure has three layers: CB acceptance, CB verification where required, and your own effectiveness review. Keep each date. Pitfall: closing the internal record when the CB accepts the plan, before the action is implemented. -->

A finding moves through these states. Record the date of each change in
the findings log.

```mermaid
stateDiagram-v2
  [*] --> Raised
  Raised --> ResponseDrafted
  ResponseDrafted --> Submitted
  Submitted --> ResponseDrafted : CB rejects
  Submitted --> Accepted : CB accepts plan
  Accepted --> Implemented
  Implemented --> CBVerified : major, CB verifies
  Implemented --> EffectivenessReviewed : minor
  CBVerified --> EffectivenessReviewed
  EffectivenessReviewed --> Closed
  EffectivenessReviewed --> ResponseDrafted : action not effective
  Closed --> [*]
```

- **CB acceptance**: the CB accepts the correction, root cause and plan.
  For minors this is usually enough for the certification decision.
- **CB verification**: for majors, the CB checks implementation evidence
  or visits. Keep the verification statement or report.
- **Internal effectiveness review**: after the effectiveness period,
  the ISMS manager or internal audit checks the criterion. If it fails,
  reopen the finding, repeat the root cause analysis and tell the CB
  before the next audit.
- **Next audit check**: at the next surveillance the CB reviews the
  actions taken on previous nonconformities. Prepare a one-page status
  for each in `isms/surveillance-readiness-health-check`.

## 9. Escalation, clarification and appeal

<!-- Guidance: Decide in advance who escalates and when. Questions to answer: what happens if an action will miss the CB deadline, and how do we raise a disagreement? Auditor check: no deadline passed silently. -->

| Trigger | Action | Who | Time limit |
|---|---|---|---|
| Action at risk of missing a CB deadline | Tell top management; ask the CB in writing for an extension with reasons, before the deadline | ISMS manager | As soon as the risk is known |
| Disagreement with the facts in a finding | Raise at the closing meeting; afterwards, write to the lead auditor with evidence | ISMS manager | *Example*: within 5 working days of the report, per CB rules |
| Disagreement with the grade or a decision | Use the CB's documented appeal process (ISO/IEC 17021-1 requires CBs to have one) | Top management | Per CB rules |
| Complaint about audit conduct | Use the CB's complaints process | Top management | Per CB rules |
| Finding reveals a significant risk | Escalate to the risk owner and treat under the risk process at once, without waiting for the CB response | Risk owner | Immediately |

Keep every escalation in the submission log. An unanswered extension
request is not an extension.

## 10. Size tiers

<!-- Guidance: The process is the same at every size; the volume, the number of owners and the tooling change. These tiers are the library's working tiers, not official definitions. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large or multi-site: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Who runs the plan | Part-time ISMS manager (0.5 FTE, Head of Engineering Operations) | Full-time ISMS manager with a 3-person security team | CISO office (14 people) with a site ISMS coordinator per site |
| Typical volume *(Example)* | 4 nonconformities, 4 OFIs at Stage 2 | 6 to 10 nonconformities across 3 locations | Findings per site and per phase; one plan per audit with a site column |
| Tooling | This document plus a shared evidence folder | Ticketing tool with a finding type, linked to this plan | Integrated management system tool shared with ISO 9001 and ISO 22301 findings |
| Approval | CEO approves the response | ISMS steering committee approves | Group management approves; site managers approve site actions |
| Specific pitfall | One person writes all responses with no owner input | Actions spread across teams miss the CB date | A finding at one site has the same root cause at others; the extent check must cover all sites in scope |

## 11. Records and evidence

<!-- Guidance: List the records that prove this plan operates and where they live. Link them in the control evidence matrix. Pitfall: evidence kept only in the CB portal, which you may lose access to if you change CB. -->

| Record | Owner | Location | Retention *(Example)* |
|---|---|---|---|
| CB audit report and closing meeting summary | ISMS manager | ISMS evidence library, audit folder | Current cycle plus one full cycle |
| This action plan, all versions | ISMS manager | Documented information system (DOC-ISMS-028) | Current cycle plus one full cycle |
| Correction and corrective action evidence | Process owners | Evidence library, linked from section 6 | Current cycle plus one full cycle |
| Submission log and CB responses | ISMS manager | This plan, section 7, with copies of messages | Current cycle plus one full cycle |
| CB verification statements | ISMS manager | Audit folder | Current cycle plus one full cycle |
| Nonconformity records | Process owners | `compliance/capa-nonconformity` records, one per nonconformity | Per DOC-ISMS-028 |
| Management review input on findings | ISMS manager | Management review minutes (DOC-ISMS-085) | Per DOC-ISMS-028 |

Map each record in `isms/control-evidence-matrix` (DOC-ISMS-033) under
clause 10.2 and, for findings against controls, under the control
concerned. Under clause 10.2 an auditor will want to see, for each
finding, what went wrong, what you did about it and whether the fix
worked; this plan and the linked records give that trail for external
findings.

## 12. References

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

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | https://www.iso.org/standard/82875.html ; Amd 1: https://www.iso.org/standard/88435.html | Clause 10.2 and the controls named in findings |
| ISO/IEC 17021-1:2015 | https://www.iso.org/standard/61651.html | How CBs grade findings, accept corrective actions and decide on certification |
| ISO/IEC 27006-1:2024 | https://www.iso.org/standard/82908.html | ISMS-specific requirements for CBs |
| ISO/IEC 27007:2020 | https://www.iso.org/standard/77802.html | ISMS auditing guidance (under revision; check for a newer edition) |
| ISO 19011:2026 | https://www.iso.org/standard/88984.html | General guidance on auditing management systems |
| Your CB's certification rules and agreement | Current version | Deadlines, grading terms, appeal process |

Related templates: `isms/audit-findings-register` (DOC-ISMS-086),
`compliance/capa-nonconformity` (DOC-ISMS-087),
`isms/stage-1-readiness-pack` (DOC-ISMS-091),
`isms/stage-2-audit-evidence-index` (DOC-ISMS-092),
`isms/certification-cycle-plan` (DOC-ISMS-094),
`isms/surveillance-readiness-health-check` (DOC-ISMS-096),
`isms/continual-improvement-register` (DOC-ISMS-088),
`compliance/risk-register` (DOC-ISMS-016),
`compliance/management-review` (DOC-ISMS-085).

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 clause 10.2 and
with the certification audit process in ISO/IEC 17021-1:2015 and ISO/IEC
27006-1:2024. The text, grading descriptions, examples and guidance are
original. No ISO or IEC text is reproduced; read the official standards
(purchase or licensed access from ISO, IEC or your national standards
body) and your certification body's rules before relying on any
statement here. Check the current edition of each standard and your CB's
current deadlines before use. Certification decisions are made only by
the accredited certification body. This is a documentation format, not
certification or legal advice. Template licence: MIT.