# Information Security Risk Assessment Report: [Organization name], [Cycle YYYY-N]

> The report of one information security risk assessment cycle: what
> was assessed, how, by whom, what the results are by risk band, which
> risks matter most, what changed since the last cycle, and which
> treatment and acceptance decisions are handed on. It is the dated
> record of risk assessment results that ISO/IEC 27001:2022 + Amd 1:2024
> clause 8.2 expects the organization to retain, produced with the
> method in DOC-ISMS-010 (clause 6.1.2) and feeding the risk treatment
> plan DOC-ISMS-013 (clauses 6.1.3 and 8.3). Guidance from ISO/IEC
> 27005:2022. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- When to use: once per planned cycle (usually annual) and for each
  significant targeted assessment (new system, merger, major
  incident). Each report is a dated, approved record; never overwrite
  the previous one.
- Fill first: section 2 (scope of this cycle) and section 3 (method
  references), then export the counts in sections 6 and 7 from the
  risk register snapshot so the numbers match exactly.
- Main pitfall: a report whose totals do not match the register, or a
  heat map that disagrees with the top risk table. Auditors recompute.
  Generate the counts from the register, then check that every band
  total, heat map row and treatment count adds up to the same number
  of risks.
- The worked example uses Quillmere Health Systems (medium tier,
  320 staff) and its second assessment cycle.
- Related templates: `compliance/risk-methodology` (DOC-ISMS-010),
  `isms/isms-risk-appetite-criteria` (DOC-ISMS-015),
  `compliance/risk-register` (DOC-ISMS-016),
  `isms/isms-threat-vulnerability-catalogue` (DOC-ISMS-018),
  `compliance/risk-treatment-plan` (DOC-ISMS-013),
  `isms/isms-risk-acceptance-record` (DOC-ISMS-019),
  `compliance/statement-of-applicability` (DOC-ISMS-011),
  `compliance/management-review` (DOC-ISMS-085).
-->

## Document control

<!-- Guidance: One report per cycle. Keep the register snapshot date in the control table so anyone can reproduce the counts. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-017 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Approvers/reviewers | [@ceo], [@ciso], [@risk-owners], [@internal-audit] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.1.2, 8.2); ISO/IEC 27005:2022 |
| Assessment cycle | [2027-1, annual cycle] |
| Assessment period | [YYYY-MM-DD to YYYY-MM-DD] |
| Method | DOC-ISMS-010 version [x.y] |
| Criteria | DOC-ISMS-015 version [x.y] |
| Catalogue | DOC-ISMS-018 version [x.y] |
| Register snapshot | DOC-ISMS-016 exported YYYY-MM-DD |
| Previous report | DOC-ISMS-017 version [x.y], cycle [2026-1] |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager (author) | [@isms-manager] | [Prepared] | YYYY-MM-DD |
| CISO or security lead | [@ciso] | [Reviewed] | YYYY-MM-DD |
| Top management | [@ceo] | [Approved; residual risks in section 11 referred to acceptance] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.9 *(Example)* | 2027-03-03 | [@isms-manager] | Draft for risk owner validation |
| 1.0 *(Example)* | 2027-03-15 | [@isms-manager] | Approved by top management |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Executive summary](#1-executive-summary)
- [2. Scope and context of this cycle](#2-scope-and-context-of-this-cycle)
- [3. Method and criteria](#3-method-and-criteria)
- [4. Participants and schedule](#4-participants-and-schedule)
- [5. Assets and scenarios assessed](#5-assets-and-scenarios-assessed)
- [6. Results summary by band](#6-results-summary-by-band)
- [7. Heat maps](#7-heat-maps)
- [8. Top risks](#8-top-risks)
- [9. Changes since the last cycle](#9-changes-since-the-last-cycle)
- [10. Treatment decisions handed to the risk treatment plan](#10-treatment-decisions-handed-to-the-risk-treatment-plan)
- [11. Risks referred for acceptance](#11-risks-referred-for-acceptance)
- [12. Limitations and assumptions](#12-limitations-and-assumptions)
- [13. Size tiers](#13-size-tiers)
- [14. Records and evidence](#14-records-and-evidence)
- [15. References](#15-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Executive summary

<!-- Guidance: Write this last, for top management. Five to eight sentences: how many risks, how many above appetite, the three to five that matter most, what is being done, what management must decide. Avoid technical detail. -->

*Example (Quillmere Health Systems, cycle 2027-1):* The 2027 annual
assessment covered the whole ISMS scope: clinical scheduling software,
the managed scheduling service, two offices and the colocation suite.
Forty-two risks were assessed against the approved criteria. With
existing controls, 3 risks are Critical, 14 High, 17 Medium and 8 Low.
Twenty-four risks are outside appetite: all Critical and High risks
and 7 Medium risks in Averse categories. The three Critical risks are
ransomware affecting the managed service (R-006), credential phishing
leading to access to the scheduling database (R-001) and exploitation
of the new hospital integration interface (R-039). Treatment is planned
for 26 risks, which would leave no Critical risk and 4 High risks once
the plan is complete. Top management is asked to approve the treatment
plan and to decide on the acceptance of the 4 High residual risks
and the 2 Medium residual risks in Averse categories listed in
section 11.

| Key figure *(Example)* | Value |
|---|---|
| Risks assessed | 42 (38 last cycle) |
| Outside appetite (current) | 24 (3 Critical, 14 High, 7 Medium in Averse categories) |
| Risks to be treated | 26 (23 modify, 2 share, 1 avoid) |
| Expected residual after treatment | 0 Critical, 4 High, 20 Medium, 18 Low |
| Decisions requested | Approve DOC-ISMS-013 update; decide on 6 residual acceptances (4 High, 2 Medium in Averse categories) |

## 2. Scope and context of this cycle

<!-- Guidance: State what was in and out of this cycle and why. If the cycle covered only part of the ISMS scope, say which parts are covered by which earlier report, so the whole scope is assessed within the planned interval. -->

| Item | Value *(Example)* |
|---|---|
| ISMS scope | DOC-ISMS-002 version 1.2: development and operation of clinical scheduling software and the managed scheduling service |
| Covered in this cycle | Whole ISMS scope |
| Not covered | None; the planned ISO/IEC 27701 privacy extension will be assessed in a separate privacy risk cycle |
| Type | Planned annual cycle (clause 8.2 planned interval) |
| Context changes considered | New hospital integration interface (go-live 2027-02); second office opened; colocation contract renewed; new data protection obligations recorded in DOC-ISMS-014 |
| Climate consideration | Flood exposure of the colocation suite reviewed per DOC-ISMS-003 (clause 4.1 as amended in 2024) |
| Interested party requirements | Hospital customer contracts (security schedules, breach notification), regulator guidance recorded in DOC-ISMS-003 |

## 3. Method and criteria

<!-- Guidance: Reference the method and criteria by ID and version rather than repeating them. Record any deviation from the method and why; an undisclosed deviation makes results incomparable with the previous cycle. -->

| Element | Reference | Notes *(Example)* |
|---|---|---|
| Method | DOC-ISMS-010 version 3.0 | Event-based approach for the whole scope; asset-based for the scheduling platform and the integration interface |
| Risk criteria and appetite | DOC-ISMS-015 version 1.0 | 5 x 5 scale; bands Low 1 to 4, Medium 5 to 9, High 10 to 16, Critical 17 to 25 (in practice 20 and 25) |
| Scenario source | DOC-ISMS-018 version 1.1 | 36 scenarios built from catalogue entries; 6 needed new entries |
| Existing controls | DOC-ISMS-011 version 1.3 | Current scores take existing controls into account |
| Deviations from method | None | [Describe any deviation and its approval] |

Scoring conventions used in this report:

- **Current score**: likelihood x impact with existing controls, as
  defined in DOC-ISMS-010 (called inherent in the register).
- **Target residual score**: expected score once the treatment in
  DOC-ISMS-013 is implemented.
- Ranking: by current score, then by impact for ties.

## 4. Participants and schedule

<!-- Guidance: Show who contributed, in which role, so the auditor sees that risk owners took part and did not just receive a spreadsheet. -->

| Participant | Role in the assessment *(Example)* | Sessions |
|---|---|---|
| ISMS manager | Facilitator, method owner, author | All |
| Security team (3) | Technical analysis, threat input | All |
| Head of Engineering | Risk owner: platform and integration | Workshops 1, 2 |
| Head of Service Operations | Risk owner: managed service and colocation | Workshops 2, 3 |
| Chief Financial Officer | Risk owner: finance and suppliers | Workshop 3 |
| HR Director | Risk owner: people risks | Workshop 3 |
| Data Protection Officer | Privacy and legal input | Workshops 1, 3 |
| Clinical safety officer | Patient safety impact | Workshop 1 |
| Internal audit | Observer for method consistency | Workshop 2 |

```mermaid
gantt
  title Risk assessment cycle 2027-1 (Example)
  dateFormat YYYY-MM-DD
  section Prepare
  Plan scope and inputs :plan, 2027-01-11, 10d
  section Assess
  Workshops 1 to 3 :work, 2027-01-25, 21d
  Scoring and validation with owners :score, 2027-02-15, 10d
  section Report
  Draft report :draft, 2027-03-01, 3d
  Approval by top management :appr, 2027-03-08, 8d
```

## 5. Assets and scenarios assessed

<!-- Guidance: Summarise what was covered. Link to the asset inventory and the catalogue by ID; list full scenarios in the register, not here. -->

| Asset or process group *(Example)* | Assets in DOC-ISMS-012 | Scenarios |
|---|---|---|
| Clinical scheduling platform (production) | 9 | 11 |
| Hospital integration interface | 3 | 5 |
| Corporate IT and SaaS suite | 6 | 8 |
| Colocation suite and offices | 4 | 6 |
| Suppliers and cloud services | 5 | 6 |
| People and processes | 3 | 6 |
| **Total** | **30** | **42** |

| Risks by category (DOC-ISMS-015 section 3) *(Example)* | Appetite | Count |
|---|---|---|
| Confidentiality of customer and personal data | Averse | 11 |
| Integrity of customer-facing data and results (including patient safety impact) | Averse | 6 |
| Availability of core services | Cautious | 7 |
| Supplier and cloud dependency | Cautious | 8 |
| People and insider risk | Cautious | 3 |
| Physical and environmental, including climate-related disruption | Cautious | 4 |
| Legal, regulatory and contractual compliance | Averse | 2 |
| Fraud (optional category added to DOC-ISMS-015) | Averse | 1 |
| **Total** | | **42** |

New catalogue entries proposed in this cycle (sent to DOC-ISMS-018):
abuse of the integration interface by a compromised hospital account,
misrouting of appointment messages, and dependence on one interface
engine supplier. *(Example)*

## 6. Results summary by band

<!-- Guidance: Give counts by band for current and target residual scores. Each column must total the number of risks assessed. -->

| Band | Score | Current *(Example)* | Target residual *(Example)* | Previous cycle current *(Example)* |
|---|---|---|---|---|
| Critical | 17 to 25 (in practice 20 and 25) | 3 | 0 | 5 |
| High | 10 to 16 | 14 | 4 | 15 |
| Medium | 5 to 9 | 17 | 20 | 12 |
| Low | 1 to 4 | 8 | 18 | 6 |
| **Total** | | **42** | **42** | **38** |

```mermaid
pie title Current risk distribution, cycle 2027-1 (Example)
  "Critical" : 3
  "High" : 14
  "Medium" : 17
  "Low" : 8
```

Outside appetite: 24 risks. All 3 Critical and 14 High risks are
outside appetite because their categories are Averse or Cautious in
DOC-ISMS-015 (no High risk falls in an Open category this cycle). In
addition, 7 Medium risks sit in Averse categories (confidentiality of
customer and personal data, integrity of customer-facing data, legal
compliance, fraud); all 7 are treated (Modify row in section 10). One
Cautious Medium risk (R-004, support supplier outage) is also modified
to improve resilience, one Cautious Medium risk (R-002) is shared, and
the 8 retained Medium risks are in Cautious categories and within
tolerance. *(Example)*

## 7. Heat maps

<!-- Guidance: Rows are likelihood, columns impact; cells hold counts. Row totals and band totals must agree with section 6. A table renders everywhere and exports cleanly. -->

### 7.1 Current (with existing controls) *(Example)*

| Likelihood / Impact | 1 | 2 | 3 | 4 | 5 | Row total |
|---|---|---|---|---|---|---|
| 5 | 0 | 0 | 0 | 1 | 0 | 1 |
| 4 | 0 | 0 | 3 | 2 | 2 | 7 |
| 3 | 0 | 2 | 5 | 6 | 1 | 14 |
| 2 | 0 | 3 | 4 | 6 | 2 | 15 |
| 1 | 0 | 0 | 2 | 3 | 0 | 5 |
| **Total** | 0 | 5 | 14 | 18 | 5 | **42** |

Check: Critical cells (L4 I5 = 2, L5 I4 = 1) give 3; High cells (L4 I3
= 3, L4 I4 = 2, L3 I4 = 6, L3 I5 = 1, L2 I5 = 2) give 14; Medium cells
(L3 I2 = 2, L3 I3 = 5, L2 I3 = 4, L2 I4 = 6) give 17; Low cells (L2 I2
= 3, L1 I3 = 2, L1 I4 = 3) give 8.

### 7.2 Target residual (after planned treatment) *(Example)*

| Likelihood / Impact | 1 | 2 | 3 | 4 | 5 | Row total |
|---|---|---|---|---|---|---|
| 5 | 0 | 0 | 0 | 0 | 0 | 0 |
| 4 | 0 | 0 | 0 | 0 | 0 | 0 |
| 3 | 0 | 0 | 3 | 2 | 0 | 5 |
| 2 | 0 | 6 | 5 | 9 | 2 | 22 |
| 1 | 0 | 0 | 4 | 8 | 3 | 15 |
| **Total** | 0 | 6 | 12 | 19 | 5 | **42** |

Check: High cells (L3 I4 = 2, L2 I5 = 2) give 4; Medium cells (L3 I3 =
3, L2 I3 = 5, L2 I4 = 9, L1 I5 = 3) give 20; Low cells (L2 I2 = 6, L1
I3 = 4, L1 I4 = 8) give 18.

## 8. Top risks

<!-- Guidance: List all Critical risks and the highest High risks, with owner and decision. Each row must sit in the heat map cell matching its likelihood and impact. -->

| Rank | Risk ID | Scenario (cause, event, consequence) | Catalogue refs | Current L x I | Current | Treatment | Target residual | Owner |
|---|---|---|---|---|---|---|---|---|
| 1 *(Example)* | R-006 | Unpatched systems and reachable backups let ransomware stop the managed service for days | THR-002, VUL-002, VUL-006 | 4 x 5 | 20 Critical | Modify | 2 x 4 = 8 Medium | [@head-of-service-operations] |
| 2 *(Example)* | R-001 | Phishing captures staff credentials that reach the scheduling database, exposing patient appointment data | THR-001, VUL-001, VUL-003 | 4 x 5 | 20 Critical | Modify | 1 x 4 = 4 Low | [@head-of-engineering] |
| 3 *(Example)* | R-039 | A flaw in the new hospital integration interface is exploited, altering or exposing schedules | THR-004, VUL-002 | 5 x 4 | 20 Critical | Modify | 2 x 4 = 8 Medium | [@head-of-engineering] |
| 4 *(Example)* | R-003 | Loss of laptops holding local exports of patient schedules | THR-015, VUL-005 | 4 x 4 | 16 High | Modify | 2 x 2 = 4 Low | [@it-manager] |
| 5 *(Example)* | R-022 | A departing administrator exports customer data | THR-006, VUL-013 | 4 x 4 | 16 High | Modify | 2 x 4 = 8 Medium | [@hr-director] |
| 6 *(Example)* | R-010 | Compromise of the managed hosting supplier with administrative access | THR-009, VUL-010 | 3 x 5 | 15 High | Modify and share | 2 x 5 = 10 High | [@cfo] |
| 7 *(Example)* | R-008 | Power failure at the colocation suite stops the managed service | THR-018, VUL-011 | 3 x 4 | 12 High | Modify | 2 x 4 = 8 Medium | [@head-of-service-operations] |
| 8 *(Example)* | R-017 | Corrupted schedules lead to missed clinical appointments | THR-020, VUL-015 | 2 x 5 | 10 High | Modify (detection and manual fallback; score unchanged) | 2 x 5 = 10 High | [@clinical-safety-officer] |

## 9. Changes since the last cycle

<!-- Guidance: Explain movements, not only totals. Auditors look for evidence that treatment from the last cycle worked and that new threats were picked up. -->

| Movement *(Example)* | Count | Detail |
|---|---|---|
| Risks in previous cycle | 38 | Cycle 2026-1 baseline |
| Closed or merged | 2 | R-012 retired (legacy fax referral process decommissioned); R-027 merged into R-005 |
| Continuing risks | 36 | |
| of which score decreased | 9 | Treatment completed: MFA for remote access, disk encryption on 90% of laptops, backup isolation phase 1 |
| of which score increased | 4 | R-008 (more customers on the managed service), R-010 (supplier given wider access), R-022, R-031 |
| of which unchanged | 23 | |
| New risks | 6 | R-039 to R-044, mainly from the integration interface and the second office |
| Risks in this cycle | 42 | 36 continuing plus 6 new |

Critical risks fell from 5 to 3: three former Critical risks moved to
High after the remote access MFA rollout, laptop encryption and backup
isolation phase 1, and R-039 is new.
*(Example)*

## 10. Treatment decisions handed to the risk treatment plan

<!-- Guidance: Summarise the decisions; the actions, owners, dates and budget live in DOC-ISMS-013. Treatment counts must total the number of risks. -->

| Option | Count *(Example)* | Bands | Recorded in |
|---|---|---|---|
| Modify (reduce) | 23 | 3 Critical, 12 High, 8 Medium | DOC-ISMS-013, new or updated RTP entries |
| Share (transfer) | 2 | 1 High (with modify), 1 Medium | DOC-ISMS-013 with insurance or contract reference |
| Avoid | 1 | 1 High | Decision to keep the legacy reporting export disabled |
| Retain (accept within criteria) | 16 | 8 Medium, 8 Low | Risk register acceptance fields |
| **Total** | **42** | 3 Critical, 14 High, 17 Medium, 8 Low | |

Note: R-010 is counted once, under Share, because its main decision is
to share part of the consequence through a contract and insurance,
combined with technical measures.

Statement of Applicability changes proposed: A.8.12 data leakage
prevention moves from Partial to Planned implementation for the
integration interface; A.5.21 ICT supply chain evidence to be updated.
*(Example)*

## 11. Risks referred for acceptance

<!-- Guidance: List each risk whose target residual needs top management approval under DOC-ISMS-015 section 9: High or Critical residual, or Medium in an Averse category (rule 1). Each gets an acceptance record DOC-ISMS-019. Medium risks within their category appetite are accepted by the risk owner and department head in the register and are not listed here. -->

| Risk ID | Target residual | Approval level required | Reason treatment stops here *(Example)* | Acceptance record |
|---|---|---|---|---|
| R-010 *(Example)* | 2 x 5 = 10 High | Top management | Supplier access is necessary for the managed service; impact remains severe if the supplier is breached | ACC-011 |
| R-017 *(Example)* | 2 x 5 = 10 High | Top management | Clinical impact of corrupted schedules cannot be reduced further by software alone; hospitals keep manual fallback | ACC-012 |
| R-029 *(Example)* | 3 x 4 = 12 High | Top management | Legacy component replacement scheduled in 2028; compensating monitoring until then | ACC-013 |
| R-033 *(Example)* | 3 x 4 = 12 High | Top management | Single interface engine supplier; exit plan in progress | ACC-014 |
| R-022 *(Example)* | 2 x 4 = 8 Medium | Top management (Medium in an Averse category, DOC-ISMS-015 section 9 rule 1) | Administrators need bulk export for customer support; approval workflow and export alerts reduce but do not remove the risk | ACC-015 |
| R-039 *(Example)* | 2 x 4 = 8 Medium | Top management (Medium in an Averse category, DOC-ISMS-015 section 9 rule 1) | Likelihood rests on the pre-go-live test; reassess after three months of operation (section 12) | ACC-016 |

## 12. Limitations and assumptions

<!-- Guidance: Be honest about what limits the results: missing data, unavailable owners, untested assumptions. Auditors respect stated limits more than claimed certainty. -->

- Likelihood ratings for the integration interface rely on the
  pre-go-live penetration test; reassess after three months of
  operation. *(Example)*
- Financial impact thresholds use the revenue forecast of
  [YYYY]; if revenue changes by more than [20]%, recalibrate.
- Supplier risks rely on supplier self-assessments for 2 of 5
  critical suppliers; independent evidence is requested.
- The privacy extension (ISO/IEC 27701:2025) is out of this cycle and
  assessed separately.

## 13. Size tiers

<!-- Guidance: The report's structure stays the same; its length, the number of participants and the approval route change with size. -->

| Aspect | Small: Quillmere Analytics Ltd *(Example)* | Medium: Quillmere Health Systems *(Example)* | Large or multi-site: Quillmere Group *(Example)* |
|---|---|---|---|
| Typical number of risks | 20 to 30 | 40 to 60 | Group report of 60 to 100 risks plus one annex per site |
| Workshops | Two half-day sessions led by the part-time ISMS manager | Three workshops over three weeks | Site workshops at each of 6 sites, then a group consolidation workshop |
| Participants | CEO, Head of Engineering Operations, two engineers | Risk owners, security team, DPO, clinical safety | Site managers, OT engineers, CISO's security office, divisional risk owners |
| Report length | 6 to 10 pages | 15 to 25 pages | Group summary of about 20 pages plus site annexes |
| Approval | CEO | CEO with steering committee | Group executive committee; site annexes approved by site directors |
| Frequency | Annual plus targeted assessments | Annual plus targeted assessments | Annual group cycle; site cycles phased as sites join the scope |

## 14. Records and evidence

<!-- Guidance: This report is itself a clause 8.2 record. List what supports it and map the records in the control evidence matrix (`isms/control-evidence-matrix`). -->

| Record | Proves | Owner | Location *(Example)* | Retention *(Example)* |
|---|---|---|---|---|
| This approved report | Risk assessment results retained (8.2) | ISMS manager | Document management system, DOC-ISMS-017 | 3 cycles minimum |
| Register snapshot at the report date | Counts are reproducible | ISMS manager | DOC-ISMS-016 export | Same as report |
| Workshop attendance and notes | Risk owners took part (6.1.2 c) | ISMS manager | ISMS working folder | 3 years |
| Risk owner validation e-mails or tickets | Owners agreed scores | Risk owners | Ticketing system | 3 years |
| Updated treatment plan | Results handed to treatment (6.1.3, 8.3) | ISMS manager | DOC-ISMS-013 | 3 years |
| Acceptance records | Residual risks above the risk owner's authority accepted at the right level | Top management | DOC-ISMS-019 | Life of risk plus 3 years |
| Management review minute | Results reported (9.3) | Steering committee secretary | DOC-ISMS-085 | 6 years |

## 15. References

<!-- Guidance: Cite the editions and the internal documents used for this cycle. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | 3rd edition 2022; Amd 1 2024-02-23 | Clauses 4.1, 6.1.2, 6.1.3, 8.2, 8.3 |
| ISO/IEC 27005:2022 | 4th edition | Approaches and reporting guidance |
| ISO 31000:2018 | Current; a revision is in progress | Risk treatment options |

Internal documents: DOC-ISMS-002 scope, DOC-ISMS-003 context,
DOC-ISMS-010 method, DOC-ISMS-011 SoA, DOC-ISMS-012 asset inventory,
DOC-ISMS-013 treatment plan, DOC-ISMS-015 criteria, DOC-ISMS-016
register, DOC-ISMS-018 catalogue, DOC-ISMS-019 acceptance records.

Related templates: `compliance/risk-methodology`,
`isms/isms-risk-appetite-criteria`, `compliance/risk-register`,
`isms/isms-threat-vulnerability-catalogue`,
`compliance/risk-treatment-plan`, `isms/isms-risk-acceptance-record`,
`compliance/statement-of-applicability`, `compliance/asset-inventory`,
`compliance/management-review`.

Official text: https://www.iso.org/standard/82875.html,
https://www.iso.org/standard/88435.html,
https://www.iso.org/standard/80585.html.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.1.2,
6.1.3, 8.2 and 8.3) and ISO/IEC 27005:2022. Clause numbers are cited
only; the report structure, conventions, figures and examples are
original text written for this template, and all figures are worked
examples. No ISO or IEC text is reproduced, and you need the official
standards to interpret the requirements. Check the current editions
before use. This template does not promise certification;
certification decisions belong to the accredited certification body.

Template licence: MIT.