# ISMS Project Charter: [Organization name]

> Project charter for implementing an information security management
> system (ISMS) and preparing for certification to ISO/IEC 27001:2022
> including Amendment 1:2024. It turns the approved business case into a
> mandate: objectives, a draft scope boundary, sponsor and roles,
> governance cadence, milestones up to the Stage 2 certification audit,
> assumptions, constraints, success criteria and change control. It
> supports clauses 5.1 and 5.3 (leadership commitment, roles and
> authorities), 6.2 (objectives and how they will be achieved) and 7.1
> (resources) during the build phase. Replace every `[bracketed]` value
> and every row marked *Example*.

<!--
Guidance: How to use this template
- Use it once the business case (`isms/isms-business-case`,
  DOC-ISMS-029) is approved and before work starts. The charter is the
  project's contract with top management; it closes when the Stage 2
  audit is complete and the ISMS is handed over to normal operation.
- Fill first: section 2 (objectives) and section 3 (draft scope
  boundary), then section 5 (roles) and section 7 (milestones). Copy
  the dates from `isms/isms-implementation-roadmap` (DOC-ISMS-030).
- Main pitfall: treating the ISMS as an IT project that "finishes".
  The project ends, the management system does not. Plan the handover
  to the steering committee and the annual calendar from the start.
- Related templates: `isms/isms-business-case`,
  `isms/isms-implementation-roadmap`, `isms/isms-budget-resource-plan`,
  `isms/isms-roles-raci`, `isms/isms-steering-committee-charter`,
  `compliance/ms-scope`, `compliance/iso-27001-gap-assessment`,
  `isms/certification-body-selection`.
-->

## Document control

<!-- Guidance: The charter is approved by the sponsor and top management. Every approved project change request (section 11) that changes scope, milestones or budget produces a new charter version. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-009 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Closed] |
| Owner | [@isms-project-manager] |
| Approvers/reviewers | [@sponsor], [@ceo], [@cfo], [@isms-manager] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024; guidance ISO/IEC 27003:2017 (a revision is in progress; check for a newer edition) |
| Project name | [ISMS implementation and ISO/IEC 27001 certification] |
| Business case reference | DOC-ISMS-029, version [1.0], decision [DEC-ISMS-001] |
| Roadmap reference | DOC-ISMS-030, version [1.0] |
| Budget reference | DOC-ISMS-031, version [1.0] |
| Project start and planned close | YYYY-MM-DD to YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD [each phase gate] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Project manager | [@isms-project-manager] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| Sponsor | [@sponsor] | [Approved] | YYYY-MM-DD |
| Top management | [@ceo] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@isms-project-manager] | Charter approved at project kick-off |
| 1.1 *(Example)* | YYYY-MM-DD | [@isms-project-manager] | PCR-002 approved: outsourced support desk added to scope, phase 5 extended by two weeks, Stage 2 unchanged |

## Contents

<!-- Guidance: Keep the charter short enough to read in one sitting (8 to 12 pages). Detail lives in the roadmap, the budget and the RACI. -->

1. Purpose and background
2. Objectives
3. Draft scope boundary
4. Deliverables
5. Sponsor, roles and project organisation
6. Governance cadence
7. Milestones to Stage 2
8. Assumptions and constraints
9. Project risks
10. Success criteria
11. Change control for the project
12. Handover and closure
13. Size tiers
14. Records and evidence
15. References

## 1. Purpose and background

<!-- Guidance: Two paragraphs: why the project exists (link the business case decision) and what "done" means. Do not repeat the whole business case. -->

[Organization name] decided on YYYY-MM-DD (decision [DEC-ISMS-001]) to
build an ISMS and to seek accredited certification to ISO/IEC
27001:2022. This charter authorises the project, names the people
accountable for it and sets the boundaries within which the project
manager may act without returning to top management.

The project is complete when the ISMS operates as described in clauses
4 to 10, the Stage 2 certification audit has been carried out, any
findings have an accepted action plan, and ownership has passed to the
ISMS steering committee (`isms/isms-steering-committee-charter`,
DOC-ISMS-007). The certification decision itself belongs to the
accredited certification body.

## 2. Objectives

<!-- Guidance: Write objectives that are specific, measurable and dated. Separate project objectives (deliver the ISMS) from ISMS objectives (clause 6.2), which go into the objectives register once the ISMS exists. -->

### 2.1 Project objectives

| ID | Objective | Measure | Target date | Owner |
|---|---|---|---|---|
| PRJ-OBJ-001 *(Example)* | Define and approve the ISMS scope | Scope statement DOC-ISMS-002 approved by top management | 2027-03-01 | [@isms-manager] |
| PRJ-OBJ-002 *(Example)* | Complete the first risk assessment and the Statement of Applicability | Risk register, risk assessment report and SoA approved | 2027-04-26 | [@isms-manager] |
| PRJ-OBJ-003 *(Example)* | Implement the controls selected in the SoA | 90% of treatment plan actions due before Stage 1 closed, rest scheduled with owners | 2027-08-02 | [@control-owners] |
| PRJ-OBJ-004 *(Example)* | Operate the ISMS and produce records | At least 12 weeks of records for recurring controls before Stage 2 | 2027-10-18 | [@isms-manager] |
| PRJ-OBJ-005 *(Example)* | Complete one full internal audit and one management review | Audit report and management review minutes approved | 2027-09-06 | [@internal-auditor], [@ceo] |
| PRJ-OBJ-006 *(Example)* | Complete Stage 1 and Stage 2 audits within budget | Audit reports received; spend within 10% of DOC-ISMS-031 | 2027-11-01 | [@sponsor] |

### 2.2 Initial ISMS objectives to be confirmed

Draft two to four ISMS objectives (clause 6.2) for approval in phase 2,
for example: "Phishing simulation report rate above 60% by
YYYY-MM-DD" or "All critical vulnerabilities fixed within 14 days".
Record them in the objectives register
(`compliance/objectives-register`, DOC-ISMS-024).

## 3. Draft scope boundary

<!-- Guidance: This is a draft for planning and budgeting. The final scope is set in phase 1 after the context analysis (clauses 4.1 to 4.3) and approved in DOC-ISMS-002. Write down interfaces and dependencies, not only what is in and out. Auditors challenge scopes that exclude the people, sites or suppliers the service actually depends on. -->

| Element | In scope (draft) | Out of scope (draft) | Reason |
|---|---|---|---|
| Services *(Example)* | Clinical scheduling platform (SaaS) and managed service | Legacy on-premises product in end-of-life support | End of life in 12 months; customers informed |
| Legal entities *(Example)* | Quillmere Health Systems | Holding company | No operations |
| Locations *(Example)* | Two offices, one colocation suite, remote workers | Customer hospital premises | Customer responsibility; covered by contracts |
| Technology *(Example)* | Production and DR environments, corporate IT, SaaS productivity suite | Customer-managed integrations | Customer controlled |
| People *(Example)* | All 320 staff and contractors with access to in-scope assets | None | Everyone who can affect the service is in scope |
| Suppliers *(Example)* | Colocation provider, cloud backup provider, payroll SaaS (interface only) | Office cleaning (no system access) | Interface controls only |

Interfaces and dependencies to document in the scope statement:
[customer integrations, colocation provider services, outsourced
support desk, group shared services].

## 4. Deliverables

<!-- Guidance: List the documents and records the project must produce. Use the library's Document IDs so everyone refers to the same thing. The roadmap gives the full list per phase. -->

| Deliverable | Document ID | Template | Phase |
|---|---|---|---|
| Context and interested parties | DOC-ISMS-003 | `isms/isms-context-interested-parties` | 1 |
| ISMS scope | DOC-ISMS-002 | `compliance/ms-scope` | 1 |
| Information security policy | DOC-ISMS-001 | `compliance/information-security-policy` | 2 |
| Roles, responsibilities and RACI | DOC-ISMS-006 | `isms/isms-roles-raci` | 2 |
| Risk assessment methodology | DOC-ISMS-010 | `compliance/risk-methodology` | 3 |
| Risk register and risk assessment report | DOC-ISMS-016, DOC-ISMS-017 | `compliance/risk-register`, `isms/isms-risk-assessment-report` | 3 |
| Statement of Applicability | DOC-ISMS-011 | `compliance/statement-of-applicability` | 3 |
| Risk treatment plan | DOC-ISMS-013 | `compliance/risk-treatment-plan` | 3 |
| Competence and training matrix | DOC-ISMS-026 | `isms/isms-competence-training-matrix` | 4 |
| Control evidence matrix | DOC-ISMS-033 | `isms/control-evidence-matrix` | 5 |
| Internal audit report | DOC-ISMS-084 | `isms/isms-internal-audit-report` | 7 |
| Management review minutes | DOC-ISMS-085 | `compliance/management-review` | 8 |
| Stage 1 readiness pack | DOC-ISMS-091 | `isms/stage-1-readiness-pack` | 9 |
| Stage 2 audit evidence index | DOC-ISMS-092 | `isms/stage-2-audit-evidence-index` | 10 |

## 5. Sponsor, roles and project organisation

<!-- Guidance: Name people, not departments. The sponsor must have authority over budget and over the managers whose staff do the work. Under clause 5.3 someone named by top management must answer for the ISMS meeting the standard and for telling top management how it is doing: make that person explicit here for the build phase. -->

| Role | Name | Responsibilities | Time commitment *(Example)* |
|---|---|---|---|
| Sponsor | [@coo] | Owns the business case, chairs the steering group, removes obstacles, approves changes within tolerance | 2 hours a week |
| Top management | [@ceo] and executive team | Approve policy, scope, risk acceptance and resources; take part in management review | Phase gates and management review |
| ISMS manager | [@isms-manager] | Designs and runs the ISMS; reports on its performance (clause 5.3 b) | 1.0 FTE |
| Project manager | [@isms-project-manager] | Plan, track, report, manage the RAID log and change control | 0.5 FTE (may be the ISMS manager in small organisations) |
| Security team | [@security-team] | Risk workshops, technical controls, monitoring, incident process | 1.2 FTE across 3 people |
| Control owners | [@it-lead], [@hr-lead], [@facilities-lead], [@engineering-lead] | Implement and operate assigned controls; keep records | 0.6 FTE combined |
| Internal auditor | [@internal-auditor] (independent of audited areas) | Plan and perform the first internal audit | 0.2 FTE in phase 7 |
| Legal and privacy | [@legal-counsel], [@dpo] | Legal register, contracts, privacy interfaces | As needed |
| External consultant *(optional)* | [Firm, role] | Coaching, templates review, pre-audit check; never owns ISMS decisions | Per contract |

The full RACI for ISMS processes is kept in `isms/isms-roles-raci`
(DOC-ISMS-006).

```mermaid
flowchart TD
  TM["Top management"] --> SP["Sponsor (COO)"]
  SP --> SG["Project steering group"]
  SG --> PM["Project manager"]
  SG --> IM["ISMS manager"]
  PM --> WS1["Workstream: context, scope and policy"]
  PM --> WS2["Workstream: risk and SoA"]
  PM --> WS3["Workstream: control implementation"]
  PM --> WS4["Workstream: audit readiness"]
  IM --> WS2
  IM --> WS4
```

## 6. Governance cadence

<!-- Guidance: State who meets, how often, with what inputs and what they decide. Keep the cadence light for small organisations and formal for large ones. The steering group becomes the ISMS steering committee after closure. -->

| Forum | Frequency | Chair | Members | Inputs | Decisions |
|---|---|---|---|---|---|
| Project steering group | Monthly and at each phase gate | [@sponsor] | CEO delegate, ISMS manager, project manager, CFO delegate, heads of engineering and HR | Status report, RAID log, budget, change requests | Phase gate approval, changes within tolerance, escalations |
| Project working group | Weekly | [@isms-project-manager] | ISMS manager, security team, control owners on rotation | Plan, action list, blockers | Task allocation, workarounds |
| Risk workshop | Per phase 3 schedule, then quarterly | [@isms-manager] | Risk owners | Asset inventory, threat catalogue, incidents | Risk ratings and proposed treatments |
| Top management briefing | At phase gates 2, 3, 8 and 10 | [@ceo] | Executive team | Policy, scope, risk acceptance, management review inputs | Approvals and resource decisions |

Status reporting: a one-page status report goes to the sponsor every
[two weeks], with RAG status for schedule, budget, scope and risk.

## 7. Milestones to Stage 2

<!-- Guidance: Use the dates from the roadmap. A milestone is a verifiable event (a document approved, an audit completed), not an activity. Leave a margin before any external deadline such as a tender. -->

Worked example: Quillmere Health Systems, start 2027-01-04, target about
10 months (all dates *Example*).

| ID | Milestone | Evidence | Planned date |
|---|---|---|---|
| MS-01 *(Example)* | Charter approved, team mobilised | Signed charter | 2027-01-25 |
| MS-02 *(Example)* | Scope and context approved | DOC-ISMS-002, DOC-ISMS-003 approved | 2027-03-01 |
| MS-03 *(Example)* | Policy, roles and objectives approved | DOC-ISMS-001, DOC-ISMS-006, DOC-ISMS-024 | 2027-03-15 |
| MS-04 *(Example)* | Certification body contracted | Signed contract, audit dates booked | 2027-04-12 |
| MS-05 *(Example)* | Risk assessment, SoA and treatment plan approved | DOC-ISMS-016, 017, 011, 013 approved; residual risks accepted | 2027-04-26 |
| MS-06 *(Example)* | Priority controls implemented | Treatment plan actions due by this date closed | 2027-08-02 |
| MS-07 *(Example)* | Internal audit completed | DOC-ISMS-084 issued, findings logged | 2027-08-30 |
| MS-08 *(Example)* | Management review held | DOC-ISMS-085 minutes approved | 2027-09-06 |
| MS-09 *(Example)* | Stage 1 audit completed | Stage 1 report received | 2027-09-20 |
| MS-10 *(Example)* | Stage 1 findings closed | Evidence of closure in DOC-ISMS-093 | 2027-10-18 |
| MS-11 *(Example)* | Stage 2 audit completed | Stage 2 report received | 2027-11-01 |
| MS-12 *(Example)* | Project closed, handover done | Closure report, steering committee in place | 2027-11-29 |

```mermaid
flowchart LR
  M1["MS-01 Charter"] --> M2["MS-02 Scope"]
  M2 --> M3["MS-03 Policy and roles"]
  M3 --> M5["MS-05 Risk, SoA, treatment"]
  M4["MS-04 CB contracted"] --> M9["MS-09 Stage 1"]
  M5 --> M6["MS-06 Controls in place"]
  M6 --> M7["MS-07 Internal audit"]
  M7 --> M8["MS-08 Management review"]
  M8 --> M9
  M9 --> M10["MS-10 Stage 1 findings closed"]
  M10 --> M11["MS-11 Stage 2"]
  M11 --> M12["MS-12 Closure"]
```

## 8. Assumptions and constraints

<!-- Guidance: Assumptions are things you believe true but have not verified; give each an owner and a date to check. Constraints are fixed limits. When an assumption proves false, raise a change request. -->

### 8.1 Assumptions

| ID | Assumption | Owner | Validate by |
|---|---|---|---|
| ASM-001 *(Example)* | Control owners can give the agreed time without backfill | [@sponsor] | 2027-02-01 |
| ASM-002 *(Example)* | The colocation provider will share its own certificate and audit report under NDA | [@it-lead] | 2027-02-15 |
| ASM-003 *(Example)* | No major platform migration starts during the project | [@cto] | 2027-01-25 |
| ASM-004 *(Example)* | The certification body can schedule Stage 1 and Stage 2 within six weeks of each other | [@isms-manager] | 2027-04-12 |
| ASM-005 *(Example)* | Existing SaaS tools provide the logs needed for monitoring controls | [@security-lead] | 2027-03-15 |

### 8.2 Constraints

| ID | Constraint | Impact |
|---|---|---|
| CON-001 *(Example)* | Year 1 budget capped at the amount approved in DOC-ISMS-031 | Changes above 10% need top management approval |
| CON-002 *(Example)* | Stage 2 must be complete before the hospital framework tender deadline | Fixed end date with a two-month margin |
| CON-003 *(Example)* | No change freeze can exceed two weeks during the clinical go-live season | Remediation scheduled around releases |
| CON-004 *(Example)* | Customer data cannot leave the agreed hosting regions | Shapes tooling choices for logging and backup |

## 9. Project risks

<!-- Guidance: Keep a short RAID log (risks, assumptions, issues, decisions). Score with the library's 5 x 5 scale. These are project risks, not ISMS information security risks: the latter go into the risk register in phase 3. -->

| ID | Risk | Likelihood | Impact | Score | Response | Owner |
|---|---|---|---|---|---|---|
| PRJ-RISK-001 *(Example)* | Control owners prioritise delivery work over ISMS tasks | 4 | 3 | 12 | Named allocations in DOC-ISMS-031; sponsor escalation path | [@sponsor] |
| PRJ-RISK-002 *(Example)* | Records period too short before Stage 2 | 3 | 4 | 12 | Start recurring controls (access review, log review, backup test) early in phase 6 | [@isms-manager] |
| PRJ-RISK-003 *(Example)* | Policies written but not adopted | 3 | 3 | 9 | Communication plan, awareness sessions, attestations | [@hr-lead] |
| PRJ-RISK-004 *(Example)* | Key person (ISMS manager) leaves | 2 | 5 | 10 | Deputy named, documentation kept current | [@ceo] |
| PRJ-RISK-005 *(Example)* | Certification body availability delays Stage 1 | 2 | 3 | 6 | Book audit dates at MS-04 | [@isms-manager] |

## 10. Success criteria

<!-- Guidance: Agree up front how the sponsor will judge success. Avoid "obtain the certificate" as the only criterion: the project controls readiness, the certification body controls the decision. -->

The project is successful when:

1. All deliverables in section 4 are approved and under document
   control.
2. The Stage 1 audit raises no issue that prevents Stage 2 from going
   ahead on the planned date.
3. The Stage 2 audit raises no major nonconformity, or every major
   nonconformity has an action plan accepted by the certification body
   within the time it sets.
4. Spend is within 10% of the approved budget and the planned Stage 2
   date is met or moved only by an approved change request.
5. The ISMS steering committee, the annual calendar
   (`isms/isms-annual-calendar`) and the measurement programme
   (`isms/isms-measurement-programme`) are in place at closure.
6. A staff survey or attestation shows at least [90%] of staff have
   read the information security policy and completed awareness
   training.

## 11. Change control for the project

<!-- Guidance: Define tolerances so the project manager can act on small changes and escalate large ones. Every change that touches scope, Stage 2 date or budget beyond tolerance needs a written project change request (PCR). Changes to the ISMS itself after it is live follow clause 6.3 and the ISMS change plan (`isms/isms-change-plan`), not this section. -->

### 11.1 Tolerances

| Dimension | Project manager may approve | Sponsor may approve | Top management must approve |
|---|---|---|---|
| Schedule | Task moves that do not change a milestone | Milestone moves up to 2 weeks without moving Stage 2 | Any move of the Stage 2 date |
| Budget | Reallocation between cost lines up to USD 10,000 *(Example)* | Up to 10% of the year budget | Above 10% |
| Scope | Wording changes to the draft scope | Adding or removing a minor system or supplier interface | Adding or removing a service, site, legal entity or country |
| Quality | Template or tool changes | Changes to the evidence approach | Lowering any success criterion |

### 11.2 Process

Raise every change as a PCR, assess its impact, route it to the lowest
level whose tolerance covers it, then update the plan and tell the team.

```mermaid
flowchart TD
  A["Change identified"] --> B["PCR raised in the change log"]
  B --> C["Impact assessed: scope, schedule, budget, risk"]
  C --> D{"Within project manager tolerance?"}
  D -- Yes --> E["Project manager approves and records"]
  D -- No --> F{"Within sponsor tolerance?"}
  F -- Yes --> G["Sponsor approves at steering group"]
  F -- No --> H["Top management decision"]
  E --> I["Update plan, charter version if needed"]
  G --> I
  H --> I
  I --> J["Communicate to the team and stakeholders"]
```

### 11.3 Change log

| PCR ID | Date | Requested by | Description | Impact | Decision | Approved by |
|---|---|---|---|---|---|---|
| PCR-001 *(Example)* | 2027-02-10 | [@it-lead] | Use the existing ticketing tool for the risk register instead of buying a GRC tool in year 1 | Budget minus USD 15,000 (above the project manager's USD 10,000 tolerance, within 10% of the year budget); slight manual effort increase | Approved | [@sponsor] |
| PCR-002 *(Example)* | 2027-03-08 | [@cto] | Add the outsourced support desk (a supplier interface with access to customer tickets) to scope after customer feedback | Two extra weeks in phase 5; Stage 2 unchanged | Approved | [@sponsor] |
| PCR-003 *(Example)* | 2027-06-14 | [@head-of-sales] | Bring Stage 2 forward by one month for a tender | No time left to close Stage 1 findings before Stage 2 | Rejected, risk to Stage 2 outcome | [@ceo] |

## 12. Handover and closure

<!-- Guidance: Plan the end on day one. Name who takes over each recurring activity, so the ISMS keeps producing records after the project team disbands. -->

At closure, the project manager prepares a closure report covering:

- deliverables status and where each is stored;
- final spend against budget and remaining commitments (for example
  surveillance audit fees in DOC-ISMS-031);
- open findings, treatment actions and their owners;
- lessons learned, recorded in the continual improvement register
  (`isms/continual-improvement-register`);
- handover of recurring activities to their owners, confirmed in the
  annual calendar (`isms/isms-annual-calendar`) and the certification
  cycle plan (`isms/certification-cycle-plan`).

The project steering group hands its role to the ISMS steering committee
(`isms/isms-steering-committee-charter`, DOC-ISMS-007).

## 13. Size tiers

<!-- Guidance: Scale the charter to the organisation. A short charter that people use beats a long one nobody reads. These are the library's working tiers, not official definitions. -->

| Element | Small: Quillmere Analytics Ltd | Medium: Quillmere Health Systems | Large: Quillmere Group |
|---|---|---|---|
| Profile | 46 staff (38 employees, 8 contractors), one office plus remote, one public cloud in two regions | 320 staff, two offices, one colocation suite | 2,400 staff, 6 sites in 4 countries, OT and IT, ISO 9001 and ISO 22301 certified |
| Sponsor | CEO | COO | Group COO or CFO, with site directors as local sponsors |
| ISMS manager and project manager | Same person: Head of Engineering Operations, 0.5 FTE | Full-time ISMS manager; project manager 0.5 FTE | CISO with 14-person security office; dedicated programme manager and site coordinators |
| Draft scope | Whole company and SaaS platform | Scheduling platform and managed service, both offices, colocation suite | Group scope phased by site: HQ, data centre and service centre first, then the 3 plants |
| Governance | Fortnightly 30-minute check-in with the CEO | Monthly steering group, weekly working group | Programme board monthly, site steering groups, integration with the existing management system review |
| Target *(Example)* | Certification in 6 months | 10 months to Stage 2 | 15 months, phased by site |
| Charter length | 4 to 6 pages | Full template | Full template plus a site annex and integration plan |

## 14. Records and evidence

<!-- Guidance: These records show that the ISMS was planned and resourced. Some are useful at Stage 1, when the auditor checks how the ISMS was established. -->

| Record | Proves | Owner | Location | Retention *(Example)* |
|---|---|---|---|---|
| Approved charter and versions | Mandate, roles and authority (clause 5.3) | [@isms-project-manager] | [Document management system] | Life of the ISMS plus 3 years |
| Steering group minutes | Oversight and decisions | [@sponsor] | [Project workspace] | 3 years |
| Status reports | Progress monitoring | [@isms-project-manager] | [Project workspace] | 3 years |
| Change log (section 11.3) | Controlled changes | [@isms-project-manager] | [Project workspace] | 3 years |
| Closure report and handover | Transition to operation | [@isms-manager] | [ISMS records library] | Life of the ISMS |

List these records in the documented information register
(`isms/isms-documented-information-register`) and map them in the
control evidence matrix (`isms/control-evidence-matrix`).

## 15. References

<!-- Guidance: Cite exact editions. ISO/IEC 27003 gives implementation guidance; it is not a requirement. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022, information security management systems requirements | 2022, with Amd 1:2024 | Clauses 4 to 10, certification basis. https://www.iso.org/standard/82875.html, https://www.iso.org/standard/88435.html |
| ISO/IEC 27003:2017, ISMS guidance | 2017 (a revision is in progress; check for a newer edition) | Implementation guidance. https://www.iso.org/standard/63417.html |
| ISO/IEC 17021-1:2015, requirements for certification bodies | 2015 | Stage 1 and Stage 2 audit structure. https://www.iso.org/standard/61651.html |
| ISO/IEC 27006-1:2024, requirements for ISMS certification bodies | 2024 | Audit time and planning by the certification body. https://www.iso.org/standard/82908.html |

Related templates: `isms/isms-business-case`,
`isms/isms-implementation-roadmap`, `isms/isms-budget-resource-plan`,
`isms/isms-roles-raci`, `isms/isms-steering-committee-charter`,
`compliance/ms-scope`, `isms/certification-body-selection`,
`isms/stage-1-readiness-pack`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 including Amd 1:2024
(clauses 5.1, 5.3, 6.2 and 7.1) and common project management practice.
The text, roles, milestones and examples are original; no ISO/IEC text
is reproduced. You need the official standard for the requirements
themselves: https://www.iso.org/standard/82875.html. Check the current
edition of every standard before use. Dates and figures are *Example*
values, and certification decisions belong to the accredited
certification body. Template licence: MIT.