Initial commit

00-governance/document-and-records-control-standard.md

@@ -0,0 +1,75 @@
+Title: Document and Records Control Standard
+Document ID: [STD-DOCCTRL-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Document and Records Control Standard
+
+## Purpose
+
+This standard defines the minimum requirements for creating, approving, storing, changing, retaining, and retiring ISMS documents and records.
+
+## Scope
+
+This standard applies to controlled ISMS documents and records, including policies, standards, procedures, templates, registers, audit outputs, management review records, and evidence retained to support assurance activity.
+
+## Mandatory Requirements
+
+Controlled documents must use the approved metadata fields for title, document ID, version, status, owner, approver, classification, effective date, and review date.
+
+Controlled documents must be stored in approved locations where version history, access control, and integrity can be managed.
+
+Each controlled document must have a named owner responsible for accuracy, review, and proposed updates.
+
+Changes to controlled documents must be reviewed and approved by the appropriate authority before issue, except for draft working changes that are clearly marked as draft.
+
+Superseded versions of controlled documents must be retained or archived according to retention requirements where evidence of previous approval or historical traceability is needed.
+
+Operational records must be complete enough to demonstrate that required activities were performed. Records must identify the relevant date, owner or contributor, and the subject of the activity.
+
+Records that contain sensitive information must be classified and protected according to applicable handling requirements.
+
+Review dates must be assigned to controlled documents, and overdue reviews must be tracked and resolved.
+
+Document identifiers and filenames should remain stable unless a controlled renaming decision is made.
+
+## Implementation Guidance
+
+BlackDice should maintain a single agreed repository or controlled set of repositories for ISMS documents and evidence. Where supporting records are held in operational systems, the document set should reference the system of record rather than duplicate evidence unnecessarily.
+
+Document owners should avoid embedding unverifiable statements in controlled documents. Where a control is planned but not fully implemented, the document should state that clearly.
+
+Version control tables should summarise meaningful changes without fabricating historic approvals. Draft packs may begin with a single initial entry.
+
+For records such as risk entries, incidents, supplier reviews, and audit actions, the underlying workflow tool may be used as the system of record if retention, access control, and auditability are adequate.
+
+## Roles and Responsibilities
+
+- The standard owner must maintain this standard and define control expectations.
+- Document owners must ensure that controlled documents are accurate, reviewed, and appropriately approved.
+- Record owners must ensure records are created, retained, and protected in line with this standard.
+- Approvers must confirm that documents are suitable before issue.
+- Personnel creating records must ensure entries are timely, factual, and complete.
+
+## Exceptions
+
+Exceptions to this standard must be documented, justified, risk-assessed where appropriate, and approved through the defined exception management process.
+
+## Related Documents
+
+- ISMS Manual
+- Information Security Policy
+- Statement of Applicability Template
+- Information Security Objectives Template
+- Security Exceptions Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

00-governance/information-security-objectives-template.md

@@ -0,0 +1,70 @@
+Title: Information Security Objectives Template
+Document ID: [GOV-OBJECTIVES-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Information Security Objectives Template
+
+## Purpose
+
+This template provides a standard structure for defining, approving, monitoring, and reviewing BlackDice's information security objectives.
+
+## Scope
+
+This template applies to information security objectives established under the ISMS, including organisation-wide objectives and targeted objectives for specific functions, risks, or improvement programmes.
+
+## Data Fields / Expected Columns
+
+Each objective record should include:
+
+- objective statement
+- rationale or linked risk/business need
+- measure or indicator
+- target value or expected outcome
+- owner
+- reporting frequency
+- target date
+- current status
+- notes on blockers, assumptions, or dependencies
+
+## Ownership
+
+The objectives register should be owned by [Role]. Individual objectives should have named owners responsible for delivery, measurement, and reporting.
+
+## Update Frequency
+
+Objectives should be reviewed at planned intervals defined by management and at least during formal management review. High-priority objectives may require monthly or quarterly reporting depending on risk and operational impact.
+
+## Retention
+
+Current and superseded objective records should be retained in line with document and records retention requirements so that performance trends and evidence of review can be demonstrated.
+
+## Template Table
+
+| Objective | Rationale / Linked Risk | Measure | Target | Owner | Reporting Frequency | Target Date | Status | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [Objective statement] | [Risk, issue, or requirement] | [KPI / metric] | [Target] | [Role] | [Frequency] | [DD Month YYYY] | [Open / On Track / At Risk / Closed] | [Notes] |
+
+## Example Objective Types
+
+Objectives may relate to:
+
+- reduction of high-risk findings
+- improvement of incident response performance
+- access review completion
+- vulnerability remediation timeliness
+- backup or recovery testing performance
+- supplier assurance coverage
+- awareness and training completion
+
+## Related Documents
+
+- Information Security Policy
+- ISMS Manual
+- Risk Assessment and Treatment Methodology
+- Management Review Procedure

00-governance/information-security-policy.md

@@ -0,0 +1,87 @@
+Title: Information Security Policy
+Document ID: [POL-INFOSEC-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CEO (Paul Hague)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Information Security Policy
+
+## Purpose
+
+This policy sets out BlackDice's overall direction for managing information security. It establishes the management intent and core principles that the ISMS and supporting control framework must follow.
+
+## Scope
+
+This policy applies to all personnel, contractors, systems, information assets, and third parties within the approved ISMS scope. It applies to activities involved in developing, operating, supporting, and assuring BlackDice services and supporting business functions.
+
+## Objectives
+
+BlackDice's information security objectives should support:
+
+- confidentiality, integrity, and availability of information and services
+- effective identification and treatment of security risk
+- secure cloud-native service delivery and software development
+- proportionate control over suppliers, systems, and operational processes
+- compliance with applicable legal, regulatory, contractual, and assurance requirements
+- continual improvement of security performance
+
+## Principles / Policy Statements
+
+BlackDice must maintain an ISMS that is appropriate to its business activities, risk profile, and operating model.
+
+Information security risks must be identified, assessed, treated, and reviewed using an approved and repeatable methodology.
+
+Security controls must be selected and operated in a manner that is proportionate to risk and suitable for cloud-native SaaS operations, including containerised workloads, CI/CD processes, and operational monitoring functions.
+
+Access to information and systems must be controlled according to business need, least privilege, and approved authorisation.
+
+Information assets must be identified, classified, handled, retained, and disposed of according to business, legal, contractual, and security requirements.
+
+Security requirements must be considered throughout system design, software development, change management, deployment, and operational support activities.
+
+Security events and weaknesses must be reported, assessed, and managed through defined incident and escalation processes.
+
+Suppliers and third parties that support in-scope services or handle relevant information must be assessed and managed according to risk.
+
+Exceptions to required controls must be documented, risk-assessed, approved, time-bound where appropriate, and reviewed.
+
+BlackDice should monitor the effectiveness of the ISMS and use audit, review, and corrective action to improve it.
+
+## Roles and Responsibilities
+
+- [Role] is accountable for overall ownership of this policy and the ISMS.
+- Managers must ensure that relevant personnel understand and follow applicable security requirements.
+- Document and control owners must maintain policies, standards, procedures, and records relevant to their areas.
+- All personnel and contractors must follow applicable information security requirements and report security concerns promptly.
+- Management must review ISMS performance and support continual improvement.
+
+## Compliance / Exceptions
+
+Failure to comply with this policy may result in investigation and corrective action in line with BlackDice processes and contractual arrangements.
+
+Any exception to this policy must be raised through the approved exception management process and approved by [Approval Authority] based on documented risk.
+
+## Monitoring and Review
+
+This policy should be reviewed at least annually and when material changes occur to business operations, technology, legal obligations, or the threat landscape.
+
+Compliance and effectiveness should be monitored through management review, internal audit, risk review, incident analysis, exception tracking, and progress against security objectives.
+
+## Related Documents
+
+- ISMS Scope Statement
+- ISMS Manual
+- Risk Assessment and Treatment Methodology
+- Document and Records Control Standard
+- Statement of Applicability Template
+- Information Security Objectives Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

00-governance/isms-manual.md

@@ -0,0 +1,107 @@
+Title: ISMS Manual
+Document ID: [GOV-ISMS-MANUAL-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# ISMS Manual
+
+## Purpose
+
+This manual describes the structure of BlackDice's ISMS and how its governing documents, operational controls, and review activities fit together. It is intended to help document owners, reviewers, and auditors understand how the ISMS is organised.
+
+## Scope
+
+This manual applies to the ISMS documentation set and the management processes used to direct, monitor, and improve information security within the approved ISMS scope.
+
+## ISMS Overview
+
+BlackDice operates a technical security business with cloud-native service delivery, containerised workloads, software delivery pipelines, security telemetry handling, and customer assurance obligations. The ISMS is intended to provide a repeatable management framework for those activities without assuming technologies, teams, or organisational structures that have not yet been confirmed.
+
+## ISMS Objectives
+
+The ISMS is intended to support BlackDice in:
+
+- protecting information assets and service integrity
+- managing risk in a structured and repeatable way
+- selecting and operating proportionate security controls
+- meeting contractual, legal, regulatory, and assurance expectations
+- driving continual improvement through audit, review, and corrective action
+
+## Document Hierarchy
+
+The ISMS document set is structured as follows:
+
+- governance documents define scope, management framework, risk method, control applicability, and document control
+- policies define management intent and high-level requirements
+- standards define mandatory implementation requirements
+- procedures define operational steps and evidence outputs
+- registers and templates define the records needed to operate and evidence the ISMS
+- audit and review artefacts support assurance and continual improvement
+
+## Core ISMS Processes
+
+The following processes form the core operating cycle of the ISMS:
+
+1. Define the scope, interested parties, and control framework.
+2. Identify and assess risks using the approved methodology.
+3. Select controls and record applicability and treatment decisions.
+4. Implement policies, standards, and procedures.
+5. Monitor performance, incidents, exceptions, and control effectiveness.
+6. Conduct internal audit and management review.
+7. Track corrective actions and improvement activity.
+
+## Governance Model
+
+The governance model should define:
+
+- who owns the ISMS
+- who approves policies and significant control decisions
+- who owns risks, exceptions, and corrective actions
+- how management review is conducted
+- how internal audit independence is maintained
+
+Named committees, boards, and role titles are not assigned in this draft and must be completed during tailoring.
+
+## Roles and Responsibilities
+
+- The ISMS owner is accountable for maintaining the ISMS framework.
+- Document owners are responsible for keeping assigned documents accurate and current.
+- Control owners are responsible for implementing and operating assigned controls.
+- Risk owners are responsible for evaluating and treating assigned risks.
+- Management is responsible for providing direction, support, and review.
+
+## Control Framework and Applicability
+
+BlackDice should maintain a Statement of Applicability that records which controls are applicable, how they are implemented, and where justification exists for exclusion. Control selection should reflect the risk profile of cloud-native service delivery, CI/CD, supplier dependencies, customer data handling, and operational monitoring.
+
+## Document and Record Management
+
+Controlled documents must use the standard metadata block, version control table, and approved storage location. Records generated by ISMS processes must be retained in a way that supports traceability, review, and audit.
+
+## Monitoring, Audit, and Review
+
+The ISMS should be monitored using appropriate measures, including risk status, security events, control exceptions, audit findings, and progress against information security objectives. Internal audit and management review should be conducted at planned intervals, with outputs recorded and tracked to closure.
+
+## Continual Improvement
+
+Nonconformities, incidents, audit findings, and management review actions should feed corrective action and improvement activity. Improvements should be prioritised according to risk, impact, and operational feasibility.
+
+## Related Documents
+
+- ISMS Scope Statement
+- Information Security Policy
+- Risk Assessment and Treatment Methodology
+- Statement of Applicability Template
+- Information Security Objectives Template
+- Document and Records Control Standard
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

00-governance/isms-scope-statement.md

@@ -0,0 +1,104 @@
+Title: ISMS Scope Statement
+Document ID: [GOV-ISMS-SCOPE-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# ISMS Scope Statement
+
+## Purpose
+
+This document defines the intended scope of BlackDice's Information Security Management System (ISMS). It provides the working boundary for risk management, control selection, governance, and assurance activity.
+
+## Scope
+
+The ISMS is intended to cover the people, processes, information, and technology used to design, build, operate, support, and assure BlackDice services within the approved organisational boundary.
+
+The scope is expected to include, where applicable:
+
+- cloud-native SaaS service delivery activities
+- containerised and Kubernetes-based workloads
+- software engineering, code review, build, release, and CI/CD activities
+- security telemetry processing, monitoring, and operational support
+- supplier-supported services and third-party dependencies relevant to service delivery
+- customer assurance, information handling, and security governance activities
+
+## In-Scope Organisational Activities
+
+The following activity groups should be treated as in scope unless explicitly excluded by approved scope decisions:
+
+- product and platform engineering
+- production operations and service support
+- security operations and incident handling
+- corporate functions handling in-scope information assets
+- supplier management for material service providers
+- internal governance, audit, and management review activities
+
+## In-Scope Assets and Information
+
+In-scope assets are expected to include:
+
+- information used to operate, secure, or support BlackDice services
+- source code, build artefacts, and deployment configurations
+- cloud infrastructure, Kubernetes clusters, and supporting management planes
+- endpoints and collaboration systems used to access in-scope information
+- records generated by the ISMS, including risk, incident, exception, and audit records
+
+## Interested Parties and Interfaces
+
+The ISMS should take account of the needs and expectations of relevant interested parties, including:
+
+- BlackDice personnel and contractors
+- customers and prospective customers
+- key suppliers and service providers
+- regulators and supervisory bodies where applicable
+- external auditors and assurance reviewers
+
+Interfaces with customer-managed or operator-hosted environments must be defined during tailoring so that control responsibilities are clear for SaaS and operator-hosted deployment patterns.
+
+## Scope Boundaries and Exclusions
+
+Any exclusions from scope must be explicitly documented, justified, reviewed for risk impact, and approved by [Approval Authority]. Exclusions must not undermine the ability of the ISMS to address material information security risks associated with BlackDice's operating model.
+
+Current exclusions:
+
+- [No exclusions confirmed]
+
+## Assumptions and Constraints
+
+- Legal, contractual, and regulatory obligations remain subject to confirmation and ongoing review.
+- Roles, system names, and ownership assignments will be completed during tailoring.
+- Shared-responsibility boundaries with customers and suppliers may vary by service model and must be documented where relevant.
+
+## Roles and Responsibilities
+
+- The ISMS owner must maintain this scope statement.
+- Process and system owners must identify assets and activities that fall within the approved scope.
+- Management must review proposed scope changes where business, technology, or supplier arrangements materially change.
+
+## Monitoring and Review
+
+This scope statement should be reviewed at least annually and when significant changes occur, including:
+
+- new products or service lines
+- material changes to hosting or deployment models
+- mergers, acquisitions, or organisational restructuring
+- major supplier changes
+- significant regulatory or contractual changes
+
+## Related Documents
+
+- Information Security Policy
+- ISMS Manual
+- Risk Assessment and Treatment Methodology
+- Statement of Applicability Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

00-governance/risk-assessment-and-treatment-methodology.md

@@ -0,0 +1,124 @@
+Title: Risk Assessment and Treatment Methodology
+Document ID: [GOV-RISK-METH-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Risk Assessment and Treatment Methodology
+
+## Purpose
+
+This document defines the method BlackDice should use to identify, assess, treat, accept, and review information security risks within the ISMS scope.
+
+## Scope
+
+This methodology applies to information security risks affecting in-scope business processes, services, systems, suppliers, information assets, and supporting activities.
+
+## Method Overview
+
+Risk assessment should be carried out using a repeatable process that records:
+
+- the asset, service, process, or change under assessment
+- the threat or source of harm
+- the vulnerability or control weakness
+- the potential business or security impact
+- the likelihood of occurrence
+- the resulting risk rating
+- the proposed treatment decision and target state
+- the assigned risk owner and review date
+
+The method should be usable for strategic risks, operational risks, project risks, supplier risks, and control exceptions.
+
+## Risk Identification
+
+Risk identification should consider, where relevant:
+
+- confidentiality, integrity, and availability impacts
+- service resilience and operational disruption
+- customer, contractual, and regulatory obligations
+- cloud platform and Kubernetes security risks
+- CI/CD and software change risks
+- data handling, information transfer, and supplier dependencies
+- human error, misuse, insider threat, and process failure
+
+Risk sources may be identified through workshops, project reviews, architecture changes, audit findings, incidents, supplier reviews, and periodic control assessments.
+
+## Risk Analysis
+
+Likelihood and impact scales must be defined by BlackDice during tailoring. Until then, assessments should use a documented scale such as Low, Medium, and High, or a numeric scale agreed by [Role].
+
+Impact analysis should consider:
+
+- customer harm or service degradation
+- compromise of sensitive or business-critical information
+- legal or contractual consequences
+- financial loss
+- reputational damage
+- recovery effort and operational disruption
+
+## Risk Evaluation
+
+BlackDice must define risk acceptance criteria so assessors can determine whether a risk is:
+
+- acceptable without further treatment
+- acceptable subject to monitoring
+- requiring treatment before acceptance
+- requiring escalation to management
+
+Where risk exceeds the approved tolerance threshold, treatment or formal acceptance by the appropriate authority is required.
+
+## Risk Treatment Options
+
+Risk treatment decisions may include:
+
+- mitigate through new or improved controls
+- avoid by changing the activity or design
+- transfer or share through contractual or insurance mechanisms
+- accept based on informed approval
+
+Treatment plans should identify the actions required, accountable owner, target date, and dependencies.
+
+## Residual Risk and Acceptance
+
+Residual risk must be reassessed after planned treatment has been defined or implemented. Formal risk acceptance must be documented where residual risk remains above routine operating thresholds or where a control gap is knowingly retained.
+
+## Roles and Responsibilities
+
+- The risk methodology owner must maintain this document.
+- Risk owners must ensure risks are assessed and treated appropriately.
+- Assessors must apply the approved method consistently and record sufficient evidence.
+- Management must review significant risks and approve risk acceptance where required.
+
+## Records and Outputs
+
+The primary records produced by this methodology are expected to include:
+
+- risk assessment records
+- risk treatment plans
+- accepted risk decisions
+- updates to the risk register
+- links to related exceptions, incidents, audits, or change records
+
+## Monitoring and Review
+
+Risk assessments should be reviewed at planned intervals and when material change occurs, including major system changes, new suppliers, security incidents, or significant business changes.
+
+The methodology itself should be reviewed at least annually to ensure it remains suitable and proportionate.
+
+## Related Documents
+
+- ISMS Scope Statement
+- Information Security Policy
+- Risk Register Template
+- Risk Assessment Procedure
+- Statement of Applicability Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

00-governance/statement-of-applicability-template.md

@@ -0,0 +1,72 @@
+Title: Statement of Applicability Template
+Document ID: [GOV-SOA-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Statement of Applicability Template
+
+## Purpose
+
+This template provides the structure for recording which information security controls are applicable to BlackDice's ISMS, why they are included or excluded, and how they are implemented.
+
+## Scope
+
+This template applies to the controls selected for the ISMS and should cover the approved control framework used by BlackDice for ISO/IEC 27001:2022 alignment.
+
+## Data Fields / Expected Columns
+
+The Statement of Applicability should record at least the following fields:
+
+- control reference
+- control title
+- applicability status
+- justification for inclusion or exclusion
+- implementation summary
+- related document or evidence reference
+- control owner
+- review date
+
+## Ownership
+
+This document should be owned by [Role]. Control owners must provide implementation detail for controls within their responsibility. Changes should be reviewed as part of risk treatment, audit, and management review activity.
+
+## Update Frequency
+
+The Statement of Applicability should be updated when:
+
+- the control framework changes
+- risks materially change
+- new systems, services, or suppliers alter the control environment
+- control implementation status changes
+- audit or review identifies a required update
+
+At minimum, it should be reviewed annually.
+
+## Retention
+
+Superseded versions should be retained in line with BlackDice's document and records retention requirements.
+
+## Template Table
+
+| Control Reference | Control Title | Applicable (Yes/No) | Justification | Implementation Summary | Related Document / Evidence | Control Owner | Review Date |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| [A.5.x] | [Control title] | [Yes/No] | [Reason] | [How implemented or planned] | [Document ID / record] | [Role] | [DD Month YYYY] |
+
+## Completion Notes
+
+- Exclusions must be explicitly justified.
+- Implementation summaries should be factual and concise.
+- References should point to policies, standards, procedures, or records rather than unsupported statements.
+- Draft entries may identify planned implementation where controls are not yet fully established.
+
+## Related Documents
+
+- ISMS Scope Statement
+- ISMS Manual
+- Information Security Policy
+- Risk Assessment and Treatment Methodology

00-governance/statement-of-applicability.md

@@ -0,0 +1,198 @@
+Title: Statement of Applicability
+Document ID: [GOV-SOA-002]
+Version: 0.2 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Statement of Applicability
+
+## Purpose
+
+This document records the applicability of ISO/IEC 27001:2022 Annex A controls to BlackDice's ISMS and provides a draft rationale for inclusion, document cross-references, implementation status, and evidence references.
+
+## Scope
+
+This Statement of Applicability applies to the BlackDice ISMS scope covering cloud-native SaaS operations, containerised and Kubernetes-based services, software delivery and CI/CD, security telemetry handling, supplier-supported service delivery, and associated business operations within the approved ISMS boundary.
+
+## Basis For Applicability Decisions
+
+This draft assumes that all Annex A controls are applicable to BlackDice at least to some degree because:
+
+- BlackDice is a security-focused SaaS business operating cloud-native services
+- the operating model includes software development, production operations, supplier dependency, customer assurance, and information handling
+- some controls may be delivered partly through shared responsibility with cloud or facility providers, but that does not remove the need to address them in the ISMS
+- the ISMS is being drafted as a practical baseline rather than as a minimal control selection
+
+Where implementation relies partly on supplier arrangements, shared responsibility, or future tailoring, that should be reflected in implementation and evidence notes rather than by excluding the control at this stage.
+
+## Status Key
+
+- `Documented Baseline`: The control is addressed in the current ISMS draft set, but operational evidence and final tailoring still need to be confirmed.
+- `Partially Implemented`: Some documented and operational elements are expected, but evidence, maturity, or consistency still needs validation.
+- `Planned`: A control is recognised as applicable, but its documented and operational approach still needs to be completed.
+
+This draft deliberately avoids claiming full implementation unless that can be evidenced.
+
+## Control Source Note
+
+The Annex A numbering and control titles in this draft were cross-checked against public summaries of ISO/IEC 27001:2022 Annex A and ISO/IEC 27002:2022 structure. The official ISO standard remains the authoritative source for final wording and interpretation.
+
+Sources used for cross-checking control titles:
+
+- ISO Library overview of ISO 27002:2022: https://iso-library.com/standard/27002
+- Bastion Annex A guide: https://bastion.tech/learn/iso27001/annex-a-controls/
+- StudyLib summary of Annex A controls: https://studylib.net/doc/27895509/is0-27001-93-annex-a-controls-pdf
+
+## Organisational Controls
+
+| Control | Title | Applicable | Justification For Inclusion | Implementation Status | Cross-Reference | Draft Implementation Summary | Draft Evidence Reference | Draft Control Owner |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| A.5.1 | Policies for information security | Yes | BlackDice requires formal management direction for information security across its SaaS platform, engineering, and operational activities. | Documented Baseline | Information Security Policy | Top-level information security policy drafted and aligned to the ISMS structure. | `00-governance/information-security-policy.md` | CEO (Paul Hague) |
+| A.5.2 | Information security roles and responsibilities | Yes | Clear security accountability is required across leadership, engineering, operations, and supporting functions. | Documented Baseline | Information Security Policy; ISMS Manual | Governance documents define accountability and metadata ownership across the document set. | `00-governance/information-security-policy.md`; `00-governance/isms-manual.md` | CISO (Paul Jenkins) |
+| A.5.3 | Segregation of duties | Yes | BlackDice operates privileged cloud, CI/CD, and production activities where conflicting duties must be reduced. | Documented Baseline | Access Control Policy; Change Management Policy | Role separation and review expectations are defined at policy level and supported by access and change procedures. | `01-policies/access-control-policy.md`; `01-policies/change-management-policy.md`; `03-procedures/access-review-procedure.md` | CISO (Paul Jenkins) |
+| A.5.4 | Management responsibilities | Yes | Managers must reinforce security expectations and ensure staff follow defined controls. | Documented Baseline | Information Security Policy; Human Resources Security Policy | Management responsibilities are defined in policy and lifecycle controls. | `00-governance/information-security-policy.md`; `01-policies/human-resources-security-policy.md` | CEO (Paul Hague) |
+| A.5.5 | Contact with authorities | Yes | Regulatory, law enforcement, and supervisory contact may be required for incidents, privacy matters, or legal obligations. | Partially Implemented | Incident Response Policy; Privacy and Data Protection Policy | Escalation and notification obligations are documented, but named authority contacts still need tailoring. | `01-policies/incident-response-policy.md`; `01-policies/privacy-and-data-protection-policy.md`; `03-procedures/breach-notification-procedure.md` | CISO (Paul Jenkins) |
+| A.5.6 | Contact with special interest groups | Yes | As a cybersecurity business, BlackDice benefits from timely security knowledge sharing and awareness of emerging threats. | Planned | Information Security Policy | Security information sharing is recognised as relevant, but named groups and routines are not yet defined. | `00-governance/information-security-policy.md` | CISO (Paul Jenkins) |
+| A.5.7 | Threat intelligence | Yes | Threat intelligence is relevant to a security-focused SaaS provider exposed to evolving cyber threats. | Partially Implemented | Logging and Monitoring Policy; Incident Response Policy | Threat awareness is recognised in monitoring and incident handling, but formal threat intelligence workflow still needs tailoring. | `01-policies/logging-and-monitoring-policy.md`; `01-policies/incident-response-policy.md` | CISO (Paul Jenkins) |
+| A.5.8 | Information security in project management | Yes | Projects and change initiatives can introduce security risk if requirements are not addressed from the outset. | Documented Baseline | Secure Development Policy; Change Management Policy | Security requirements are expected in projects and change activity through the documented control set. | `01-policies/secure-development-policy.md`; `01-policies/change-management-policy.md`; `03-procedures/change-approval-procedure.md` | CISO (Paul Jenkins) |
+| A.5.9 | Inventory of information and other associated assets | Yes | BlackDice must know what systems, services, repositories, and information assets are in scope to protect them effectively. | Documented Baseline | Asset Management and Acceptable Use Policy | Asset accountability is documented and supported by a draft asset register template. | `01-policies/asset-management-and-acceptable-use-policy.md`; `04-registers/asset-register-template.md` | CISO (Paul Jenkins) |
+| A.5.10 | Acceptable use of information and other associated assets | Yes | BlackDice staff and contractors use endpoints, code repositories, cloud services, and business systems that require controlled use. | Documented Baseline | Asset Management and Acceptable Use Policy | Acceptable use expectations are defined at policy level for company systems and assets. | `01-policies/asset-management-and-acceptable-use-policy.md` | CISO (Paul Jenkins) |
+| A.5.11 | Return of assets | Yes | Assets, credentials, and related materials must be returned or revoked when personnel leave or change role. | Documented Baseline | Asset Management and Acceptable Use Policy; Human Resources Security Policy | Joiner/mover/leaver and asset return expectations are documented. | `01-policies/asset-management-and-acceptable-use-policy.md`; `01-policies/human-resources-security-policy.md`; `03-procedures/joiner-mover-leaver-procedure.md` | CISO (Paul Jenkins) |
+| A.5.12 | Classification of information | Yes | BlackDice handles information with differing sensitivity, including security, customer, and potentially personal data. | Documented Baseline | Data Classification and Handling Policy | Information classification requirements are defined in policy. | `01-policies/data-classification-and-handling-policy.md` | CISO (Paul Jenkins) |
+| A.5.13 | Labelling of information | Yes | Labelling supports consistent handling and sharing of sensitive information across teams and suppliers. | Partially Implemented | Data Classification and Handling Policy | The policy supports differentiated handling, but specific labelling conventions still need tailoring. | `01-policies/data-classification-and-handling-policy.md` | CISO (Paul Jenkins) |
+| A.5.14 | Information transfer | Yes | Information is transferred between staff, systems, customers, and suppliers and must be protected appropriately. | Documented Baseline | Information Transfer Policy; Data Classification and Handling Policy | Transfer controls are defined at policy level and supported by privacy and classification requirements. | `01-policies/information-transfer-policy.md`; `01-policies/data-classification-and-handling-policy.md` | CISO (Paul Jenkins) |
+| A.5.15 | Access control | Yes | BlackDice relies on controlled access to cloud environments, code, business systems, and customer-relevant information. | Documented Baseline | Access Control Policy; Identity and Authentication Standard | Access control expectations are documented and now explicitly cover stronger authentication, MFA for high-risk access, reduced reliance on standalone passwords, and controlled use of default credentials. | `01-policies/access-control-policy.md`; `02-standards/identity-and-authentication-standard.md`; `03-procedures/access-review-procedure.md` | CISO (Paul Jenkins) |
+| A.5.16 | Identity management | Yes | Workforce and system identities must be managed consistently across SaaS, cloud, and engineering environments. | Documented Baseline | Access Control Policy; Identity and Authentication Standard | Identity management requirements are documented in policy and standard form, including SSO preference, account uniqueness, lifecycle control, and stronger authentication for in-scope access. | `01-policies/access-control-policy.md`; `02-standards/identity-and-authentication-standard.md` | CISO (Paul Jenkins) |
+| A.5.17 | Authentication information | Yes | Credentials, secrets, and related authentication material must be protected to prevent compromise. | Documented Baseline | Access Control Policy; Cryptography and Key Management Policy; Secrets Management Standard | Authentication information and secrets handling are covered by access, cryptography, IAM, and secrets-management controls, including default credential change, password-management expectations, and protection of authentication material. | `01-policies/access-control-policy.md`; `01-policies/cryptography-and-key-management-policy.md`; `02-standards/identity-and-authentication-standard.md`; `02-standards/secrets-management-standard.md` | CISO (Paul Jenkins) |
+| A.5.18 | Access rights | Yes | Access rights must be granted, reviewed, and removed according to business need and least privilege. | Documented Baseline | Access Control Policy; Identity and Authentication Standard | Granting, review, and removal of access are covered by policy, procedure, and standard, including stronger expectations for privileged and high-risk access paths. | `01-policies/access-control-policy.md`; `02-standards/identity-and-authentication-standard.md`; `03-procedures/access-review-procedure.md`; `03-procedures/joiner-mover-leaver-procedure.md` | CISO (Paul Jenkins) |
+| A.5.19 | Information security in supplier relationships | Yes | BlackDice depends on third parties for hosting, tooling, and service support, so supplier security must be managed. | Documented Baseline | Supplier Security Policy | Supplier security expectations are defined and supported by due diligence and review procedures. | `01-policies/supplier-security-policy.md`; `02-standards/supplier-due-diligence-standard.md` | CISO (Paul Jenkins) |
+| A.5.20 | Addressing information security within supplier agreements | Yes | Contractual terms must reflect security, privacy, and notification expectations for suppliers handling important services or data. | Partially Implemented | Supplier Security Policy; Privacy and Data Protection Policy | Requirement is documented, but contract clause set and review checkpoints still need tailoring. | `01-policies/supplier-security-policy.md`; `01-policies/privacy-and-data-protection-policy.md`; `03-procedures/supplier-onboarding-and-review-procedure.md` | CISO (Paul Jenkins) |
+| A.5.21 | Managing information security in the ICT supply chain | Yes | Software, hosting, and other ICT dependencies create supply chain risks relevant to BlackDice's operating model. | Partially Implemented | Supplier Security Policy; Cloud Security Policy | Supply chain risk is recognised in policy and supplier review, but detailed supplier-tiering implementation still needs evidencing. | `01-policies/supplier-security-policy.md`; `01-policies/cloud-security-policy.md`; `02-standards/supplier-due-diligence-standard.md` | CISO (Paul Jenkins) |
+| A.5.22 | Monitoring, review and change management of supplier services | Yes | Supplier risk is not static and must be reassessed as services, assurance status, or incidents change. | Documented Baseline | Supplier Security Policy | Ongoing review is supported by the supplier procedure and supplier register. | `01-policies/supplier-security-policy.md`; `03-procedures/supplier-onboarding-and-review-procedure.md`; `04-registers/supplier-register-template.md` | CISO (Paul Jenkins) |
+| A.5.23 | Information security for use of cloud services | Yes | BlackDice is cloud-native, so cloud security governance is fundamental rather than optional. | Documented Baseline | Cloud Security Policy | Cloud use is directly addressed through the policy and supporting standards. | `01-policies/cloud-security-policy.md`; `02-standards/secure-configuration-standard.md`; `02-standards/kubernetes-security-standard.md` | CISO (Paul Jenkins) |
+| A.5.24 | Information security incident management planning and preparation | Yes | BlackDice needs a planned incident capability for platform, customer, supplier, and security events. | Documented Baseline | Incident Response Policy | Incident planning is supported by policy, procedure, and guidance. | `01-policies/incident-response-policy.md`; `03-procedures/security-incident-handling-procedure.md` | CISO (Paul Jenkins) |
+| A.5.25 | Assessment and decision on information security events | Yes | Security events must be assessed consistently to determine severity, escalation, and response. | Documented Baseline | Incident Response Policy; Logging and Monitoring Policy | Event assessment is addressed in incident handling and monitoring controls. | `01-policies/incident-response-policy.md`; `01-policies/logging-and-monitoring-policy.md`; `03-procedures/security-incident-handling-procedure.md` | CISO (Paul Jenkins) |
+| A.5.26 | Response to information security incidents | Yes | Incident response is required to contain harm, support customers, and restore secure operations. | Documented Baseline | Incident Response Policy | Response arrangements are documented through the incident handling procedure. | `01-policies/incident-response-policy.md`; `03-procedures/security-incident-handling-procedure.md` | CISO (Paul Jenkins) |
+| A.5.27 | Learning from information security incidents | Yes | As a security business, BlackDice should treat incidents as a source of control improvement and operational learning. | Documented Baseline | Incident Response Policy | Post-incident learning and corrective action are built into the procedure set. | `01-policies/incident-response-policy.md`; `03-procedures/security-incident-handling-procedure.md`; `03-procedures/corrective-action-procedure.md` | CISO (Paul Jenkins) |
+| A.5.28 | Collection of evidence | Yes | Evidence may be needed for investigation, audit, legal review, or contractual reporting following incidents. | Partially Implemented | Incident Response Policy; Privacy and Data Protection Policy | Evidence collection is addressed in incident handling, but forensic handling specifics still need tailoring. | `01-policies/incident-response-policy.md`; `03-procedures/security-incident-handling-procedure.md`; `06-audit-and-review/audit-and-review-evidence-log-template.md` | CISO (Paul Jenkins) |
+| A.5.29 | Information security during disruption | Yes | Security requirements continue during service disruption, outages, and crisis conditions. | Documented Baseline | Business Continuity and Disaster Recovery Policy | Security continuity expectations are addressed in continuity and recovery documents. | `01-policies/business-continuity-and-disaster-recovery-policy.md`; `01-policies/incident-response-policy.md` | CISO (Paul Jenkins) |
+| A.5.30 | ICT readiness for business continuity | Yes | BlackDice depends on ICT services and therefore needs recoverability and continuity planning. | Documented Baseline | Business Continuity and Disaster Recovery Policy; Backup and Recovery Policy | Recovery planning and testing are supported by policy and procedures. | `01-policies/business-continuity-and-disaster-recovery-policy.md`; `01-policies/backup-and-recovery-policy.md`; `03-procedures/disaster-recovery-testing-procedure.md` | CISO (Paul Jenkins) |
+| A.5.31 | Legal, statutory, regulatory and contractual requirements | Yes | BlackDice operates in customer and multi-jurisdiction contexts with legal and contractual obligations affecting the ISMS. | Documented Baseline | Privacy and Data Protection Policy; Records Retention and Disposal Policy | A legal obligations register and related policy set are in place as draft controls. | `01-policies/privacy-and-data-protection-policy.md`; `01-policies/records-retention-and-disposal-policy.md`; `04-registers/legal-and-regulatory-obligations-register-template.md` | CISO (Paul Jenkins) |
+| A.5.32 | Intellectual property rights | Yes | BlackDice creates and handles software, content, and other intellectual property that must be protected appropriately. | Partially Implemented | Asset Management and Acceptable Use Policy; Secure Development Policy | IP protection is recognised in asset and development controls, but specific IP handling rules may need further tailoring. | `01-policies/asset-management-and-acceptable-use-policy.md`; `01-policies/secure-development-policy.md` | CISO (Paul Jenkins) |
+| A.5.33 | Protection of records | Yes | The ISMS and business operations rely on records that must remain accurate, protected, and available as needed. | Documented Baseline | Records Retention and Disposal Policy | Record protection, retention, and disposal are addressed in policy and standard form. | `01-policies/records-retention-and-disposal-policy.md`; `00-governance/document-and-records-control-standard.md` | CISO (Paul Jenkins) |
+| A.5.34 | Privacy and protection of personally identifiable information (PII) | Yes | BlackDice may process personal data in customer, supplier, and internal contexts and must protect it appropriately. | Documented Baseline | Privacy and Data Protection Policy; Data Classification and Handling Policy | Privacy expectations are documented and supported by transfer, classification, and retention controls. | `01-policies/privacy-and-data-protection-policy.md`; `01-policies/data-classification-and-handling-policy.md`; `01-policies/information-transfer-policy.md` | CISO (Paul Jenkins) |
+| A.5.35 | Independent review of information security | Yes | Independent review is needed to assess whether the ISMS remains suitable and effective. | Documented Baseline | Information Security Policy; Internal Audit Procedure | Independent review is supported by the audit programme and review artefacts. | `00-governance/information-security-policy.md`; `03-procedures/internal-audit-procedure.md`; `06-audit-and-review/internal-audit-report-template.md` | CISO (Paul Jenkins) |
+| A.5.36 | Compliance with policies, rules and standards for information security | Yes | BlackDice needs oversight of whether documented control requirements are actually being followed. | Documented Baseline | Information Security Policy | Compliance oversight is supported by audit, management review, and corrective action processes. | `00-governance/information-security-policy.md`; `03-procedures/internal-audit-procedure.md`; `03-procedures/management-review-procedure.md` | CISO (Paul Jenkins) |
+| A.5.37 | Documented operating procedures | Yes | Important activities require documented procedures to support repeatability, accountability, and auditability. | Documented Baseline | Information Security Policy; Change Management Policy | Core operational procedures have been drafted for the main ISMS activities. | `03-procedures/` | CISO (Paul Jenkins) |
+
+## People Controls
+
+| Control | Title | Applicable | Justification For Inclusion | Implementation Status | Cross-Reference | Draft Implementation Summary | Draft Evidence Reference | Draft Control Owner |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| A.6.1 | Screening | Yes | Personnel trustworthiness matters because staff may access sensitive systems, data, and security tooling. | Partially Implemented | Human Resources Security Policy | Screening expectations are documented, but exact screening levels and evidence sources still need tailoring. | `01-policies/human-resources-security-policy.md` | CISO (Paul Jenkins) |
+| A.6.2 | Terms and conditions of employment | Yes | Security responsibilities should be reflected in employment or engagement terms. | Partially Implemented | Human Resources Security Policy | Security obligations are documented at policy level, but contract and onboarding wording still need confirmation. | `01-policies/human-resources-security-policy.md`; `03-procedures/joiner-mover-leaver-procedure.md` | CISO (Paul Jenkins) |
+| A.6.3 | Information security awareness, education and training | Yes | Awareness and role-based knowledge are required to reduce avoidable human error and security incidents. | Documented Baseline | Human Resources Security Policy; Information Security Policy | Awareness is documented and supported by the training record template. | `01-policies/human-resources-security-policy.md`; `04-registers/training-and-awareness-record-template.md` | CISO (Paul Jenkins) |
+| A.6.4 | Disciplinary process | Yes | BlackDice needs a defined response where security obligations are knowingly or repeatedly breached. | Partially Implemented | Human Resources Security Policy | Requirement is documented, but exact disciplinary workflow remains an HR tailoring point. | `01-policies/human-resources-security-policy.md` | CISO (Paul Jenkins) |
+| A.6.5 | Responsibilities after termination or change of employment | Yes | Security obligations and access changes continue to matter when people leave or change role. | Documented Baseline | Human Resources Security Policy; Access Control Policy | Leaver and role-change responsibilities are reflected in policy and lifecycle procedure. | `01-policies/human-resources-security-policy.md`; `03-procedures/joiner-mover-leaver-procedure.md` | CISO (Paul Jenkins) |
+| A.6.6 | Confidentiality or non-disclosure agreements | Yes | Personnel may access confidential business, customer, or security information that requires formal protection. | Partially Implemented | Human Resources Security Policy; Privacy and Data Protection Policy | Confidentiality expectations are documented, but template agreements and legal wording still need confirmation. | `01-policies/human-resources-security-policy.md`; `01-policies/privacy-and-data-protection-policy.md` | CISO (Paul Jenkins) |
+| A.6.7 | Remote working | Yes | BlackDice personnel are likely to work remotely and access cloud services outside controlled office environments. | Documented Baseline | Remote Working Policy; Endpoint Security Policy; Identity and Authentication Standard | Remote working controls are documented at policy level and supported by explicit MFA requirements for remote and high-risk access. | `01-policies/remote-working-policy.md`; `01-policies/endpoint-security-policy.md`; `02-standards/identity-and-authentication-standard.md` | CISO (Paul Jenkins) |
+| A.6.8 | Information security event reporting | Yes | Staff must know how to report incidents, weaknesses, and suspicious activity promptly. | Documented Baseline | Incident Response Policy; Human Resources Security Policy | Event reporting expectations are defined in policy and procedure. | `01-policies/incident-response-policy.md`; `03-procedures/security-incident-handling-procedure.md` | CISO (Paul Jenkins) |
+
+## Physical Controls
+
+| Control | Title | Applicable | Justification For Inclusion | Implementation Status | Cross-Reference | Draft Implementation Summary | Draft Evidence Reference | Draft Control Owner |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| A.7.1 | Physical security perimeters | Yes | Even in a cloud-first model, BlackDice uses offices, homes, and third-party facilities where physical boundaries matter. | Documented Baseline | Physical Security Policy | Physical control expectations are documented for offices and third-party environments. | `01-policies/physical-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.2 | Physical entry controls | Yes | Access to offices, storage, and sensitive working areas should be limited to authorised persons. | Partially Implemented | Physical Security Policy | Requirement is documented, but site-specific access mechanisms remain a tailoring point. | `01-policies/physical-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.3 | Securing offices, rooms and facilities | Yes | Work areas and facilities used for business activity require proportionate protection. | Documented Baseline | Physical Security Policy | Physical environment expectations are addressed at policy level. | `01-policies/physical-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.4 | Physical security monitoring | Yes | Physical monitoring may be needed for offices, storage, or other relevant facilities, whether directly managed or supplier-delivered. | Partially Implemented | Physical Security Policy | Monitoring expectation is recognised, but exact arrangements may rely on landlord or supplier controls. | `01-policies/physical-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.5 | Protection against physical and environmental threats | Yes | Fire, power, environmental, and physical hazards can affect BlackDice operations and working locations. | Documented Baseline | Physical Security Policy; Business Continuity and Disaster Recovery Policy | Environmental and resilience concerns are covered in physical and continuity policies. | `01-policies/physical-security-policy.md`; `01-policies/business-continuity-and-disaster-recovery-policy.md` | CISO (Paul Jenkins) |
+| A.7.6 | Working in secure areas | Yes | Some activities or information may require tighter controls over where work is performed or discussed. | Planned | Physical Security Policy | Requirement is recognised, but defined secure-area use cases still need tailoring. | `01-policies/physical-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.7 | Clear desk and clear screen | Yes | Sensitive information can be exposed in shared, remote, or office environments without basic physical discipline. | Documented Baseline | Physical Security Policy; Remote Working Policy | Basic physical information handling expectations are documented. | `01-policies/physical-security-policy.md`; `01-policies/remote-working-policy.md` | CISO (Paul Jenkins) |
+| A.7.8 | Equipment siting and protection | Yes | Endpoints and other equipment need protection against theft, tampering, and accidental damage. | Documented Baseline | Physical Security Policy; Endpoint Security Policy | Device protection expectations are covered for office and remote use. | `01-policies/physical-security-policy.md`; `01-policies/endpoint-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.9 | Security of assets off-premises | Yes | Laptops and other business assets are used away from controlled premises and remain in scope. | Documented Baseline | Remote Working Policy; Endpoint Security Policy | Off-premises asset use is addressed through remote working and endpoint controls. | `01-policies/remote-working-policy.md`; `01-policies/endpoint-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.10 | Storage media | Yes | Media containing business or customer information must be handled, stored, and disposed of securely. | Partially Implemented | Physical Security Policy; Data Classification and Handling Policy | Media handling is recognised, but exact media-use practices still need local tailoring. | `01-policies/physical-security-policy.md`; `01-policies/data-classification-and-handling-policy.md` | CISO (Paul Jenkins) |
+| A.7.11 | Supporting utilities | Yes | Utility disruption can affect office operations and any on-premises supporting capabilities. | Planned | Business Continuity and Disaster Recovery Policy; Physical Security Policy | Utility dependencies are recognised, but direct and supplier-delivered responsibilities still need confirmation. | `01-policies/business-continuity-and-disaster-recovery-policy.md`; `01-policies/physical-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.12 | Cabling security | Yes | Cabling and physical connectivity remain relevant where local office or networking equipment is used. | Planned | Network and Infrastructure Security Policy; Physical Security Policy | Requirement remains applicable where office networking exists, but implementation depends on local environment. | `01-policies/network-and-infrastructure-security-policy.md`; `01-policies/physical-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.13 | Equipment maintenance | Yes | Equipment maintenance can introduce data exposure or integrity risk if not handled securely. | Partially Implemented | Endpoint Security Policy; Physical Security Policy | Maintenance risk is recognised, but maintenance workflow and records still need local definition. | `01-policies/endpoint-security-policy.md`; `01-policies/physical-security-policy.md` | CISO (Paul Jenkins) |
+| A.7.14 | Secure disposal or re-use of equipment | Yes | Devices and equipment may retain data and must be sanitised or disposed of appropriately. | Documented Baseline | Physical Security Policy; Records Retention and Disposal Policy | Disposal expectations are documented at policy level. | `01-policies/physical-security-policy.md`; `01-policies/records-retention-and-disposal-policy.md` | CISO (Paul Jenkins) |
+
+## Technological Controls
+
+| Control | Title | Applicable | Justification For Inclusion | Implementation Status | Cross-Reference | Draft Implementation Summary | Draft Evidence Reference | Draft Control Owner |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| A.8.1 | User endpoint devices | Yes | Staff use endpoints to access critical systems, code, and business information. | Documented Baseline | Endpoint Security Policy; Remote Working Policy; Identity and Authentication Standard | Endpoint control expectations are documented and supported by explicit authentication, MFA, and credential-handling requirements for endpoint-mediated access. | `01-policies/endpoint-security-policy.md`; `01-policies/remote-working-policy.md`; `02-standards/identity-and-authentication-standard.md` | CISO (Paul Jenkins) |
+| A.8.2 | Privileged access rights | Yes | Privileged access to production, cloud, and identity systems is high risk and must be tightly controlled. | Documented Baseline | Access Control Policy; Cloud Security Policy; Identity and Authentication Standard | Privileged access controls are defined at policy and standard level, including mandatory MFA for privileged access and tighter control of administrative identities. | `01-policies/access-control-policy.md`; `01-policies/cloud-security-policy.md`; `02-standards/identity-and-authentication-standard.md` | CISO (Paul Jenkins) |
+| A.8.3 | Information access restriction | Yes | Information access should be limited based on sensitivity, business need, and role. | Documented Baseline | Access Control Policy; Data Classification and Handling Policy; Identity and Authentication Standard | Access restriction is addressed through access, authentication, and classification controls, including stronger expectations for high-risk access paths. | `01-policies/access-control-policy.md`; `01-policies/data-classification-and-handling-policy.md`; `02-standards/identity-and-authentication-standard.md` | CISO (Paul Jenkins) |
+| A.8.4 | Access to source code | Yes | BlackDice develops software, so source code access is a material security concern. | Documented Baseline | Secure Development Policy; Access Control Policy | Source code control is addressed by access and secure development requirements. | `01-policies/secure-development-policy.md`; `01-policies/access-control-policy.md`; `02-standards/secure-code-review-standard.md` | CISO (Paul Jenkins) |
+| A.8.5 | Secure authentication | Yes | Strong authentication is required across cloud, SaaS, and administrative access paths. | Documented Baseline | Access Control Policy; Identity and Authentication Standard | Authentication expectations are explicitly documented, including MFA wherever technically available, mandatory MFA for high-risk access, SSO preference, secure password-management principles, and default credential handling. | `01-policies/access-control-policy.md`; `02-standards/identity-and-authentication-standard.md` | CISO (Paul Jenkins) |
+| A.8.6 | Capacity management | Yes | Capacity issues can affect availability and resilience of customer-facing and internal systems. | Planned | Cloud Security Policy; Business Continuity and Disaster Recovery Policy | Capacity planning is recognised, but specific thresholds and operational evidence still need confirmation. | `01-policies/cloud-security-policy.md`; `01-policies/business-continuity-and-disaster-recovery-policy.md` | CISO (Paul Jenkins) |
+| A.8.7 | Protection against malware | Yes | Malware risk remains relevant across endpoints, tooling, and workloads. | Partially Implemented | Endpoint Security Policy; Cloud Security Policy | Malware protection is expected, but exact endpoint and workload controls still need evidencing. | `01-policies/endpoint-security-policy.md`; `01-policies/cloud-security-policy.md` | CISO (Paul Jenkins) |
+| A.8.8 | Management of technical vulnerabilities | Yes | BlackDice must identify and remediate technical weaknesses affecting systems and services. | Documented Baseline | Vulnerability and Patch Management Policy | Vulnerability identification, tracking, and remediation are documented in policy and procedures. | `01-policies/vulnerability-and-patch-management-policy.md`; `03-procedures/vulnerability-management-procedure.md`; `03-procedures/patch-management-procedure.md` | CISO (Paul Jenkins) |
+| A.8.9 | Configuration management | Yes | Secure and controlled configuration is essential in cloud-native and Kubernetes-based environments. | Documented Baseline | Cloud Security Policy; Network and Infrastructure Security Policy | Configuration management is supported by dedicated standard and related policies. | `02-standards/secure-configuration-standard.md`; `01-policies/cloud-security-policy.md` | CISO (Paul Jenkins) |
+| A.8.10 | Information deletion | Yes | Data must be deleted appropriately when no longer required or where obligations demand it. | Documented Baseline | Records Retention and Disposal Policy; Privacy and Data Protection Policy | Retention and disposal controls provide the draft basis for deletion expectations. | `01-policies/records-retention-and-disposal-policy.md`; `02-standards/data-retention-standard.md` | CISO (Paul Jenkins) |
+| A.8.11 | Data masking | Yes | Masking may be needed where sensitive or personal data is used in support, testing, or shared contexts. | Planned | Privacy and Data Protection Policy; Data Classification and Handling Policy | Data masking is recognised as relevant, but technique and use-case definition still need tailoring. | `01-policies/privacy-and-data-protection-policy.md`; `01-policies/data-classification-and-handling-policy.md` | CISO (Paul Jenkins) |
+| A.8.12 | Data leakage prevention | Yes | BlackDice needs proportionate measures against unauthorised disclosure of sensitive information. | Planned | Data Classification and Handling Policy; Information Transfer Policy | DLP need is recognised, but exact preventive and detective controls remain to be defined. | `01-policies/data-classification-and-handling-policy.md`; `01-policies/information-transfer-policy.md` | CISO (Paul Jenkins) |
+| A.8.13 | Information backup | Yes | Backups are required to support resilience, recovery, and service continuity. | Documented Baseline | Backup and Recovery Policy | Backup control requirements and testing are documented. | `01-policies/backup-and-recovery-policy.md`; `03-procedures/backup-testing-procedure.md` | CISO (Paul Jenkins) |
+| A.8.14 | Redundancy of information processing facilities | Yes | Redundancy may be needed to support service availability and resilience expectations. | Planned | Business Continuity and Disaster Recovery Policy; Cloud Security Policy | Redundancy is recognised, but actual resilience design and evidence still need confirmation. | `01-policies/business-continuity-and-disaster-recovery-policy.md`; `01-policies/cloud-security-policy.md` | CISO (Paul Jenkins) |
+| A.8.15 | Logging | Yes | Security and operational events must be logged to support detection, response, and auditability. | Documented Baseline | Logging and Monitoring Policy | Logging requirements are documented in policy and standard form. | `01-policies/logging-and-monitoring-policy.md`; `02-standards/logging-and-alerting-standard.md` | CISO (Paul Jenkins) |
+| A.8.16 | Monitoring activities | Yes | Monitoring is necessary to identify suspicious activity, failures, and control issues. | Documented Baseline | Logging and Monitoring Policy; Incident Response Policy | Monitoring expectations are documented and linked to incident handling. | `01-policies/logging-and-monitoring-policy.md`; `02-standards/logging-and-alerting-standard.md` | CISO (Paul Jenkins) |
+| A.8.17 | Clock synchronisation | Yes | Reliable timestamps are needed for investigation, event correlation, and evidence integrity. | Planned | Logging and Monitoring Policy | Time integrity is recognised through logging requirements, but specific synchronisation standard still needs tailoring. | `01-policies/logging-and-monitoring-policy.md`; `02-standards/logging-and-alerting-standard.md` | CISO (Paul Jenkins) |
+| A.8.18 | Use of privileged utility programs | Yes | Powerful utilities can bypass normal controls and must be restricted and monitored. | Partially Implemented | Access Control Policy; Network and Infrastructure Security Policy; Identity and Authentication Standard | High-risk utility use is covered by privileged access, MFA, and change controls, though specific utility inventory and monitoring evidence still need tailoring. | `01-policies/access-control-policy.md`; `01-policies/network-and-infrastructure-security-policy.md`; `02-standards/identity-and-authentication-standard.md` | CISO (Paul Jenkins) |
+| A.8.19 | Installation of software on operational systems | Yes | Uncontrolled software installation can create security and stability risks in live environments. | Documented Baseline | Change Management Policy; Endpoint Security Policy | Installation control is covered through change and endpoint requirements, with default credentials and stronger authentication expectations reinforcing administrative control of operational systems. | `01-policies/change-management-policy.md`; `01-policies/endpoint-security-policy.md`; `02-standards/identity-and-authentication-standard.md`; `03-procedures/change-approval-procedure.md` | CISO (Paul Jenkins) |
+| A.8.20 | Networks security | Yes | BlackDice depends on secure network design and protection for service delivery and administration. | Documented Baseline | Network and Infrastructure Security Policy; Cloud Security Policy | Network security expectations are documented through network, cloud, and configuration controls. | `01-policies/network-and-infrastructure-security-policy.md`; `01-policies/cloud-security-policy.md`; `02-standards/secure-configuration-standard.md` | CISO (Paul Jenkins) |
+| A.8.21 | Security of network services | Yes | Network services used internally or delivered by providers must meet security expectations. | Documented Baseline | Network and Infrastructure Security Policy | Network service control expectations are documented at policy level. | `01-policies/network-and-infrastructure-security-policy.md` | CISO (Paul Jenkins) |
+| A.8.22 | Segregation of networks | Yes | Segmentation reduces the impact of compromise and supports environment separation. | Partially Implemented | Network and Infrastructure Security Policy | Segregation is recognised in policy, but actual segmentation patterns still require implementation evidence. | `01-policies/network-and-infrastructure-security-policy.md`; `01-policies/cloud-security-policy.md` | CISO (Paul Jenkins) |
+| A.8.23 | Web filtering | Yes | Web filtering can support protection from malicious sites and inappropriate high-risk browsing. | Planned | Access Control Policy; Endpoint Security Policy | Web filtering remains relevant, but the specific technical approach is still a tailoring point. | `01-policies/access-control-policy.md`; `01-policies/endpoint-security-policy.md` | CISO (Paul Jenkins) |
+| A.8.24 | Use of cryptography | Yes | Encryption and related cryptographic controls are required for modern SaaS, cloud, and data protection. | Documented Baseline | Cryptography and Key Management Policy | Cryptography expectations are documented and supported by secrets and configuration standards. | `01-policies/cryptography-and-key-management-policy.md`; `02-standards/secrets-management-standard.md` | CISO (Paul Jenkins) |
+| A.8.25 | Secure development life cycle | Yes | Security must be integrated into how BlackDice designs, builds, tests, and releases software. | Documented Baseline | Secure Development Policy | Secure SDLC expectations are documented and supported by code review and CI/CD standards. | `01-policies/secure-development-policy.md`; `02-standards/secure-code-review-standard.md`; `02-standards/ci-cd-security-standard.md` | CISO (Paul Jenkins) |
+| A.8.26 | Application security requirements | Yes | Security and privacy requirements should be defined before software changes and service design decisions. | Documented Baseline | Secure Development Policy; Privacy and Data Protection Policy | Security requirements are expected during design and change activity through the development policy set. | `01-policies/secure-development-policy.md`; `01-policies/privacy-and-data-protection-policy.md` | CISO (Paul Jenkins) |
+| A.8.27 | Secure system architecture and engineering principles | Yes | Security by design is required for BlackDice's platform, infrastructure, and engineering decisions. | Partially Implemented | Cloud Security Policy; Secure Development Policy | Secure architecture principles are implied by the policy set, but explicit architecture standard content may still need strengthening. | `01-policies/cloud-security-policy.md`; `01-policies/secure-development-policy.md`; `02-standards/kubernetes-security-standard.md` | CISO (Paul Jenkins) |
+| A.8.28 | Secure coding | Yes | BlackDice develops software and therefore needs explicit expectations for secure coding practice. | Documented Baseline | Secure Development Policy | Secure coding expectations are supported by development policy and code review standard. | `01-policies/secure-development-policy.md`; `02-standards/secure-code-review-standard.md` | CISO (Paul Jenkins) |
+| A.8.29 | Security testing in development and acceptance | Yes | Changes should be tested for security impact before release into live environments. | Documented Baseline | Secure Development Policy; Change Management Policy | Security testing expectation is built into development and deployment control documents. | `01-policies/secure-development-policy.md`; `03-procedures/production-deployment-procedure.md` | CISO (Paul Jenkins) |
+| A.8.30 | Outsourced development | Yes | Outsourced or third-party development, where used, must be governed to avoid introducing unmanaged risk. | Partially Implemented | Supplier Security Policy; Secure Development Policy | Outsourced development risk is recognised, but supplier-specific development controls remain to be tailored if used. | `01-policies/supplier-security-policy.md`; `01-policies/secure-development-policy.md`; `02-standards/supplier-due-diligence-standard.md` | CISO (Paul Jenkins) |
+| A.8.31 | Separation of development, test and production environments | Yes | Environment separation reduces the risk of error, misuse, and unintended production impact. | Documented Baseline | Secure Development Policy; Change Management Policy | Environment separation is included in development and change control expectations. | `01-policies/secure-development-policy.md`; `03-procedures/change-approval-procedure.md`; `03-procedures/production-deployment-procedure.md` | CISO (Paul Jenkins) |
+| A.8.32 | Change management | Yes | BlackDice needs traceable and risk-based control over changes to systems, code, and infrastructure. | Documented Baseline | Change Management Policy | Change management is covered by policy and two supporting procedures. | `01-policies/change-management-policy.md`; `03-procedures/change-approval-procedure.md`; `03-procedures/production-deployment-procedure.md` | CISO (Paul Jenkins) |
+| A.8.33 | Test information | Yes | Test data may expose sensitive information if not controlled appropriately. | Partially Implemented | Data Classification and Handling Policy; Privacy and Data Protection Policy | Test data handling is recognised, but detailed masking and synthetic data rules still need tailoring. | `01-policies/data-classification-and-handling-policy.md`; `01-policies/privacy-and-data-protection-policy.md` | CISO (Paul Jenkins) |
+| A.8.34 | Protection of information systems during audit testing | Yes | Audit or testing activity can affect production services if not planned and controlled carefully. | Documented Baseline | Change Management Policy; Logging and Monitoring Policy | Audit testing risk is covered through change, monitoring, and audit artefact controls. | `01-policies/change-management-policy.md`; `03-procedures/internal-audit-procedure.md`; `06-audit-and-review/internal-audit-working-paper-template.md` | CISO (Paul Jenkins) |
+
+## Overall Draft Position
+
+Draft applicability conclusion:
+
+- Annex A controls reviewed: 93
+- Applicable controls: 93
+- Excluded controls: 0
+
+Draft implementation conclusion:
+
+- Documented Baseline: 65
+- Partially Implemented: 22
+- Planned: 6
+
+The current status reflects a strong documentation baseline but does not yet claim full operational implementation. The next pass should validate evidence, replace draft assumptions with real operational references, and confirm where supplier-delivered or shared-responsibility controls are relied upon.
+
+## Recommended Next SoA Steps
+
+1. Replace draft evidence references with actual system-of-record locations, reports, tickets, or operating evidence.
+2. Confirm whether any controls should be assigned to a function other than the CISO as control owner.
+3. Add an implementation status date and review cadence for each control.
+4. Identify any controls that should move from `Documented Baseline` or `Partially Implemented` to `Implemented` once evidence is confirmed.
+
+## Related Documents
+
+- ISMS Scope Statement
+- Information Security Policy
+- Risk Assessment and Treatment Methodology
+- Statement of Applicability Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft populated with Annex A control applicability, policy cross-references, and inclusion justifications. | ChatGPT |
+| 0.2 Draft | [DD Month YYYY] | Expanded to include implementation status, draft implementation summaries, evidence references, and draft control owners. | ChatGPT |

01-policies/access-control-policy.md

@@ -0,0 +1,77 @@
+Title: Access Control Policy
+Document ID: [POL-ACCESS-001]
+Version: 0.2 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Access Control Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for controlling access to information, systems, services, and administrative interfaces.
+
+## Scope
+
+This policy applies to personnel, contractors, service accounts, systems, cloud platforms, Kubernetes environments, CI/CD systems, endpoints, and third parties within the ISMS scope.
+
+## Objectives
+
+- limit access to authorised users and approved system identities
+- enforce least privilege and need-to-know principles
+- reduce the risk of unauthorised access, misuse, and privilege escalation
+
+## Principles / Policy Statements
+
+Access to information and systems must be granted only where there is an approved business need.
+
+Privileges must be assigned using least privilege and separated where appropriate to reduce the risk of unauthorised or unsafe activity.
+
+Authentication methods must be appropriate to the sensitivity and exposure of the system or service being accessed.
+
+BlackDice should reduce unnecessary reliance on standalone passwords by favouring centrally managed identity, single sign-on, and stronger authentication approaches where practical.
+
+Multi-factor authentication must be used for privileged, remote, cloud administrative, internet-facing, and other high-risk access unless a formally approved exception exists. Where technically available, BlackDice should enable multi-factor authentication more broadly across workforce access.
+
+Default credentials must not remain in use on production or operational systems. Any default password identified on an in-scope system or service must be changed before use.
+
+Privileged access to cloud management planes, production systems, Kubernetes administration, and CI/CD tooling must be subject to stronger control and increased oversight.
+
+Access rights must be reviewed at planned intervals and when roles, responsibilities, or employment status change.
+
+Shared accounts should be avoided unless formally justified, controlled, and traceable.
+
+Where passwords remain necessary, BlackDice should support secure password management practices and avoid relying primarily on complexity rules or routine password expiry as the main control measure.
+
+## Roles and Responsibilities
+
+- [Role] must define and oversee access control requirements.
+- Managers must approve access according to business need.
+- System owners must ensure access models are suitable for their systems.
+- Users must protect their credentials and use access only for authorised purposes.
+
+## Compliance / Exceptions
+
+Exceptions must be documented, risk-assessed, approved, and reviewed through the exception management process.
+
+## Monitoring and Review
+
+Compliance should be monitored through access reviews, joiner-mover-leaver activities, incident handling, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Identity and Authentication Standard
+- Secrets Management Standard
+- Joiner Mover Leaver Procedure
+- Access Review Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |
+| 0.2 Draft | [DD Month YYYY] | Expanded to include explicit MFA, default credential, SSO, and password management principles. | ChatGPT |

01-policies/asset-management-and-acceptable-use-policy.md

@@ -0,0 +1,64 @@
+Title: Asset Management and Acceptable Use Policy
+Document ID: [POL-ASSET-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Asset Management and Acceptable Use Policy
+
+## Purpose
+
+This policy defines BlackDice's expectations for identifying, managing, and using information assets and technology resources appropriately.
+
+## Scope
+
+This policy applies to information, software, cloud resources, endpoints, repositories, collaboration platforms, removable media, and other assets used within the ISMS scope.
+
+## Objectives
+
+- maintain accountability for important assets
+- ensure assets are used appropriately and securely
+- reduce misuse, loss, and uncontrolled exposure of business information
+
+## Principles / Policy Statements
+
+In-scope information assets and supporting technology assets must be identified and assigned an owner.
+
+Assets must be handled in accordance with their classification, business value, and criticality.
+
+BlackDice technology resources must be used only for authorised business purposes unless limited personal use is expressly permitted by [Policy or Role].
+
+Users must not use company assets to bypass security controls, introduce unapproved software, or perform unsafe activity that could affect cloud services, customer data, or corporate systems.
+
+Where assets support cloud-native operations, source code, build artefacts, infrastructure definitions, and deployment configurations must be treated as controlled assets.
+
+## Roles and Responsibilities
+
+- Asset owners must ensure assets are identified, classified, and appropriately protected.
+- Users must use assets responsibly and report loss, misuse, or security concerns.
+- [Role] must oversee the asset management framework.
+
+## Compliance / Exceptions
+
+Non-compliant use may lead to removal of access, investigation, and corrective action. Exceptions must be approved through the defined process.
+
+## Monitoring and Review
+
+This policy should be reviewed alongside asset inventory accuracy, acceptable use issues, incidents, and audit findings.
+
+## Related Documents
+
+- Information Security Policy
+- Data Classification and Handling Policy
+- Asset Register Template
+- Remote Working Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/backup-and-recovery-policy.md

@@ -0,0 +1,64 @@
+Title: Backup and Recovery Policy
+Document ID: [POL-BACKUP-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Backup and Recovery Policy
+
+## Purpose
+
+This policy defines BlackDice's expectations for protecting data and service recoverability through backup and recovery arrangements.
+
+## Scope
+
+This policy applies to in-scope data, configurations, system components, supporting platforms, and recovery information relevant to BlackDice services and business operations.
+
+## Objectives
+
+- maintain recoverability of important data and service components
+- reduce the impact of data loss, corruption, or service disruption
+- ensure recovery arrangements are defined and tested
+
+## Principles / Policy Statements
+
+Backup and recovery arrangements must be defined according to business criticality, recovery needs, and risk.
+
+Backups must be protected against unauthorised access, tampering, loss, and inappropriate deletion.
+
+Cloud-native and Kubernetes-based services must consider recovery of data, configurations, infrastructure definitions, and dependencies needed to restore service.
+
+Recovery requirements should reflect service commitments, business priorities, and operational constraints.
+
+Backup restoration capability must be tested at planned intervals.
+
+## Roles and Responsibilities
+
+- [Role] must define backup and recovery expectations.
+- System owners must ensure required backup and recovery arrangements exist.
+- Operational teams must perform and evidence testing and restoration activity as required.
+
+## Compliance / Exceptions
+
+Any gap in backup coverage or recovery capability must be documented, assessed for risk, and addressed through remediation or approved exception.
+
+## Monitoring and Review
+
+This policy should be reviewed through backup testing, recovery exercises, incidents, change review, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Backup Testing Procedure
+- Business Continuity and Disaster Recovery Policy
+- Data Retention Standard
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/business-continuity-and-disaster-recovery-policy.md

@@ -0,0 +1,64 @@
+Title: Business Continuity and Disaster Recovery Policy
+Document ID: [POL-BCDR-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Business Continuity and Disaster Recovery Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for maintaining continuity of important activities and recovering from disruptive events.
+
+## Scope
+
+This policy applies to in-scope business processes, technology services, supporting suppliers, information assets, and recovery arrangements relevant to BlackDice operations.
+
+## Objectives
+
+- reduce the impact of disruptive events on critical services and operations
+- define recovery priorities and continuity expectations
+- support coordinated response, recovery, and testing
+
+## Principles / Policy Statements
+
+BlackDice must identify critical activities, dependencies, and recovery requirements relevant to in-scope services and business operations.
+
+Continuity and disaster recovery arrangements must consider cloud platform dependencies, operator-hosted patterns where applicable, critical suppliers, and supporting internal processes.
+
+Recovery strategies should be appropriate to service importance, data criticality, and customer commitments.
+
+Plans must be maintained, accessible to authorised responders, and reviewed when material change occurs.
+
+Continuity and disaster recovery arrangements must be tested at planned intervals.
+
+## Roles and Responsibilities
+
+- [Role] must oversee continuity and disaster recovery policy requirements.
+- Process and system owners must define recovery needs and supporting arrangements.
+- Management must support prioritisation, testing, and review.
+
+## Compliance / Exceptions
+
+Gaps in continuity or recovery arrangements must be tracked and addressed through remediation or approved exception.
+
+## Monitoring and Review
+
+This policy should be reviewed through exercises, incidents, service changes, supplier review, and management review.
+
+## Related Documents
+
+- Information Security Policy
+- Backup and Recovery Policy
+- Disaster Recovery Testing Procedure
+- Risk Assessment and Treatment Methodology
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/change-management-policy.md

@@ -0,0 +1,65 @@
+Title: Change Management Policy
+Document ID: [POL-CHANGE-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Change Management Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for managing changes to systems, services, infrastructure, configurations, and processes that may affect security or service integrity.
+
+## Scope
+
+This policy applies to production systems, cloud infrastructure, Kubernetes environments, software releases, CI/CD pipelines, security tooling, and other in-scope changes.
+
+## Objectives
+
+- ensure changes are assessed, authorised, and traceable
+- reduce the risk of unintended security or service impact
+- support safe and repeatable operational change
+
+## Principles / Policy Statements
+
+Changes that may affect information security, resilience, compliance, or customer service must be subject to defined assessment and approval.
+
+The level of review and approval must be proportionate to the risk and impact of the change.
+
+Emergency changes may be implemented where necessary to reduce immediate risk or restore service, but they must be documented and reviewed retrospectively.
+
+Changes to production infrastructure, identity systems, network controls, security tooling, and CI/CD workflows must receive appropriate scrutiny.
+
+Change records must provide enough information to support accountability, rollback planning, and auditability.
+
+## Roles and Responsibilities
+
+- [Role] must define change management expectations.
+- Change owners must ensure changes are documented and approved appropriately.
+- Reviewers and approvers must assess impact, risk, and readiness.
+- Operational teams must implement changes in line with approved controls.
+
+## Compliance / Exceptions
+
+Unauthorised changes are not permitted. Exceptions must be documented and approved through the defined process.
+
+## Monitoring and Review
+
+This policy should be reviewed through change metrics, incidents, failed changes, exceptions, and audit findings.
+
+## Related Documents
+
+- Information Security Policy
+- Secure Development Policy
+- Change Approval Procedure
+- Production Deployment Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/cloud-security-policy.md

@@ -0,0 +1,64 @@
+Title: Cloud Security Policy
+Document ID: [POL-CLOUD-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Cloud Security Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for securing cloud services and cloud-hosted workloads used to deliver and support its business operations.
+
+## Scope
+
+This policy applies to cloud platforms, managed cloud services, cloud administration functions, infrastructure as code, and cloud-hosted workloads within the ISMS scope.
+
+## Objectives
+
+- maintain secure and controlled use of cloud services
+- reduce risk arising from misconfiguration, excessive privilege, and unmanaged change
+- support resilient and auditable cloud-native operations
+
+## Principles / Policy Statements
+
+Cloud services must be selected, configured, and operated according to approved security requirements and risk assessments.
+
+Responsibilities between BlackDice and cloud providers must be understood and reflected in control design.
+
+Production cloud environments, management planes, and supporting automation must be subject to stronger access, change, and monitoring controls.
+
+Security requirements for cloud-native workloads must consider identity, networking, secrets, logging, configuration management, and resilience.
+
+Material cloud architecture changes must be assessed for security impact before implementation.
+
+## Roles and Responsibilities
+
+- [Role] must define cloud security expectations and oversight.
+- Platform and service owners must ensure secure operation of their cloud resources.
+- Engineering and operations teams must implement approved controls in cloud environments.
+
+## Compliance / Exceptions
+
+Cloud control gaps or deviations from baseline requirements must be documented and addressed through remediation or approved exception.
+
+## Monitoring and Review
+
+This policy should be reviewed through configuration assurance, access review, incidents, supplier oversight, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Kubernetes Security Standard
+- Secure Configuration Standard
+- Network and Infrastructure Security Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/cryptography-and-key-management-policy.md

@@ -0,0 +1,64 @@
+Title: Cryptography and Key Management Policy
+Document ID: [POL-CRYPTO-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Cryptography and Key Management Policy
+
+## Purpose
+
+This policy defines BlackDice's expectations for the use of cryptographic controls and the secure management of keys, secrets, and certificates.
+
+## Scope
+
+This policy applies to cryptographic protections used for data at rest, data in transit, identity material, secrets, certificates, and platform integrations within the ISMS scope.
+
+## Objectives
+
+- protect sensitive information using appropriate cryptographic controls
+- reduce the risk of compromise through weak or poorly managed keys and secrets
+- support secure cloud-native and software delivery operations
+
+## Principles / Policy Statements
+
+Cryptographic controls must be selected based on business need, risk, and applicable legal or contractual requirements.
+
+Sensitive information in transit must be protected using approved secure protocols.
+
+Secrets, keys, tokens, and certificates must be generated, stored, rotated, distributed, and revoked using controlled processes.
+
+Hard-coded secrets in source code, CI/CD pipelines, container images, or infrastructure definitions must be prohibited unless explicitly justified and approved.
+
+Access to key and secret management functions must be limited to authorised personnel and systems.
+
+## Roles and Responsibilities
+
+- [Role] must define approved cryptographic requirements.
+- System owners must ensure their services use appropriate protections.
+- Engineering and operations teams must manage secrets and certificates through approved methods.
+
+## Compliance / Exceptions
+
+Any deviation from approved cryptographic or key management practice must be documented and approved as an exception.
+
+## Monitoring and Review
+
+This policy should be reviewed alongside secrets management, certificate issues, incident findings, and control assurance activity.
+
+## Related Documents
+
+- Information Security Policy
+- Secrets Management Standard
+- Secure Configuration Standard
+- Secure Development Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/data-classification-and-handling-policy.md

@@ -0,0 +1,64 @@
+Title: Data Classification and Handling Policy
+Document ID: [POL-DATA-CLASS-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Data Classification and Handling Policy
+
+## Purpose
+
+This policy defines how BlackDice information must be classified, labelled where appropriate, handled, shared, stored, retained, and disposed of.
+
+## Scope
+
+This policy applies to all information created, received, processed, stored, or transmitted within the ISMS scope, regardless of format or location.
+
+## Objectives
+
+- ensure information receives protection appropriate to sensitivity and business need
+- support consistent handling decisions across teams and systems
+- reduce the risk of inappropriate disclosure, alteration, or loss
+
+## Principles / Policy Statements
+
+Information must be classified according to its sensitivity, business impact, legal obligations, and contractual requirements.
+
+Handling requirements must align with the assigned classification and apply to storage, access, transfer, retention, and disposal.
+
+Sensitive information must be protected when used in cloud services, engineering workflows, support processes, and customer assurance activities.
+
+Data exports, logs, telemetry, and support artefacts must be reviewed to avoid unnecessary exposure of sensitive or regulated information.
+
+Information shared with suppliers, customers, or operator-hosted environments must be subject to defined handling requirements and appropriate controls.
+
+## Roles and Responsibilities
+
+- Information owners must assign classifications and handling requirements where appropriate.
+- Users must handle information according to classification and approved process.
+- [Role] must maintain the classification framework.
+
+## Compliance / Exceptions
+
+Exceptions to standard handling requirements must be formally approved where justified by business need and documented risk.
+
+## Monitoring and Review
+
+This policy should be monitored through incident trends, transfer controls, retention practices, supplier review, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Information Transfer Policy
+- Privacy and Data Protection Policy
+- Data Retention Standard
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/endpoint-security-policy.md

@@ -0,0 +1,64 @@
+Title: Endpoint Security Policy
+Document ID: [POL-ENDPOINT-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Endpoint Security Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for securing endpoints used to access company systems and information.
+
+## Scope
+
+This policy applies to laptops, workstations, mobile devices, privileged administration devices, and other endpoints used for in-scope business activity.
+
+## Objectives
+
+- reduce endpoint-related risk to systems and information
+- support secure access to cloud services, code repositories, and administrative interfaces
+- ensure baseline protections are applied consistently
+
+## Principles / Policy Statements
+
+Endpoints used to access in-scope systems or information must be configured and managed according to approved security requirements.
+
+Security baseline controls should address system hardening, authentication, encryption, patching, malware protection, and device lock requirements as appropriate.
+
+Endpoints used for privileged access to production platforms, cloud administration, or customer-sensitive information should receive stronger control and monitoring.
+
+Local storage of sensitive information should be minimised and protected according to classification and business need.
+
+Lost, stolen, or compromised endpoints must be reported promptly.
+
+## Roles and Responsibilities
+
+- [Role] must define endpoint security expectations.
+- Device owners and users must protect endpoints and report security issues promptly.
+- Administrators must maintain required endpoint controls where they are responsible for managed devices.
+
+## Compliance / Exceptions
+
+Use of unmanaged or non-compliant endpoints for in-scope access must be prohibited unless formally approved and risk-assessed.
+
+## Monitoring and Review
+
+This policy should be reviewed through endpoint assurance activity, incidents, vulnerability management, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Remote Working Policy
+- Access Control Policy
+- Vulnerability and Patch Management Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/human-resources-security-policy.md

@@ -0,0 +1,64 @@
+Title: Human Resources Security Policy
+Document ID: [POL-HRSEC-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Human Resources Security Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for managing information security responsibilities throughout the personnel lifecycle.
+
+## Scope
+
+This policy applies to employees, contractors, temporary workers, and other personnel with access to in-scope systems, information, or facilities.
+
+## Objectives
+
+- ensure personnel understand security responsibilities
+- reduce risk during onboarding, role change, and offboarding
+- support confidentiality, acceptable use, and awareness expectations
+
+## Principles / Policy Statements
+
+Personnel with access to in-scope information or systems must be subject to appropriate screening, onboarding, confidentiality, awareness, and offboarding controls where lawful and appropriate.
+
+Access, responsibilities, and training requirements must reflect the role and level of privilege granted.
+
+Joiner, mover, and leaver events must be managed promptly to reduce the risk of inappropriate access retention.
+
+Personnel must understand how to report security incidents, policy concerns, and suspected weaknesses.
+
+Additional measures may be required for privileged roles, security-sensitive functions, or access to customer-sensitive information.
+
+## Roles and Responsibilities
+
+- [Role] must define HR security expectations with relevant business stakeholders.
+- Managers must ensure role changes and departures are communicated promptly.
+- Personnel must comply with security obligations and complete required awareness activities.
+
+## Compliance / Exceptions
+
+Any departure from required lifecycle controls must be documented and approved according to risk.
+
+## Monitoring and Review
+
+This policy should be reviewed through access review, training records, incidents, audit, and management review.
+
+## Related Documents
+
+- Information Security Policy
+- Joiner Mover Leaver Procedure
+- Access Control Policy
+- Training and Awareness Record Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/incident-response-policy.md

@@ -0,0 +1,65 @@
+Title: Incident Response Policy
+Document ID: [POL-INCIDENT-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Incident Response Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for preparing for, reporting, assessing, responding to, and learning from information security incidents.
+
+## Scope
+
+This policy applies to suspected or confirmed security incidents affecting in-scope people, systems, services, suppliers, information, or customers.
+
+## Objectives
+
+- ensure incidents are identified and managed consistently
+- reduce harm through timely containment and response
+- support communication, reporting, and post-incident improvement
+
+## Principles / Policy Statements
+
+Security incidents and suspected security weaknesses must be reported promptly through approved channels.
+
+Incidents must be assessed to determine severity, impact, required response, and escalation needs.
+
+Response arrangements must consider BlackDice's cloud-native services, production environments, telemetry sources, customer impact, and supplier dependencies.
+
+Roles for containment, investigation, communication, and decision-making must be defined and exercised.
+
+Material incidents must result in documented lessons learned and corrective action where appropriate.
+
+## Roles and Responsibilities
+
+- [Role] must oversee incident response arrangements.
+- Personnel must report incidents and cooperate with response activity.
+- Service and system owners must support containment and recovery for their environments.
+- Management must support escalation, communication, and review.
+
+## Compliance / Exceptions
+
+Any deviation from required incident handling expectations must be documented and approved where practicable. Emergency actions taken during incident response must be recorded retrospectively.
+
+## Monitoring and Review
+
+This policy should be reviewed through incident trends, exercises, post-incident reviews, audit, and management review.
+
+## Related Documents
+
+- Information Security Policy
+- Security Incident Handling Procedure
+- Breach Notification Procedure
+- Corrective Action Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/information-transfer-policy.md

@@ -0,0 +1,64 @@
+Title: Information Transfer Policy
+Document ID: [POL-TRANSFER-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Information Transfer Policy
+
+## Purpose
+
+This policy defines BlackDice's requirements for transferring information securely between internal teams, customers, suppliers, and other authorised parties.
+
+## Scope
+
+This policy applies to electronic and physical information transfer involving in-scope information, including customer communications, support processes, supplier exchanges, and operational data sharing.
+
+## Objectives
+
+- protect information during transfer against unauthorised access or loss
+- ensure transfers are appropriate to classification and business need
+- reduce risk in cross-organisational and multi-jurisdiction exchanges
+
+## Principles / Policy Statements
+
+Information must only be transferred where there is a legitimate business need and an approved transfer method appropriate to the information's sensitivity.
+
+Transfer mechanisms for sensitive information must include suitable protections such as access restriction, encryption, integrity assurance, and recipient validation where appropriate.
+
+Operational data shared with suppliers, customers, or operator-hosted environments must be limited to what is necessary and handled according to agreed requirements.
+
+Transfers that may involve legal, regulatory, or contractual obligations must be assessed and approved through the relevant process.
+
+Unauthorised use of personal email, consumer file-sharing, or other unapproved channels for sensitive business information must be prohibited.
+
+## Roles and Responsibilities
+
+- [Role] must define information transfer expectations.
+- Information owners must approve transfer arrangements where required.
+- Users must use approved methods and verify recipients before sharing sensitive information.
+
+## Compliance / Exceptions
+
+Exceptions to standard transfer controls must be documented, justified, and approved based on risk and business need.
+
+## Monitoring and Review
+
+This policy should be reviewed through incident analysis, supplier review, privacy review, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Data Classification and Handling Policy
+- Privacy and Data Protection Policy
+- Supplier Security Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/logging-and-monitoring-policy.md

@@ -0,0 +1,64 @@
+Title: Logging and Monitoring Policy
+Document ID: [POL-LOGGING-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Logging and Monitoring Policy
+
+## Purpose
+
+This policy defines BlackDice's expectations for generating, protecting, reviewing, and using logs and monitoring data to support security and operational oversight.
+
+## Scope
+
+This policy applies to in-scope applications, cloud services, Kubernetes environments, endpoints, identity systems, CI/CD platforms, and security monitoring processes.
+
+## Objectives
+
+- support detection of security events and operational issues
+- provide evidence for investigation, review, and assurance
+- protect monitoring data against unauthorised access or tampering
+
+## Principles / Policy Statements
+
+Logging and monitoring must be proportionate to the risk and criticality of the relevant service or system.
+
+Security-relevant activities should be logged where feasible, including authentication events, privileged actions, administrative changes, and significant production or security events.
+
+Logging arrangements for cloud-native and containerised services must consider distributed architectures, ephemeral workloads, and centralised analysis needs.
+
+Logs and telemetry that may contain sensitive information must be handled and retained according to approved requirements.
+
+Alerting and monitoring processes must support timely review and escalation of material issues.
+
+## Roles and Responsibilities
+
+- [Role] must define monitoring expectations and oversight arrangements.
+- System owners must ensure adequate logging exists for their services.
+- Operational teams must review alerts and respond through defined processes.
+
+## Compliance / Exceptions
+
+Gaps in required logging or monitoring coverage must be tracked, risk-assessed, and remediated or formally accepted.
+
+## Monitoring and Review
+
+This policy should be reviewed through control testing, incident handling, alert tuning, audit, and management review.
+
+## Related Documents
+
+- Information Security Policy
+- Logging and Alerting Standard
+- Security Incident Handling Procedure
+- Incident Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/network-and-infrastructure-security-policy.md

@@ -0,0 +1,64 @@
+Title: Network and Infrastructure Security Policy
+Document ID: [POL-NETINFRA-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Network and Infrastructure Security Policy
+
+## Purpose
+
+This policy defines BlackDice's expectations for securing networks, infrastructure components, and supporting platform services.
+
+## Scope
+
+This policy applies to cloud networking, connectivity, infrastructure services, administrative access paths, supporting compute resources, and related management components within the ISMS scope.
+
+## Objectives
+
+- protect infrastructure and network pathways from unauthorised access or misuse
+- support segmentation, resilience, and controlled administration
+- reduce exposure from insecure configurations and unmanaged services
+
+## Principles / Policy Statements
+
+Infrastructure and network services must be designed and operated according to approved security requirements.
+
+Administrative interfaces and management paths must be restricted, monitored, and protected with stronger controls.
+
+Network exposure should be minimised according to business need, and externally accessible services must receive appropriate protection and review.
+
+Infrastructure security arrangements must consider cloud-native service patterns, container orchestration dependencies, and operator-facing deployment requirements where applicable.
+
+Changes to network and infrastructure controls must be subject to defined assessment and approval.
+
+## Roles and Responsibilities
+
+- [Role] must define infrastructure and network security expectations.
+- Platform and infrastructure owners must maintain secure configurations and access controls.
+- Operational teams must monitor and manage infrastructure risks.
+
+## Compliance / Exceptions
+
+Exceptions must be documented and approved where baseline infrastructure or network requirements cannot be met.
+
+## Monitoring and Review
+
+This policy should be reviewed through configuration reviews, vulnerability management, incident analysis, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Cloud Security Policy
+- Secure Configuration Standard
+- Change Management Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/physical-security-policy.md

@@ -0,0 +1,64 @@
+Title: Physical Security Policy
+Document ID: [POL-PHYSICAL-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Physical Security Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for protecting physical environments, assets, and information from unauthorised physical access, damage, or interference.
+
+## Scope
+
+This policy applies to offices, shared workspaces, storage areas, endpoint handling, and any other physical locations or facilities used for in-scope business activity. It also applies, where relevant, to third-party facilities that support in-scope operations.
+
+## Objectives
+
+- reduce risk arising from unauthorised physical access or asset loss
+- protect equipment and information used in business operations
+- support secure working across office, remote, and supplier-hosted environments
+
+## Principles / Policy Statements
+
+Physical access to locations handling sensitive information or important technology assets must be controlled according to risk and business need.
+
+Equipment and media containing sensitive information must be protected from theft, loss, damage, or unauthorised use.
+
+BlackDice must consider physical risks associated with office environments, remote working, shipped equipment, and any third-party hosting or operational facilities relevant to in-scope services.
+
+Clear desk, screen protection, visitor control, and secure disposal practices should be applied where appropriate to the working environment and information handled.
+
+Physical security responsibilities for supplier or cloud-hosted facilities must be understood as part of supplier and shared-responsibility arrangements.
+
+## Roles and Responsibilities
+
+- [Role] must define physical security expectations.
+- Location and asset owners must apply physical protections appropriate to their environments.
+- Personnel must protect assets and information from avoidable physical exposure.
+
+## Compliance / Exceptions
+
+Exceptions to required physical security measures must be documented and approved according to risk.
+
+## Monitoring and Review
+
+This policy should be reviewed through incidents, asset issues, supplier assurance, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Remote Working Policy
+- Asset Management and Acceptable Use Policy
+- Supplier Security Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/privacy-and-data-protection-policy.md

@@ -0,0 +1,64 @@
+Title: Privacy and Data Protection Policy
+Document ID: [POL-PRIVACY-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Privacy and Data Protection Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level approach to protecting personal data and supporting privacy obligations in the context of its ISMS.
+
+## Scope
+
+This policy applies to personal data processed within the ISMS scope, including data handled in business operations, customer service delivery, supplier relationships, and internal administration.
+
+## Objectives
+
+- support lawful, fair, and appropriate handling of personal data
+- reduce the risk of privacy harm, data misuse, and regulatory issue
+- ensure privacy considerations are reflected in security and operational practice
+
+## Principles / Policy Statements
+
+Personal data must be handled in accordance with applicable legal, regulatory, and contractual requirements.
+
+Collection, access, use, sharing, retention, and disposal of personal data must be limited to legitimate and authorised purposes.
+
+Privacy and security considerations must be considered when designing or changing services, processes, and supplier arrangements that may affect personal data.
+
+Where BlackDice operates across multiple jurisdictions or customer environments, applicable privacy obligations and transfer considerations must be identified and managed.
+
+Potential personal data breaches must be escalated promptly for assessment and response.
+
+## Roles and Responsibilities
+
+- [Role] must oversee privacy and data protection requirements relevant to the ISMS.
+- Process and system owners must identify where personal data is handled and apply appropriate controls.
+- Personnel must handle personal data only for authorised purposes and report concerns promptly.
+
+## Compliance / Exceptions
+
+No exception may override applicable legal obligations. Any control deviation must be reviewed with appropriate stakeholders and approved where lawful and justified.
+
+## Monitoring and Review
+
+This policy should be reviewed through breach handling, supplier review, risk assessment, legal change monitoring, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Data Classification and Handling Policy
+- Information Transfer Policy
+- Breach Notification Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/records-retention-and-disposal-policy.md

@@ -0,0 +1,64 @@
+Title: Records Retention and Disposal Policy
+Document ID: [POL-RECORDS-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Records Retention and Disposal Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for retaining and disposing of business and ISMS records in a controlled manner.
+
+## Scope
+
+This policy applies to records created or maintained within the ISMS scope, including governance records, risk records, incident records, audit outputs, supplier records, and supporting operational evidence.
+
+## Objectives
+
+- retain records for as long as required by business, legal, contractual, and assurance needs
+- dispose of records securely when retention is no longer required
+- support traceability, evidence, and defensible record handling
+
+## Principles / Policy Statements
+
+Records must be retained according to defined retention requirements that reflect legal, regulatory, contractual, operational, and assurance needs.
+
+Records must remain accessible, accurate, and protected for the duration of their retention period.
+
+Disposal of records must be controlled and appropriate to the sensitivity of the information involved.
+
+ISMS records such as risks, incidents, audit findings, management reviews, and exceptions must be retained in a way that supports oversight and auditability.
+
+Where operational tooling is used as the system of record, retention and disposal arrangements must be understood and controlled.
+
+## Roles and Responsibilities
+
+- [Role] must define retention and disposal expectations.
+- Record owners must ensure records are retained and disposed of appropriately.
+- System owners must support retention controls where records are stored in business systems.
+
+## Compliance / Exceptions
+
+Any exception to approved retention or disposal requirements must be documented and approved by the relevant authority.
+
+## Monitoring and Review
+
+This policy should be reviewed through record sampling, legal change monitoring, audit, and management review.
+
+## Related Documents
+
+- Information Security Policy
+- Document and Records Control Standard
+- Data Retention Standard
+- Legal and Regulatory Obligations Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/remote-working-policy.md

@@ -0,0 +1,64 @@
+Title: Remote Working Policy
+Document ID: [POL-REMOTE-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Remote Working Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for secure remote and hybrid working.
+
+## Scope
+
+This policy applies to personnel and contractors working remotely or outside controlled office locations while accessing in-scope systems, information, or services.
+
+## Objectives
+
+- reduce the risk of compromise associated with remote access and off-site working
+- support secure access to cloud platforms, code repositories, and business systems
+- protect information handled outside controlled premises
+
+## Principles / Policy Statements
+
+Remote working arrangements must use approved access methods and appropriate endpoint security controls.
+
+Personnel working remotely must take reasonable steps to protect devices, credentials, and information from unauthorised access, observation, theft, or loss.
+
+Use of public or shared environments must be managed carefully, particularly where sensitive information, privileged access, or customer-related work is involved.
+
+Remote administration of production systems, cloud environments, and CI/CD platforms must be subject to stronger control and monitoring.
+
+Local printing, storage, or transfer of sensitive information should be minimised and controlled.
+
+## Roles and Responsibilities
+
+- [Role] must define remote working security expectations.
+- Managers must ensure remote workers understand their obligations.
+- Remote workers must follow approved security practices and report issues promptly.
+
+## Compliance / Exceptions
+
+Exceptions to remote working requirements must be documented and approved based on risk and business need.
+
+## Monitoring and Review
+
+This policy should be reviewed through endpoint assurance, access review, incident handling, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Endpoint Security Policy
+- Access Control Policy
+- Asset Management and Acceptable Use Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/secure-development-policy.md

@@ -0,0 +1,64 @@
+Title: Secure Development Policy
+Document ID: [POL-SECDEV-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Secure Development Policy
+
+## Purpose
+
+This policy defines BlackDice's high-level requirements for integrating security into software design, development, testing, and release activities.
+
+## Scope
+
+This policy applies to source code, infrastructure as code, build pipelines, code review, deployment workflows, and related engineering activities within the ISMS scope.
+
+## Objectives
+
+- reduce security defects introduced during development
+- ensure security is considered throughout the software lifecycle
+- support safe and repeatable change in cloud-native environments
+
+## Principles / Policy Statements
+
+Security requirements must be considered during design, development, testing, and release planning.
+
+Changes to source code, application configuration, infrastructure definitions, and deployment pipelines must be subject to controlled review and approval.
+
+Code changes affecting authentication, authorisation, data handling, cryptography, logging, or externally exposed services should receive additional security scrutiny.
+
+Build and release processes must be designed to reduce the risk of unauthorised change, insecure dependencies, or unsafe deployment to production environments.
+
+Development and test practices must be appropriate for BlackDice's cloud-native SaaS and Kubernetes-based operating model.
+
+## Roles and Responsibilities
+
+- Engineering leadership must ensure secure development expectations are embedded into delivery practices.
+- Developers must follow approved secure coding and review requirements.
+- [Role] must define supporting standards and assurance expectations.
+
+## Compliance / Exceptions
+
+Exceptions to required development controls must be documented, approved, and reviewed based on risk.
+
+## Monitoring and Review
+
+This policy should be monitored through code review records, pipeline assurance, vulnerability trends, incidents, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- CI/CD Security Standard
+- Secure Code Review Standard
+- Change Management Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/supplier-security-policy.md

@@ -0,0 +1,64 @@
+Title: Supplier Security Policy
+Document ID: [POL-SUPPLIER-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Supplier Security Policy
+
+## Purpose
+
+This policy defines BlackDice's requirements for assessing and managing information security risk arising from suppliers and third-party service providers.
+
+## Scope
+
+This policy applies to suppliers that provide technology, hosting, development support, operational services, data processing, or other services relevant to the ISMS scope.
+
+## Objectives
+
+- manage supplier-related security and resilience risk
+- ensure supplier controls are proportionate to service criticality and information sensitivity
+- support ongoing oversight of important third-party relationships
+
+## Principles / Policy Statements
+
+Suppliers must be assessed for information security risk before onboarding where they support in-scope services or handle relevant information.
+
+The level of due diligence, contracting, and ongoing review must reflect the supplier's role, access, criticality, and risk.
+
+Shared responsibility boundaries with cloud providers, operator-hosted environments, and specialist security or telemetry providers must be understood and documented.
+
+Supplier arrangements should define relevant security expectations, notification obligations, and rights of review or assurance where appropriate.
+
+Material supplier changes, incidents, or control concerns must trigger reassessment.
+
+## Roles and Responsibilities
+
+- [Role] must oversee the supplier security framework.
+- Supplier owners must ensure due diligence and review activities are completed.
+- Procurement, legal, and operational stakeholders must support security review where applicable.
+
+## Compliance / Exceptions
+
+Onboarding or continued use of a supplier without required review must be risk-assessed and approved as an exception where unavoidable.
+
+## Monitoring and Review
+
+This policy should be monitored through supplier reviews, assurance evidence, incidents, contract changes, and audit.
+
+## Related Documents
+
+- Information Security Policy
+- Supplier Due Diligence Standard
+- Supplier Onboarding and Review Procedure
+- Supplier Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

01-policies/vulnerability-and-patch-management-policy.md

@@ -0,0 +1,64 @@
+Title: Vulnerability and Patch Management Policy
+Document ID: [POL-VULN-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CEO (Paul Hague)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Vulnerability and Patch Management Policy
+
+## Purpose
+
+This policy defines BlackDice's expectations for identifying, assessing, prioritising, remediating, and tracking vulnerabilities and security patches.
+
+## Scope
+
+This policy applies to applications, cloud infrastructure, containers, Kubernetes components, endpoints, dependencies, and third-party software within the ISMS scope.
+
+## Objectives
+
+- reduce exposure to known vulnerabilities
+- apply patches and remediation actions within risk-based timeframes
+- maintain visibility of unresolved security weaknesses
+
+## Principles / Policy Statements
+
+BlackDice must maintain processes to identify vulnerabilities affecting in-scope systems and services.
+
+Vulnerabilities and missing security patches must be assessed according to business context, exploitability, exposure, and potential impact.
+
+Production-facing cloud workloads, externally exposed services, CI/CD components, and identity systems should receive prioritised remediation attention.
+
+Where immediate remediation is not possible, compensating controls, formal risk acceptance, or time-bound exceptions must be considered and recorded.
+
+Remediation activity must be tracked to closure and supported by appropriate evidence.
+
+## Roles and Responsibilities
+
+- [Role] must oversee vulnerability management requirements.
+- System and service owners must remediate issues affecting their assets.
+- Management must support prioritisation where remediation requires planned change or resource allocation.
+
+## Compliance / Exceptions
+
+Deferred remediation must be justified, recorded, approved where required, and reviewed until closure.
+
+## Monitoring and Review
+
+This policy should be monitored through vulnerability reporting, patch timeliness, exception tracking, incidents, and audit findings.
+
+## Related Documents
+
+- Information Security Policy
+- Vulnerability Management Procedure
+- Patch Management Procedure
+- Secure Configuration Standard
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

02-standards/ci-cd-security-standard.md

@@ -0,0 +1,70 @@
+Title: CI/CD Security Standard
+Document ID: [STD-CICD-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# CI/CD Security Standard
+
+## Purpose
+
+This standard defines the minimum security requirements for continuous integration, continuous delivery, and automated build and deployment workflows.
+
+## Scope
+
+This standard applies to source control integrations, build systems, test pipelines, artefact repositories, deployment automation, and related engineering workflow components within the ISMS scope.
+
+## Mandatory Requirements
+
+CI/CD systems must be access-controlled and restricted to authorised users, services, and automation identities.
+
+Changes to pipeline definitions, build configurations, deployment workflows, and release automation must be subject to review and approval.
+
+Build and deployment workflows must provide traceability between approved source changes, generated artefacts, and deployed outputs.
+
+Secrets used by CI/CD systems must be managed according to the approved secrets management approach and must not be exposed through pipeline logs or insecure configuration.
+
+Production deployment paths must include appropriate separation of duties, approval, or equivalent compensating control based on risk.
+
+Build environments and runners must be managed and hardened according to approved configuration and access requirements.
+
+Pipeline activity, administrative changes, and failed or unusual security-relevant events should be logged and reviewed where appropriate.
+
+Artefacts promoted to production should originate from approved and traceable build processes.
+
+## Implementation Guidance
+
+BlackDice should design CI/CD controls to support rapid engineering while preserving change integrity and production safety.
+
+The standard should be applied consistently to application code, infrastructure as code, policy-as-code, and deployment configuration where these contribute to service delivery.
+
+Where third-party hosted build or deployment services are used, supplier and shared-responsibility considerations should be documented.
+
+Higher-risk deployment paths, including production and security-sensitive platform changes, should receive stronger approval and monitoring controls.
+
+## Roles and Responsibilities
+
+- [Role] must define CI/CD security expectations.
+- Engineering and platform owners must implement compliant pipeline controls.
+- Approvers and reviewers must assess high-risk changes before production deployment.
+
+## Exceptions
+
+Exceptions must be documented, justified, risk-assessed, approved, and reviewed.
+
+## Related Documents
+
+- Secure Development Policy
+- Change Management Policy
+- Secrets Management Standard
+- Secure Code Review Standard
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

02-standards/data-retention-standard.md

@@ -0,0 +1,68 @@
+Title: Data Retention Standard
+Document ID: [STD-RETENTION-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Data Retention Standard
+
+## Purpose
+
+This standard defines the minimum requirements for setting, applying, and evidencing data and record retention periods.
+
+## Scope
+
+This standard applies to business information, personal data, logs, telemetry, backups, audit evidence, and ISMS records within the ISMS scope.
+
+## Mandatory Requirements
+
+Retention periods must be defined for relevant information and record categories based on legal, regulatory, contractual, operational, and assurance needs.
+
+Data and records must not be retained longer than necessary without documented justification.
+
+Retention requirements must take account of the information's classification, purpose, system of record, and recovery or investigation needs.
+
+Where automated deletion or archival controls are used, they must be configured, reviewed, and monitored appropriately.
+
+Backups, logs, and derived operational data must be subject to retention rules that are consistent with their purpose and risk profile.
+
+Disposal at the end of the retention period must be carried out securely and in a manner appropriate to the medium and sensitivity involved.
+
+Changes to retention requirements must be reviewed with relevant stakeholders where legal, privacy, customer, or audit implications may arise.
+
+## Implementation Guidance
+
+BlackDice should maintain a retention schedule or equivalent reference that links information categories to retention periods, disposal expectations, and ownership.
+
+Where data exists in multiple systems, the authoritative retention rule and system of record should be clear.
+
+Retention design should consider the practical realities of cloud-native operations, including distributed logs, backups, telemetry stores, and supplier-managed data locations.
+
+If a required retention period cannot be enforced technically, compensating governance and manual review should be defined until remediation is possible.
+
+## Roles and Responsibilities
+
+- [Role] must define retention standards and coordinate updates.
+- Record and data owners must ensure retention rules are applied to their information sets.
+- System owners must implement feasible technical controls to support retention and disposal.
+
+## Exceptions
+
+Exceptions must be documented, justified, risk-assessed, approved, and reviewed.
+
+## Related Documents
+
+- Records Retention and Disposal Policy
+- Privacy and Data Protection Policy
+- Logging and Alerting Standard
+- Backup and Recovery Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

02-standards/identity-and-authentication-standard.md

@@ -0,0 +1,98 @@
+Title: Identity and Authentication Standard
+Document ID: [STD-IAM-001]
+Version: 0.2 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Identity and Authentication Standard
+
+## Purpose
+
+This standard defines the minimum requirements for identity lifecycle control, authentication strength, and account management within the ISMS scope.
+
+## Scope
+
+This standard applies to user accounts, administrative accounts, service accounts, machine identities, authentication systems, and identity integrations used by BlackDice.
+
+## Mandatory Requirements
+
+All accounts must be uniquely identifiable to an individual user or controlled system identity unless an approved exception exists.
+
+Access must be provisioned through an approved process based on authorised business need.
+
+Authentication mechanisms must be appropriate to the sensitivity and exposure of the system or service.
+
+Wherever technically available, multi-factor authentication must be enabled for workforce, privileged, administrative, remote, cloud, and other in-scope access paths unless a formally approved exception exists.
+
+Multi-factor authentication must be used for privileged access, remote access, cloud management access, internet-facing systems, and other high-risk access paths unless formally exempted.
+
+Where practical, BlackDice should reduce reliance on standalone passwords by using single sign-on, federated identity, hardware-backed methods, or other stronger authentication mechanisms.
+
+Password-based authentication must not rely primarily on password complexity rules or frequent mandatory password changes as the main security control.
+
+Where user-chosen passwords are used, systems should support strong password selection through minimum length expectations, deny-listing of common or compromised passwords, and controls against brute-force or password-spraying attacks.
+
+Passwords must be changed when compromise is known or suspected, when required by a role change or credential exposure event, or when a system-specific risk assessment requires it.
+
+BlackDice should provide or approve secure password management mechanisms where passwords remain necessary at scale. Use of approved password managers should be encouraged where appropriate.
+
+Default credentials must be changed or disabled before systems are placed into operational use.
+
+Any default vendor-supplied password identified on a production or operationally relevant system, service, device, or administrative component must be changed before use and notified to the CISO.
+
+Privileged accounts must be restricted, monitored, and reviewed more closely than standard user accounts.
+
+Service accounts and machine identities must be limited to the permissions required for their defined purpose and must not be used for interactive activity unless explicitly justified.
+
+Authentication secrets must be protected in line with the approved secrets management approach.
+
+Account access must be reviewed at defined intervals and promptly updated for role changes, departures, or identified misuse.
+
+Dormant, temporary, emergency, and shared accounts must be controlled, documented, and removed or disabled when no longer required.
+
+## Implementation Guidance
+
+BlackDice should centralise identity control where practical to improve consistency, traceability, and joiner-mover-leaver handling.
+
+Authentication decisions should consider user population, deployment model, administrative exposure, and customer or supplier integration patterns.
+
+Single sign-on should be preferred for workforce access where it improves consistency and reduces password burden. Where SSO is used, it should itself be protected by multi-factor authentication.
+
+Where password-based login remains necessary, BlackDice should favour approaches aligned with recognised good practice, including reducing password overload, supporting password managers, and using technical controls such as throttling, lockout, or monitoring rather than depending on user memory of complex passwords.
+
+For cloud-native and Kubernetes-based operations, identity design should cover workforce access, platform administration, automation identities, pipeline identities, and workload-to-service authentication as distinct control areas.
+
+Systems that cannot meet the standard directly should be isolated, monitored, and subject to compensating controls pending remediation or replacement.
+
+## Roles and Responsibilities
+
+- [Role] must define identity and authentication control requirements.
+- Managers and access approvers must validate business need before access is granted.
+- System owners must ensure their systems implement the required controls.
+- Users must protect authentication credentials and report suspected compromise promptly.
+
+## Exceptions
+
+Exceptions must be documented, justified, risk-assessed, approved, and reviewed through the exception management process.
+
+## Related Documents
+
+- Access Control Policy
+- Cloud Security Policy
+- Access Review Procedure
+- Joiner Mover Leaver Procedure
+
+## External Reference
+
+- UK National Cyber Security Centre, "Password policy: updating your approach": https://www.ncsc.gov.uk/collection/passwords/updating-your-approach
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |
+| 0.2 Draft | [DD Month YYYY] | Expanded to include explicit password management, MFA, SSO, and default credential requirements aligned with NCSC guidance. | ChatGPT |

02-standards/kubernetes-security-standard.md

@@ -0,0 +1,70 @@
+Title: Kubernetes Security Standard
+Document ID: [STD-K8S-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Kubernetes Security Standard
+
+## Purpose
+
+This standard defines the minimum requirements for securing Kubernetes clusters, workloads, and supporting control planes used within the ISMS scope.
+
+## Scope
+
+This standard applies to Kubernetes clusters, namespaces, workloads, controllers, configuration manifests, ingress paths, secrets usage, administrative access, and supporting operational components.
+
+## Mandatory Requirements
+
+Access to Kubernetes control planes, cluster administration functions, and production namespaces must be restricted to authorised personnel and systems.
+
+Role-based access controls must be defined and maintained to limit privileges according to operational need.
+
+Cluster and workload configuration must follow approved security baselines, including restrictions on overly permissive settings and unnecessary privilege.
+
+Secrets used by workloads must be managed through approved secrets management processes and must not be embedded insecurely in manifests or images.
+
+Network exposure and service-to-service connectivity must be controlled according to business need and risk.
+
+Cluster changes and workload deployments must be subject to approved change and deployment controls.
+
+Security-relevant cluster events and administrative activity must be logged and monitored where feasible.
+
+Workloads, images, and supporting components must be maintained in line with vulnerability and patch management expectations.
+
+## Implementation Guidance
+
+BlackDice should apply this standard in a way that reflects its use of containerised services, automation pipelines, and potentially different deployment models across SaaS and operator-hosted environments.
+
+Kubernetes security assurance should address both platform-level controls and workload-level controls.
+
+Baseline expectations should cover namespace separation, administrative identity, workload privilege, network policy, configuration validation, and image provenance where relevant.
+
+Where managed Kubernetes services are used, BlackDice should define which responsibilities remain with the provider and which remain internal.
+
+## Roles and Responsibilities
+
+- [Role] must define Kubernetes security expectations.
+- Platform owners must ensure clusters and supporting services meet this standard.
+- Engineering and operations teams must deploy and manage workloads in line with approved controls.
+
+## Exceptions
+
+Exceptions must be documented, risk-assessed, approved, and reviewed through the defined process.
+
+## Related Documents
+
+- Cloud Security Policy
+- Network and Infrastructure Security Policy
+- Secrets Management Standard
+- CI/CD Security Standard
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

02-standards/logging-and-alerting-standard.md

@@ -0,0 +1,68 @@
+Title: Logging and Alerting Standard
+Document ID: [STD-LOG-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Logging and Alerting Standard
+
+## Purpose
+
+This standard defines the minimum requirements for log generation, log protection, alerting, and review of security-relevant events.
+
+## Scope
+
+This standard applies to applications, infrastructure, identity systems, cloud services, Kubernetes environments, CI/CD platforms, and security monitoring workflows within the ISMS scope.
+
+## Mandatory Requirements
+
+Systems must generate logs sufficient to support operational oversight, incident investigation, and audit where proportionate to risk.
+
+Security-relevant events should be logged, including authentication activity, privileged actions, security control changes, and material failures or suspicious events where feasible.
+
+Logs must be protected against unauthorised access, tampering, and inappropriate deletion.
+
+Time settings for systems generating logs should be controlled so that event sequencing and investigation remain reliable.
+
+Alerting rules or equivalent review mechanisms must exist for material security events and high-risk operational issues.
+
+Logging and alerting coverage must reflect the distributed and ephemeral nature of cloud-native and containerised services.
+
+Retention of logs and monitoring records must align with approved retention requirements and business need.
+
+## Implementation Guidance
+
+BlackDice should define logging expectations by asset class so that services with greater exposure or criticality receive stronger coverage.
+
+Centralised or consolidated collection should be used where practical to improve correlation, searchability, and access control.
+
+Alerting should be tuned to balance timely escalation with manageable operational noise.
+
+Where logs may contain personal data, credentials, or other sensitive information, collection and retention should be minimised to what is necessary and handled appropriately.
+
+## Roles and Responsibilities
+
+- [Role] must define logging and alerting control expectations.
+- System owners must ensure relevant logging exists for their systems and services.
+- Operational teams must review alerts and take action according to defined processes.
+
+## Exceptions
+
+Exceptions to logging or alerting requirements must be documented, risk-assessed, approved, and reviewed.
+
+## Related Documents
+
+- Logging and Monitoring Policy
+- Incident Response Policy
+- Data Classification and Handling Policy
+- Records Retention and Disposal Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

02-standards/secrets-management-standard.md

@@ -0,0 +1,68 @@
+Title: Secrets Management Standard
+Document ID: [STD-SECRETS-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Secrets Management Standard
+
+## Purpose
+
+This standard defines the minimum requirements for creating, storing, using, rotating, and retiring secrets and related sensitive authentication material.
+
+## Scope
+
+This standard applies to passwords, API keys, tokens, certificates, private keys, connection strings, and other sensitive credentials used within the ISMS scope.
+
+## Mandatory Requirements
+
+Secrets must be stored only in approved controlled locations or mechanisms appropriate to their sensitivity and usage pattern.
+
+Secrets must not be hard-coded into source code, infrastructure definitions, build scripts, container images, documentation, or collaboration tools unless explicitly justified and approved.
+
+Access to secrets must be limited to authorised users, services, and processes based on least privilege.
+
+Secrets must be rotated, revoked, or replaced when compromise is suspected, when personnel with access depart, when system design changes require it, or at defined intervals where appropriate.
+
+Shared secrets should be avoided where more traceable identity-based mechanisms are available.
+
+Secrets used by automation, cloud services, Kubernetes workloads, and CI/CD pipelines must be managed in a way that reduces exposure through logs, configuration files, and debugging output.
+
+Test or non-production secrets must not be reused for production purposes.
+
+## Implementation Guidance
+
+BlackDice should favour centrally governed and auditable secret storage and retrieval mechanisms over manual distribution or local storage.
+
+Secret lifecycle management should cover generation, approval, distribution, rotation, revocation, replacement, and disposal.
+
+For containerised and cloud-native workloads, secret injection methods should minimise persistence in images, repositories, and long-lived static files.
+
+Monitoring should detect potentially exposed secrets in repositories, build artefacts, or operational records where feasible.
+
+## Roles and Responsibilities
+
+- [Role] must define the approved secrets management approach.
+- System owners must ensure secrets used by their services are controlled appropriately.
+- Engineering and operational teams must handle secrets according to this standard and report exposure promptly.
+
+## Exceptions
+
+Exceptions must be documented, risk-assessed, approved, and reviewed through the exception process.
+
+## Related Documents
+
+- Cryptography and Key Management Policy
+- Secure Development Policy
+- CI/CD Security Standard
+- Kubernetes Security Standard
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

02-standards/secure-code-review-standard.md

@@ -0,0 +1,66 @@
+Title: Secure Code Review Standard
+Document ID: [STD-CODEREVIEW-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Secure Code Review Standard
+
+## Purpose
+
+This standard defines the minimum requirements for reviewing code and related changes for security impact before promotion to production use.
+
+## Scope
+
+This standard applies to application code, infrastructure as code, deployment manifests, pipeline definitions, configuration changes, and related engineering artefacts within the ISMS scope.
+
+## Mandatory Requirements
+
+Changes must be reviewed before merge or release using a process appropriate to the risk and criticality of the change.
+
+Reviewers must assess whether the change introduces material security impact, especially where authentication, authorisation, data handling, cryptography, logging, infrastructure control, or externally exposed services are affected.
+
+High-risk changes must receive review by personnel with appropriate security or domain competence.
+
+Code review records must provide sufficient traceability to show what was reviewed, by whom, and with what outcome.
+
+Automated checks may support code review but must not be treated as a complete replacement for human assessment where security judgement is required.
+
+Emergency changes must be reviewed retrospectively where pre-implementation review is not feasible.
+
+## Implementation Guidance
+
+BlackDice should align review depth with change risk so that routine low-risk changes remain efficient while high-impact changes receive greater scrutiny.
+
+Review expectations should cover not only application source code but also infrastructure and deployment changes that can materially affect service security.
+
+Where specialised security review is not immediately available, compensating approval or targeted post-change review should be defined.
+
+Patterns of repeated review findings should inform secure development guidance, training, and pipeline checks.
+
+## Roles and Responsibilities
+
+- [Role] must define secure code review expectations.
+- Developers and change authors must submit changes for review with enough context to support assessment.
+- Reviewers must assess security-relevant impact before approval.
+
+## Exceptions
+
+Exceptions must be documented, justified, risk-assessed, approved, and reviewed.
+
+## Related Documents
+
+- Secure Development Policy
+- CI/CD Security Standard
+- Change Management Policy
+- Production Deployment Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

02-standards/secure-configuration-standard.md

@@ -0,0 +1,70 @@
+Title: Secure Configuration Standard
+Document ID: [STD-CONFIG-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Secure Configuration Standard
+
+## Purpose
+
+This standard defines the minimum secure configuration expectations for systems, services, platforms, and supporting technology within the ISMS scope.
+
+## Scope
+
+This standard applies to cloud resources, operating systems, endpoints, containers, Kubernetes components, applications, security tooling, and supporting infrastructure.
+
+## Mandatory Requirements
+
+Systems must be configured according to approved security baselines appropriate to their function, risk, and exposure.
+
+Unnecessary services, ports, protocols, packages, permissions, and features must be disabled or removed where practical.
+
+Default settings that increase security risk must be changed before operational use.
+
+Configuration changes affecting security posture must be controlled through the approved change process.
+
+Configuration standards for production and other high-risk environments must be documented and subject to periodic review.
+
+Security-relevant configuration drift must be detected through review, monitoring, automation, or other suitable means.
+
+Administrative interfaces and management access paths must be restricted and hardened.
+
+Sensitive configuration items, including secrets and key material, must not be embedded in unsecured locations.
+
+## Implementation Guidance
+
+BlackDice should define baseline configurations for common asset classes and align them with cloud-native operating patterns, infrastructure-as-code usage, and automation pipelines.
+
+For distributed or ephemeral workloads, secure configuration should be enforced as early as possible in templates, images, manifests, and deployment workflows rather than relying only on manual review.
+
+Configuration assurance should cover both initial build state and ongoing operational state.
+
+Where legacy constraints or third-party managed services limit baseline application, the residual risk should be understood and addressed through compensating control or exception.
+
+## Roles and Responsibilities
+
+- [Role] must define secure baseline expectations.
+- System and platform owners must implement and maintain approved configurations.
+- Change owners must ensure security-impacting configuration changes are assessed and approved.
+
+## Exceptions
+
+Exceptions to baseline configuration requirements must be documented, risk-assessed, approved, and reviewed.
+
+## Related Documents
+
+- Cloud Security Policy
+- Network and Infrastructure Security Policy
+- Vulnerability and Patch Management Policy
+- Change Management Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

02-standards/supplier-due-diligence-standard.md

@@ -0,0 +1,68 @@
+Title: Supplier Due Diligence Standard
+Document ID: [STD-SUPPLIER-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Supplier Due Diligence Standard
+
+## Purpose
+
+This standard defines the minimum due diligence requirements for onboarding and reviewing suppliers that may affect information security, service delivery, or compliance obligations.
+
+## Scope
+
+This standard applies to suppliers, service providers, subprocessors, hosting providers, development partners, and other third parties relevant to the ISMS scope.
+
+## Mandatory Requirements
+
+Suppliers that support in-scope services or handle relevant information must be assessed before onboarding to a level proportionate to their risk and criticality.
+
+Due diligence must consider the nature of the service, access level, information handled, dependency criticality, deployment model, and relevant legal or contractual obligations.
+
+Material suppliers must have a defined owner within BlackDice responsible for coordinating review and ongoing oversight.
+
+Security, privacy, resilience, and notification expectations should be addressed through contractual terms or other approved mechanisms where appropriate.
+
+Supplier assurance information relied upon for risk decisions must be reviewed for relevance, scope, and currency.
+
+Changes in supplier service model, ownership, control environment, or incident history that may materially affect risk must trigger reassessment.
+
+Supplier review outcomes, decisions, and follow-up actions must be recorded in an auditable manner.
+
+## Implementation Guidance
+
+BlackDice should tier suppliers so that deeper review is focused on those with greater operational importance, access, or information sensitivity.
+
+Due diligence may include questionnaires, assurance reports, certifications, contract review, architectural review, incident history, and dependency analysis as appropriate.
+
+For cloud providers and operator-hosted deployment models, due diligence should explicitly consider shared-responsibility boundaries and operational dependencies.
+
+Where a supplier cannot meet all requirements, compensating control, contractual mitigation, planned remediation, or formal risk acceptance should be considered.
+
+## Roles and Responsibilities
+
+- [Role] must define supplier due diligence expectations.
+- Supplier owners must complete or coordinate required due diligence and review.
+- Procurement, legal, security, privacy, and operational stakeholders must support assessment where relevant.
+
+## Exceptions
+
+Exceptions must be documented, justified, risk-assessed, approved, and reviewed through the defined process.
+
+## Related Documents
+
+- Supplier Security Policy
+- Privacy and Data Protection Policy
+- Supplier Onboarding and Review Procedure
+- Supplier Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/access-review-procedure.md

@@ -0,0 +1,84 @@
+Title: Access Review Procedure
+Document ID: [PROC-ACCESS-REVIEW-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Access Review Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should review user, privileged, and service access to ensure it remains appropriate.
+
+## Scope
+
+This procedure applies to in-scope systems, services, cloud platforms, repositories, administrative functions, and other controlled access points.
+
+## Trigger / When Used
+
+Use this procedure:
+
+- at planned review intervals
+- after significant role or organisational changes
+- after incidents, audit findings, or suspected misuse
+- when required for high-risk or privileged environments
+
+## Procedure Steps
+
+1. Define the scope of the review, including the systems, accounts, and review period.
+2. Extract or compile the current access listing from the relevant systems or authoritative source.
+3. Identify account types requiring review, including user accounts, privileged accounts, service accounts, temporary accounts, and shared accounts where they exist.
+4. Send the review to the appropriate manager, asset owner, or system owner for validation.
+5. Confirm whether each access right remains required, appropriate, and proportionate to the current role or system purpose.
+6. Record required changes, including removals, privilege reductions, account disablement, or further investigation.
+7. Complete the approved changes and confirm closure of review actions.
+8. Retain review evidence and track overdue or incomplete reviews to resolution.
+
+## Inputs
+
+- current access listing
+- system ownership information
+- personnel role information
+- previous review results where relevant
+
+## Outputs / Records
+
+- completed access review record
+- required remediation actions
+- evidence of changed or removed access
+- escalation record for unresolved items
+
+## Roles and Responsibilities
+
+- [Role] must coordinate the access review process.
+- Managers and system owners must validate access under their responsibility.
+- Administrators must implement approved changes.
+- Internal reviewers may sample evidence for assurance purposes.
+
+## Escalation / Exceptions
+
+Escalate when:
+
+- reviewers do not complete reviews within the required timeframe
+- privileged access cannot be validated
+- unexplained accounts or excessive permissions are identified
+- technical limitations prevent evidence collection
+
+Exceptions must be documented and approved through the defined process.
+
+## Related Documents
+
+- Access Control Policy
+- Identity and Authentication Standard
+- Joiner Mover Leaver Procedure
+- Corrective Action Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/backup-testing-procedure.md

@@ -0,0 +1,83 @@
+Title: Backup Testing Procedure
+Document ID: [PROC-BACKUP-TEST-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Backup Testing Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should test backup restoration capability and record the results.
+
+## Scope
+
+This procedure applies to in-scope systems, services, data sets, configurations, and other assets where backup and restoration capability is required.
+
+## Trigger / When Used
+
+Use this procedure:
+
+- at planned backup test intervals
+- after material changes to backup design or protected assets
+- after backup-related incidents or failures
+- when assurance evidence is required
+
+## Procedure Steps
+
+1. Select the system, data set, or recovery scenario to test based on criticality and test plan.
+2. Confirm the expected restore objective, test scope, data sensitivity, and success criteria.
+3. Perform the backup restoration test in an approved and controlled manner.
+4. Validate that the restored data, configuration, or service state is complete, usable, and consistent with the test objective.
+5. Record the outcome, timing, issues encountered, and whether objectives were met.
+6. Raise remediation actions for failures, gaps, or unacceptable delays.
+7. Review results with the relevant owner and agree follow-up actions.
+8. Retain test evidence for assurance and audit purposes.
+
+## Inputs
+
+- backup test schedule or request
+- protected asset information
+- restoration instructions or runbooks
+- success criteria
+
+## Outputs / Records
+
+- backup test record
+- restoration evidence
+- identified issues and follow-up actions
+- updated recovery assurance status
+
+## Roles and Responsibilities
+
+- [Role] must coordinate the backup test programme or oversight.
+- System owners must confirm recovery requirements and review outcomes.
+- Operational teams must perform restoration testing and record results.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- a test fails or cannot be completed
+- recovery objectives are not met
+- backup coverage is incomplete
+- sensitive data handling during testing creates additional risk
+
+Exceptions to planned testing must be documented and approved.
+
+## Related Documents
+
+- Backup and Recovery Policy
+- Business Continuity and Disaster Recovery Policy
+- Disaster Recovery Testing Procedure
+- Corrective Action Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/breach-notification-procedure.md

@@ -0,0 +1,83 @@
+Title: Breach Notification Procedure
+Document ID: [PROC-BREACH-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Breach Notification Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should assess and manage notification obligations arising from suspected or confirmed personal data breaches or other reportable security incidents.
+
+## Scope
+
+This procedure applies to incidents that may trigger legal, regulatory, contractual, customer, or other formal notification obligations.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- an incident may involve personal data compromise
+- contractual notification requirements may apply
+- customer-owned or supplier-shared information may be affected
+- there is uncertainty about whether notification obligations exist
+
+## Procedure Steps
+
+1. Receive escalation from incident handling or another authorised source.
+2. Confirm the nature of the incident, the information involved, and the affected parties or environments.
+3. Assess whether legal, regulatory, contractual, customer, or supplier notification obligations may apply.
+4. Identify relevant deadlines, approval requirements, and required content for notification.
+5. Coordinate internal review with appropriate stakeholders, including security, privacy, legal, management, and customer-facing roles as needed.
+6. Prepare and issue notification through the approved channel where notification is required.
+7. Record the decision, rationale, timing, recipients, and any follow-up obligations.
+8. Update the underlying incident record and track resulting actions to completion.
+
+## Inputs
+
+- incident details and severity assessment
+- affected data or service information
+- contractual and regulatory obligations
+- stakeholder review input
+
+## Outputs / Records
+
+- notification decision record
+- issued notification or documented no-notification rationale
+- approval evidence
+- follow-up action record
+
+## Roles and Responsibilities
+
+- [Role] must coordinate notification assessment and execution.
+- Incident handlers must escalate potentially notifiable incidents promptly.
+- Relevant stakeholders must review obligations and approve content where required.
+
+## Escalation / Exceptions
+
+Escalate immediately where:
+
+- notification deadlines may be at risk
+- facts are incomplete but harm may be ongoing
+- a customer or regulator has already made contact
+- multiple jurisdictions or conflicting obligations may apply
+
+This procedure must not be interpreted as legal advice. Legal review should be obtained where appropriate.
+
+## Related Documents
+
+- Incident Response Policy
+- Security Incident Handling Procedure
+- Privacy and Data Protection Policy
+- Information Transfer Policy
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/change-approval-procedure.md

@@ -0,0 +1,82 @@
+Title: Change Approval Procedure
+Document ID: [PROC-CHANGE-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Change Approval Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should assess, review, approve, and record changes that may affect security, service integrity, or compliance.
+
+## Scope
+
+This procedure applies to production changes, infrastructure changes, configuration changes, security tooling changes, CI/CD workflow changes, and other in-scope changes requiring formal approval.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- a planned change may affect security or service operation
+- a high-risk or production change requires approval
+- an emergency change requires retrospective review
+
+## Procedure Steps
+
+1. Create a change record with a description of the planned change, scope, systems affected, timing, and owner.
+2. Assess the change for security, operational, customer, resilience, and rollback impact.
+3. Identify testing, evidence, implementation steps, and backout arrangements.
+4. Determine the approval level required based on risk, environment, and criticality.
+5. Obtain approval from the appropriate reviewer or authority before implementation, unless emergency conditions require immediate action.
+6. Ensure pre-implementation conditions are satisfied, including communication and deployment readiness where relevant.
+7. Record the decision and retain approval evidence.
+8. For emergency changes, ensure retrospective review and confirmation of residual risk.
+
+## Inputs
+
+- change request
+- impact assessment
+- test or validation evidence
+- implementation and rollback plan
+
+## Outputs / Records
+
+- approved or rejected change record
+- approval evidence
+- implementation conditions and notes
+- retrospective review record where applicable
+
+## Roles and Responsibilities
+
+- Change owners must submit complete and accurate change information.
+- [Role] or designated approvers must review and approve changes according to risk.
+- Technical reviewers must provide impact input where needed.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- the change has production, customer, or regulatory impact
+- risk is not understood or testing is incomplete
+- there is disagreement on approval or readiness
+- emergency implementation is proposed without enough context
+
+Exceptions must be documented and approved through the defined process.
+
+## Related Documents
+
+- Change Management Policy
+- Production Deployment Procedure
+- Secure Development Policy
+- Risk Assessment Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/corrective-action-procedure.md

@@ -0,0 +1,83 @@
+Title: Corrective Action Procedure
+Document ID: [PROC-CAPA-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Corrective Action Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should record, investigate, assign, track, and close corrective actions arising from ISMS issues.
+
+## Scope
+
+This procedure applies to corrective actions raised from incidents, audits, risk reviews, management review, testing, exceptions, and other control deficiencies within the ISMS scope.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- an issue requires formal remediation tracking
+- an audit finding or nonconformity is raised
+- an incident or exercise identifies improvement actions
+- management review requires follow-up actions
+
+## Procedure Steps
+
+1. Record the issue, source, impact, and required corrective action.
+2. Assign an owner, target date, and priority based on risk and business impact.
+3. Perform root cause analysis where appropriate to understand the underlying control or process weakness.
+4. Define the remediation plan, including actions, dependencies, and evidence needed for closure.
+5. Track progress and review overdue, blocked, or high-risk items regularly.
+6. Verify that the corrective action has been completed effectively.
+7. Close the action only when sufficient evidence exists and any residual risk is understood.
+8. Update related risks, procedures, controls, or registers where the issue has wider implications.
+
+## Inputs
+
+- finding, issue, or improvement record
+- supporting evidence
+- risk and impact information
+- proposed remediation plan
+
+## Outputs / Records
+
+- corrective action record
+- status updates and escalation notes
+- closure evidence
+- linked updates to other records where applicable
+
+## Roles and Responsibilities
+
+- Action owners must deliver remediation and provide evidence.
+- [Role] must oversee tracking and escalation of corrective actions.
+- Reviewers must verify completion and effectiveness where required.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- an action is overdue or repeatedly deferred
+- remediation is ineffective or incomplete
+- the issue presents significant ongoing risk
+- cross-functional support is needed but not available
+
+Exceptions to target dates or action scope must be documented and approved where required.
+
+## Related Documents
+
+- Incident Response Policy
+- Internal Audit Procedure
+- Management Review Procedure
+- Corrective Actions Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/disaster-recovery-testing-procedure.md

@@ -0,0 +1,83 @@
+Title: Disaster Recovery Testing Procedure
+Document ID: [PROC-DR-TEST-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Disaster Recovery Testing Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should plan, execute, record, and review disaster recovery tests.
+
+## Scope
+
+This procedure applies to disaster recovery plans, recovery scenarios, technology recovery arrangements, critical dependencies, and coordination activities relevant to in-scope operations.
+
+## Trigger / When Used
+
+Use this procedure:
+
+- at planned disaster recovery exercise intervals
+- after material changes to architecture or recovery arrangements
+- after major incidents or identified resilience concerns
+- when management or audit requires assurance evidence
+
+## Procedure Steps
+
+1. Define the recovery scenario, scope, assumptions, participants, and success criteria.
+2. Identify the systems, suppliers, communications paths, and dependencies involved in the test.
+3. Obtain required approvals and ensure test risks are understood and controlled.
+4. Execute the exercise or simulation according to the approved plan.
+5. Record recovery timing, decisions, issues, coordination gaps, and whether objectives were met.
+6. Assess the effectiveness of technical recovery, communications, escalation, and decision-making.
+7. Agree follow-up actions, owners, and due dates for identified gaps.
+8. Retain the test report and track corrective actions through to closure.
+
+## Inputs
+
+- disaster recovery test plan
+- recovery documentation
+- asset and dependency information
+- participant and contact lists
+
+## Outputs / Records
+
+- test plan and approvals
+- exercise notes and evidence
+- recovery test report
+- corrective actions and improvement items
+
+## Roles and Responsibilities
+
+- [Role] must coordinate disaster recovery testing or oversight.
+- Process and system owners must support test design and participation.
+- Management must review significant outcomes and support remediation.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- testing identifies a material recovery gap
+- required participants or suppliers cannot support the exercise
+- a live service risk emerges during testing
+- the scenario indicates a likely failure to meet recovery expectations
+
+Exceptions to planned testing must be documented and approved.
+
+## Related Documents
+
+- Business Continuity and Disaster Recovery Policy
+- Backup and Recovery Policy
+- Backup Testing Procedure
+- Corrective Action Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/exception-management-procedure.md

@@ -0,0 +1,83 @@
+Title: Exception Management Procedure
+Document ID: [PROC-EXCEPTION-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Exception Management Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should request, assess, approve, record, review, and close exceptions to required security controls.
+
+## Scope
+
+This procedure applies to proposed deviations from approved policies, standards, procedures, or mandatory security requirements within the ISMS scope.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- a control requirement cannot be met
+- a temporary deviation is needed for operational or technical reasons
+- a compensating control is proposed in place of the standard requirement
+
+## Procedure Steps
+
+1. Submit an exception request describing the requirement affected, rationale, affected assets or services, duration, and proposed compensating controls.
+2. Confirm the request is complete and identify the relevant owner, approver, and impacted stakeholders.
+3. Assess the security, operational, customer, compliance, and resilience risk associated with the exception.
+4. Determine whether the exception can be accepted, requires additional controls, or should be rejected.
+5. Record the decision, approval, conditions, expiry date, and review date.
+6. Implement any required compensating controls or follow-up actions.
+7. Review open exceptions at defined intervals or when conditions change.
+8. Close the exception when the underlying issue is remediated or the exception expires without renewal.
+
+## Inputs
+
+- exception request
+- affected control requirement
+- risk assessment information
+- proposed compensating controls
+
+## Outputs / Records
+
+- exception decision record
+- approved conditions and expiry date
+- linked risk or remediation actions
+- closure record
+
+## Roles and Responsibilities
+
+- Requesters must provide accurate justification and proposed mitigation.
+- [Role] must coordinate exception review and record management.
+- Approvers must evaluate risk and determine whether the exception is acceptable.
+- Control owners must implement agreed compensating controls.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- the exception affects production, customer, or regulated data handling
+- no compensating control is available
+- the exception becomes long-term or repeatedly renewed
+- disagreement exists over residual risk
+
+This procedure governs exceptions; no additional procedural exception is needed beyond documented emergency handling.
+
+## Related Documents
+
+- Information Security Policy
+- Risk Assessment and Treatment Methodology
+- Risk Assessment Procedure
+- Security Exceptions Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/internal-audit-procedure.md

@@ -0,0 +1,83 @@
+Title: Internal Audit Procedure
+Document ID: [PROC-AUDIT-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Internal Audit Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should plan, perform, report, and follow up internal audits of the ISMS.
+
+## Scope
+
+This procedure applies to internal audits of the ISMS scope, including governance, policies, standards, procedures, records, control operation, and improvement activities.
+
+## Trigger / When Used
+
+Use this procedure:
+
+- according to the internal audit plan
+- when management requests targeted assurance
+- after major changes or significant incidents where additional assurance is needed
+
+## Procedure Steps
+
+1. Define the audit objective, scope, criteria, timing, and auditor assignment.
+2. Confirm auditor competence and independence appropriate to the audit scope.
+3. Prepare the audit plan, sampling approach, and evidence request.
+4. Conduct document review, interviews, walkthroughs, and evidence sampling as required.
+5. Evaluate conformity, effectiveness, and any identified gaps or nonconformities.
+6. Record findings, observations, and strengths in the audit report.
+7. Communicate results to relevant owners and management.
+8. Track resulting corrective actions to closure and confirm follow-up where needed.
+
+## Inputs
+
+- audit plan
+- audit criteria and scope
+- relevant documents and records
+- prior audit and corrective action information
+
+## Outputs / Records
+
+- audit plan
+- working notes or evidence references
+- audit report
+- corrective action records
+
+## Roles and Responsibilities
+
+- [Role] must coordinate the internal audit programme.
+- Auditors must perform audits objectively and record evidence appropriately.
+- Auditees must provide access to relevant information and support the audit.
+- Management must review results and support corrective action.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- auditor independence cannot be maintained
+- required evidence is unavailable
+- significant nonconformity or systemic failure is identified
+- corrective actions are not progressing
+
+Exceptions to the audit plan must be documented and approved.
+
+## Related Documents
+
+- Information Security Policy
+- Management Review Procedure
+- Corrective Action Procedure
+- Internal Audit Plan Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/joiner-mover-leaver-procedure.md

@@ -0,0 +1,84 @@
+Title: Joiner Mover Leaver Procedure
+Document ID: [PROC-JML-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Joiner Mover Leaver Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should provision, change, and remove access when personnel join, change role, or leave.
+
+## Scope
+
+This procedure applies to employees, contractors, temporary workers, and other individuals granted access to in-scope systems, services, information, or facilities.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- a new starter requires access
+- an existing worker changes role, team, or privilege level
+- a worker leaves the organisation or no longer requires access
+- emergency access changes are needed due to risk or incident
+
+## Procedure Steps
+
+1. Receive an authorised joiner, mover, or leaver request from the appropriate manager or approved source.
+2. Confirm the individual's identity, status, start or end date, and the business justification for access.
+3. Determine the required access profile based on role, least privilege, and segregation considerations.
+4. Provision, modify, or remove access in relevant systems, including identity platforms, endpoints, cloud services, repositories, support systems, and facilities as applicable.
+5. Apply stronger controls or additional review for privileged, production, cloud administration, CI/CD, or customer-sensitive access.
+6. Confirm that access changes have been completed and notify the requester or manager.
+7. Record the activity and retain evidence of approval and completion.
+8. For leavers, ensure access removal is completed promptly and that any assigned assets or credentials are returned, revoked, or disabled.
+
+## Inputs
+
+- authorised access request
+- start date, role change date, or leaving date
+- approved role profile or access requirements
+- asset assignment information where relevant
+
+## Outputs / Records
+
+- access provisioning or deprovisioning record
+- approval evidence
+- updated account and access status
+- returned asset or credential record where relevant
+
+## Roles and Responsibilities
+
+- Managers must submit timely and accurate requests.
+- [Role] or designated administrators must process access changes and retain records.
+- System owners must support role-appropriate access where local approval is required.
+- Individuals subject to this procedure must return assets and comply with security obligations.
+
+## Escalation / Exceptions
+
+Escalate immediately where:
+
+- privileged or sensitive access cannot be removed on time
+- employment or contractor status is unclear
+- emergency suspension of access is required
+- requested access exceeds normal role expectations
+
+Exceptions must be documented, risk-assessed, and approved through the exception process.
+
+## Related Documents
+
+- Access Control Policy
+- Human Resources Security Policy
+- Identity and Authentication Standard
+- Access Review Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/management-review-procedure.md

@@ -0,0 +1,82 @@
+Title: Management Review Procedure
+Document ID: [PROC-MGMT-REVIEW-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Management Review Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should prepare for, conduct, record, and follow up formal management reviews of the ISMS.
+
+## Scope
+
+This procedure applies to formal management review activity for the ISMS, including review inputs, decisions, actions, and evidence of oversight.
+
+## Trigger / When Used
+
+Use this procedure:
+
+- at planned management review intervals
+- when significant change, incident, or audit outcome requires management review
+- when strategic security decisions require formal oversight and recording
+
+## Procedure Steps
+
+1. Define the review date, scope, participants, and agenda.
+2. Gather required inputs, including status of objectives, risks, incidents, audit results, corrective actions, exceptions, supplier issues, and improvement opportunities.
+3. Prepare the review pack or meeting material and circulate it to participants in advance where appropriate.
+4. Conduct the review and document discussions, decisions, approvals, and required actions.
+5. Confirm whether the ISMS remains suitable, adequate, and effective, and identify any required changes.
+6. Assign owners and due dates for resulting decisions or actions.
+7. Record the review outcome in the approved format and retain supporting evidence.
+8. Track resulting actions through to closure and report status at the next review where necessary.
+
+## Inputs
+
+- objectives and performance information
+- risk and exception status
+- incident, audit, and corrective action summaries
+- supplier and compliance issues where relevant
+
+## Outputs / Records
+
+- management review minutes or record
+- decisions and action items
+- updated priorities or improvement actions
+- evidence of oversight
+
+## Roles and Responsibilities
+
+- [Role] must coordinate the review process and records.
+- Management participants must review the inputs and make informed decisions.
+- Action owners must complete assigned follow-up actions.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- required inputs are incomplete
+- major risk or nonconformity requires urgent decision
+- assigned actions are not being progressed
+- management attendance or approval cannot be obtained
+
+Exceptions to scheduled review timing must be documented and approved.
+
+## Related Documents
+
+- ISMS Manual
+- Information Security Objectives Template
+- Internal Audit Procedure
+- Management Review Minutes Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/patch-management-procedure.md

@@ -0,0 +1,83 @@
+Title: Patch Management Procedure
+Document ID: [PROC-PATCH-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Patch Management Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should assess, test, schedule, deploy, and verify security patches and updates.
+
+## Scope
+
+This procedure applies to operating systems, applications, dependencies, cloud images, containers, endpoints, managed services, and other patchable in-scope components.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- security patches become available
+- emergency patching is required due to active risk
+- periodic patch cycles are performed
+- vulnerability management identifies missing updates
+
+## Procedure Steps
+
+1. Identify relevant patches or updates and the assets they affect.
+2. Assess urgency based on severity, exploitability, exposure, and business impact.
+3. Determine whether testing is required before deployment and identify any change approval requirements.
+4. Schedule deployment according to risk, operational impact, and service constraints.
+5. Apply the patch or update through controlled and traceable methods.
+6. Validate that the update completed successfully and that the affected service remains stable.
+7. Record patch status, timing, failures, and follow-up actions.
+8. Where patching cannot proceed, document the reason and apply compensating controls, exception handling, or risk acceptance as appropriate.
+
+## Inputs
+
+- patch or update notice
+- affected asset inventory
+- vulnerability context
+- testing and change requirements
+
+## Outputs / Records
+
+- patch deployment record
+- change record where applicable
+- validation evidence
+- exception or risk record for deferred updates
+
+## Roles and Responsibilities
+
+- [Role] must oversee patch management expectations.
+- System owners must ensure updates are assessed and applied to their assets.
+- Operational teams must carry out deployment and verification steps.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- critical security patches cannot be applied in time
+- patching causes service degradation or rollback
+- supplier-managed services require unresolved external action
+- testing shows a material incompatibility or business risk
+
+Exceptions must be documented and approved where required.
+
+## Related Documents
+
+- Vulnerability and Patch Management Policy
+- Vulnerability Management Procedure
+- Change Management Policy
+- Production Deployment Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/production-deployment-procedure.md

@@ -0,0 +1,82 @@
+Title: Production Deployment Procedure
+Document ID: [PROC-DEPLOY-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Production Deployment Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should prepare, authorise, execute, and verify production deployments.
+
+## Scope
+
+This procedure applies to production releases affecting applications, infrastructure as code, Kubernetes workloads, configuration, and supporting service components within the ISMS scope.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- a production deployment is planned
+- a production hotfix or emergency release is required
+- a deployment rollback or recovery action is needed
+
+## Procedure Steps
+
+1. Confirm that the change has passed the required review, approval, and testing gates.
+2. Validate the release scope, artefact version, deployment target, and deployment owner.
+3. Check for known operational risks, dependencies, freeze periods, customer constraints, and rollback readiness.
+4. Notify relevant stakeholders where communication is required.
+5. Execute the deployment using the approved and traceable deployment path.
+6. Monitor the deployment and perform post-deployment validation checks, including service health and any security-relevant control checks.
+7. Roll back or escalate if the deployment introduces unacceptable risk, instability, or failed controls.
+8. Record the deployment outcome, timing, issues, and follow-up actions.
+
+## Inputs
+
+- approved change record
+- release artefact or deployment package
+- deployment plan and rollback plan
+- validation criteria
+
+## Outputs / Records
+
+- deployment record
+- validation evidence
+- rollback or incident record where applicable
+- follow-up action record
+
+## Roles and Responsibilities
+
+- Deployment owners must ensure readiness and accurate execution.
+- Reviewers and approvers must confirm the deployment is authorised.
+- Operational teams must monitor production behaviour during and after deployment.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- deployment validation fails
+- unexpected customer or production impact occurs
+- rollback fails or is not available
+- emergency deployment bypasses normal control steps
+
+Emergency or exceptional deployments must be reviewed retrospectively and recorded.
+
+## Related Documents
+
+- Change Management Policy
+- Change Approval Procedure
+- CI/CD Security Standard
+- Secure Code Review Standard
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/risk-assessment-procedure.md

@@ -0,0 +1,83 @@
+Title: Risk Assessment Procedure
+Document ID: [PROC-RISK-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Risk Assessment Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should perform and record information security risk assessments using the approved methodology.
+
+## Scope
+
+This procedure applies to assessments of in-scope services, systems, projects, suppliers, changes, exceptions, incidents, and other relevant activities.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- a new system, service, supplier, or change is introduced
+- a periodic risk review is due
+- an incident, audit finding, or exception requires assessment
+- management requests reassessment due to changed conditions
+
+## Procedure Steps
+
+1. Define the subject of the assessment, including scope, owner, context, and assessment objective.
+2. Identify relevant assets, threats, vulnerabilities, dependencies, and potential impacts.
+3. Assess likelihood and impact using the approved risk methodology and current business context.
+4. Determine the initial risk rating and compare it with risk acceptance criteria.
+5. Identify proposed treatment options, compensating controls, or risk acceptance needs.
+6. Assign a risk owner, review date, and action plan where treatment is required.
+7. Record the assessment outcome in the approved format or register.
+8. Escalate significant risks for approval, treatment prioritisation, or formal acceptance as required.
+
+## Inputs
+
+- assessment scope and context
+- asset and service information
+- risk methodology
+- supporting evidence such as architecture, incidents, audits, or supplier data
+
+## Outputs / Records
+
+- completed risk assessment
+- treatment actions or acceptance decision
+- risk register update
+- escalation record where applicable
+
+## Roles and Responsibilities
+
+- Assessors must apply the methodology consistently and document the rationale.
+- Risk owners must review and accept accountability for assigned risks.
+- [Role] must maintain oversight of process quality and risk tracking.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- a risk exceeds normal acceptance thresholds
+- ownership is unclear
+- the treatment plan cannot be agreed
+- the risk has customer, regulatory, or major service implications
+
+Exceptions to the process must be documented and approved where necessary.
+
+## Related Documents
+
+- Risk Assessment and Treatment Methodology
+- Exception Management Procedure
+- Corrective Action Procedure
+- Risk Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/security-incident-handling-procedure.md

@@ -0,0 +1,85 @@
+Title: Security Incident Handling Procedure
+Document ID: [PROC-INCIDENT-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Security Incident Handling Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should report, assess, contain, investigate, communicate, and close information security incidents.
+
+## Scope
+
+This procedure applies to suspected or confirmed security incidents affecting in-scope people, information, systems, services, suppliers, or customers.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- a security event may represent an incident
+- a user reports suspicious activity or weakness
+- monitoring or telemetry identifies potentially malicious or unauthorised behaviour
+- a supplier or customer notifies BlackDice of a security issue affecting in-scope operations
+
+## Procedure Steps
+
+1. Record the reported event or issue and assign an initial handler or coordinator.
+2. Perform initial triage to determine whether the issue is likely to be a security incident and assess urgency.
+3. Classify the incident according to the approved severity approach and determine immediate containment needs.
+4. Contain the incident where feasible while preserving evidence and avoiding unnecessary disruption.
+5. Investigate the cause, affected assets, timeline, impact, and whether customer, supplier, privacy, or regulatory considerations apply.
+6. Escalate internally and externally as required, including legal, privacy, customer communication, management, and supplier interfaces where relevant.
+7. Coordinate eradication and recovery actions, including validation that risk has been reduced to an acceptable level.
+8. Record lessons learned, required corrective actions, and any updates needed to risks, controls, or documentation before closure.
+
+## Inputs
+
+- incident report or alert
+- logs, telemetry, and evidence
+- asset and ownership information
+- relevant contact and escalation details
+
+## Outputs / Records
+
+- incident record
+- incident severity and status updates
+- evidence and investigation notes
+- recovery and communication record
+- lessons learned and corrective actions
+
+## Roles and Responsibilities
+
+- [Role] must coordinate incident handling and escalation.
+- Personnel must report incidents promptly and cooperate with the response.
+- System and service owners must support containment, investigation, and recovery.
+- Management must support critical decisions and communications.
+
+## Escalation / Exceptions
+
+Escalate immediately where:
+
+- there is actual or suspected customer impact
+- there is possible personal data compromise
+- critical production services are at risk
+- regulatory, contractual, or public communication may be required
+
+Emergency deviations from normal process must be documented retrospectively if immediate action is necessary.
+
+## Related Documents
+
+- Incident Response Policy
+- Breach Notification Procedure
+- Corrective Action Procedure
+- Incident Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/supplier-onboarding-and-review-procedure.md

@@ -0,0 +1,83 @@
+Title: Supplier Onboarding and Review Procedure
+Document ID: [PROC-SUPPLIER-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Supplier Onboarding and Review Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should assess, onboard, record, and review suppliers relevant to the ISMS scope.
+
+## Scope
+
+This procedure applies to suppliers providing technology, hosting, support, development, data processing, operational, or other services that may affect security, resilience, or compliance.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- a new supplier is proposed
+- a supplier's role or service scope materially changes
+- periodic supplier review is due
+- a supplier incident or assurance concern triggers reassessment
+
+## Procedure Steps
+
+1. Record the proposed supplier, service description, owner, and business rationale.
+2. Determine the supplier's risk tier based on access, information handled, service criticality, deployment model, and dependency importance.
+3. Perform due diligence appropriate to the risk tier, including security, privacy, resilience, contractual, and shared-responsibility considerations.
+4. Review the due diligence outcome and identify any required contractual controls, remediation actions, or risk acceptance decisions.
+5. Obtain approval to onboard or continue using the supplier where required.
+6. Record the supplier in the approved register with ownership, status, review cadence, and assurance references.
+7. Perform periodic review and reassessment based on risk, incidents, material changes, or expired assurance evidence.
+8. Track remediation actions, exceptions, and reassessment outcomes to closure.
+
+## Inputs
+
+- supplier proposal
+- due diligence responses or evidence
+- service and dependency information
+- legal or contractual review input where applicable
+
+## Outputs / Records
+
+- supplier review record
+- onboarding or continuation decision
+- supplier register entry
+- remediation, exception, or risk records where applicable
+
+## Roles and Responsibilities
+
+- Supplier owners must initiate and coordinate the review.
+- [Role] must oversee supplier security due diligence and review expectations.
+- Relevant stakeholders must support assessment and approval where applicable.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- a supplier is business-critical or handles sensitive information
+- assurance evidence is incomplete or materially outdated
+- contractual controls cannot be agreed
+- a supplier incident changes the risk profile materially
+
+Exceptions must be documented and approved appropriately.
+
+## Related Documents
+
+- Supplier Security Policy
+- Supplier Due Diligence Standard
+- Risk Assessment Procedure
+- Supplier Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

03-procedures/vulnerability-management-procedure.md

@@ -0,0 +1,83 @@
+Title: Vulnerability Management Procedure
+Document ID: [PROC-VULN-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Vulnerability Management Procedure
+
+## Purpose
+
+This procedure defines how BlackDice should identify, assess, prioritise, track, and close vulnerabilities affecting in-scope assets and services.
+
+## Scope
+
+This procedure applies to applications, infrastructure, cloud services, Kubernetes environments, endpoints, dependencies, and other in-scope technology assets.
+
+## Trigger / When Used
+
+Use this procedure when:
+
+- new vulnerabilities are identified
+- periodic scanning or review takes place
+- supplier notifications or intelligence indicate exposure
+- incidents, audits, or testing reveal security weaknesses
+
+## Procedure Steps
+
+1. Collect vulnerability findings from approved sources such as scanning, review, supplier notifications, or manual assessment.
+2. Validate the finding and identify the affected asset, service, version, environment, and owner.
+3. Assess severity using technical characteristics, business context, exposure, exploitability, and service criticality.
+4. Determine the remediation approach, such as patching, configuration change, code fix, compensating control, or risk acceptance.
+5. Record the finding, owner, target date, and status in the approved tracking mechanism.
+6. Prioritise remediation for externally exposed services, production workloads, identity systems, CI/CD components, and high-impact assets.
+7. Verify remediation or compensating control implementation before closure.
+8. Escalate overdue, high-risk, or disputed findings as required.
+
+## Inputs
+
+- vulnerability findings
+- asset and owner information
+- severity and business context
+- remediation guidance where available
+
+## Outputs / Records
+
+- vulnerability tracking record
+- remediation actions
+- exception or risk acceptance record where applicable
+- closure evidence
+
+## Roles and Responsibilities
+
+- [Role] must oversee the vulnerability management process.
+- System and service owners must remediate findings affecting their assets.
+- Security or platform reviewers must support validation and prioritisation where required.
+
+## Escalation / Exceptions
+
+Escalate where:
+
+- a high-risk issue affects production or exposed services
+- remediation is overdue or blocked
+- there is disagreement on severity or ownership
+- a workaround is used instead of full remediation
+
+Exceptions and accepted risks must be documented and approved appropriately.
+
+## Related Documents
+
+- Vulnerability and Patch Management Policy
+- Patch Management Procedure
+- Secure Configuration Standard
+- Risk Assessment Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

04-registers/asset-register-template.md

@@ -0,0 +1,62 @@
+Title: Asset Register Template
+Document ID: [REG-ASSET-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Asset Register Template
+
+## Purpose
+
+This template provides the structure for recording in-scope information and technology assets.
+
+## Scope
+
+This register applies to information assets, software assets, cloud services, repositories, endpoints, infrastructure components, and other assets relevant to the ISMS scope.
+
+## Data Fields / Expected Columns
+
+The asset register should record at least:
+
+- asset ID
+- asset name
+- asset type
+- description
+- owner
+- location or platform
+- classification
+- criticality
+- environment
+- supplier or hosting dependency
+- backup or recovery requirement
+- status
+- review date
+
+## Ownership
+
+This register should be owned by [Role]. Asset owners are responsible for maintaining the accuracy of entries relevant to their assets.
+
+## Update Frequency
+
+The register should be updated when assets are created, changed, retired, transferred, or reassessed. It should be reviewed periodically for completeness and accuracy.
+
+## Retention
+
+Current and historical records should be retained in line with document and records retention requirements where needed for auditability or lifecycle traceability.
+
+## Template Table
+
+| Asset ID | Asset Name | Asset Type | Description | Owner | Location / Platform | Classification | Criticality | Environment | Supplier / Hosting Dependency | Recovery Requirement | Status | Review Date |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [A-001] | [Asset name] | [Application / Data / Endpoint / Cloud Service / Repository] | [Description] | [Role] | [Platform / location] | [Classification] | [Low/Medium/High] | [Prod / Non-Prod] | [Supplier / Provider] | [Yes / No / Details] | [Active / Retired] | [DD Month YYYY] |
+
+## Related Documents
+
+- Asset Management and Acceptable Use Policy
+- Data Classification and Handling Policy
+- Backup and Recovery Policy
+- Risk Register Template

04-registers/corrective-actions-register-template.md

@@ -0,0 +1,61 @@
+Title: Corrective Actions Register Template
+Document ID: [REG-CORRECTIVE-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Corrective Actions Register Template
+
+## Purpose
+
+This template provides the structure for recording and tracking corrective actions arising from ISMS issues, findings, and improvement activity.
+
+## Scope
+
+This register applies to actions arising from incidents, audits, risk reviews, exceptions, testing, management review, and other control gaps.
+
+## Data Fields / Expected Columns
+
+The register should record at least:
+
+- action ID
+- source
+- issue summary
+- action description
+- owner
+- priority
+- target date
+- status
+- progress update
+- closure evidence
+- closure date
+- linked records
+
+## Ownership
+
+This register should be owned by [Role]. Assigned action owners are responsible for progress and evidence of closure.
+
+## Update Frequency
+
+The register should be updated when actions are raised, reassigned, progressed, delayed, or closed. Overdue actions should be reviewed regularly.
+
+## Retention
+
+Corrective action records should be retained in line with document and records retention requirements and audit needs.
+
+## Template Table
+
+| Action ID | Source | Issue Summary | Action Description | Owner | Priority | Target Date | Status | Progress Update | Closure Evidence | Closure Date | Linked Records |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [CA-001] | [Incident / Audit / Review] | [Issue] | [Required action] | [Role] | [Low/Medium/High] | [DD Month YYYY] | [Open / In Progress / Blocked / Closed] | [Summary] | [Evidence ref] | [DD Month YYYY] | [Incident / risk / audit ref] |
+
+## Related Documents
+
+- Corrective Action Procedure
+- Internal Audit Procedure
+- Management Review Procedure
+- Security Incident Handling Procedure

04-registers/incident-register-template.md

@@ -0,0 +1,62 @@
+Title: Incident Register Template
+Document ID: [REG-INCIDENT-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Incident Register Template
+
+## Purpose
+
+This template provides the structure for recording security incidents and tracking their status and outcomes.
+
+## Scope
+
+This register applies to suspected and confirmed information security incidents affecting in-scope people, information, systems, services, suppliers, or customers.
+
+## Data Fields / Expected Columns
+
+The register should record at least:
+
+- incident ID
+- date reported
+- reported by
+- incident title
+- affected asset or service
+- severity
+- status
+- summary
+- containment status
+- notification required
+- owner
+- closure date
+- lessons learned or linked actions
+
+## Ownership
+
+This register should be owned by [Role]. Incident coordinators or handlers should maintain the status and outcome of each entry.
+
+## Update Frequency
+
+The register should be updated when incidents are opened, reclassified, escalated, contained, communicated, or closed.
+
+## Retention
+
+Incident records should be retained in line with legal, contractual, audit, and operational requirements.
+
+## Template Table
+
+| Incident ID | Date Reported | Reported By | Incident Title | Affected Asset / Service | Severity | Status | Summary | Containment Status | Notification Required | Owner | Closure Date | Lessons Learned / Linked Actions |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [INC-001] | [DD Month YYYY] | [Name / Role / System] | [Short title] | [Asset / service] | [Low/Medium/High/Critical] | [Open / Investigating / Contained / Closed] | [Summary] | [In Progress / Complete] | [Yes / No / Under Assessment] | [Role] | [DD Month YYYY] | [Summary / corrective action ref] |
+
+## Related Documents
+
+- Incident Response Policy
+- Security Incident Handling Procedure
+- Breach Notification Procedure
+- Corrective Actions Register Template

04-registers/internal-audit-plan-template.md

@@ -0,0 +1,59 @@
+Title: Internal Audit Plan Template
+Document ID: [REG-AUDIT-PLAN-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Internal Audit Plan Template
+
+## Purpose
+
+This template provides the structure for planning internal ISMS audits across the audit cycle.
+
+## Scope
+
+This plan applies to internal audit activities covering governance, controls, processes, evidence, and improvement actions within the ISMS scope.
+
+## Data Fields / Expected Columns
+
+The audit plan should record at least:
+
+- audit reference
+- audit topic or scope
+- audit criteria
+- planned period
+- assigned auditor
+- auditee or owner
+- status
+- report due date
+- follow-up required
+- notes
+
+## Ownership
+
+This plan should be owned by [Role]. Audit leads should maintain planned dates, status, and follow-up information.
+
+## Update Frequency
+
+The plan should be updated when audits are scheduled, rescheduled, completed, or when follow-up activity changes status.
+
+## Retention
+
+Audit planning records should be retained with related audit outputs in line with retention and audit traceability requirements.
+
+## Template Table
+
+| Audit Reference | Audit Topic / Scope | Audit Criteria | Planned Period | Assigned Auditor | Auditee / Owner | Status | Report Due Date | Follow-up Required | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [AUD-001] | [Topic / area] | [Policy / standard / clause] | [Month / Quarter] | [Name / Role] | [Role / Team] | [Planned / In Progress / Complete] | [DD Month YYYY] | [Yes / No] | [Notes] |
+
+## Related Documents
+
+- Internal Audit Procedure
+- Corrective Action Procedure
+- Management Review Procedure
+- ISMS Manual

04-registers/legal-and-regulatory-obligations-register-template.md

@@ -0,0 +1,61 @@
+Title: Legal and Regulatory Obligations Register Template
+Document ID: [REG-LEGAL-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Legal and Regulatory Obligations Register Template
+
+## Purpose
+
+This template provides the structure for recording legal, regulatory, contractual, and other formal obligations relevant to the ISMS.
+
+## Scope
+
+This register applies to obligations affecting information security, privacy, records, supplier management, incident notification, service delivery, and other in-scope activities.
+
+## Data Fields / Expected Columns
+
+The register should record at least:
+
+- obligation ID
+- source or requirement name
+- obligation type
+- summary of requirement
+- applicable business area
+- owner
+- jurisdiction or context
+- review frequency
+- compliance evidence reference
+- status
+- next review date
+- notes
+
+## Ownership
+
+This register should be owned by [Role]. Individual obligations should have accountable owners responsible for assessing applicability and maintaining evidence.
+
+## Update Frequency
+
+The register should be updated when new obligations are identified, existing obligations change, or review outcomes alter applicability or evidence status.
+
+## Retention
+
+Records should be retained in line with document and records retention requirements and any applicable legal or audit expectations.
+
+## Template Table
+
+| Obligation ID | Source / Requirement Name | Obligation Type | Summary of Requirement | Applicable Area | Owner | Jurisdiction / Context | Review Frequency | Evidence Reference | Status | Next Review Date | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [L-001] | [Law / Contract / Requirement] | [Legal / Regulatory / Contractual] | [Summary] | [Area] | [Role] | [UK / Customer / Multi-jurisdiction] | [Frequency] | [Policy / record / contract] | [Applicable / Under Review / Not Applicable] | [DD Month YYYY] | [Notes] |
+
+## Related Documents
+
+- Privacy and Data Protection Policy
+- Records Retention and Disposal Policy
+- Breach Notification Procedure
+- Document and Records Control Standard

04-registers/management-review-minutes-template.md

@@ -0,0 +1,60 @@
+Title: Management Review Minutes Template
+Document ID: [REG-MGMT-MINUTES-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Management Review Minutes Template
+
+## Purpose
+
+This template provides the structure for recording formal management review meetings and their outputs.
+
+## Scope
+
+This template applies to formal ISMS management reviews, including periodic reviews and exceptional reviews triggered by significant change or incident.
+
+## Data Fields / Expected Columns
+
+The minutes should capture at least:
+
+- meeting date
+- attendees
+- chair
+- scope or agenda
+- review inputs considered
+- decisions made
+- actions agreed
+- action owners
+- due dates
+- overall conclusions
+- next review date
+
+## Ownership
+
+This record should be owned by [Role]. The meeting coordinator should ensure the minutes are complete, approved if required, and retained appropriately.
+
+## Update Frequency
+
+This record should be created for each formal management review meeting and updated until actions are captured and assigned.
+
+## Retention
+
+Management review records should be retained in line with audit, governance, and document retention requirements.
+
+## Template Table
+
+| Meeting Date | Chair | Attendees | Scope / Agenda | Review Inputs Considered | Decisions Made | Actions Agreed | Action Owners | Due Dates | Overall Conclusions | Next Review Date |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [DD Month YYYY] | [Role] | [Names / Roles] | [Agenda summary] | [Objectives / risks / incidents / audits / actions] | [Summary] | [Summary] | [Roles] | [Dates] | [Suitable / adequate / effective summary] | [DD Month YYYY] |
+
+## Related Documents
+
+- Management Review Procedure
+- Information Security Objectives Template
+- Corrective Actions Register Template
+- Internal Audit Plan Template

04-registers/risk-register-template.md

@@ -0,0 +1,65 @@
+Title: Risk Register Template
+Document ID: [REG-RISK-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Risk Register Template
+
+## Purpose
+
+This template provides the structure for recording and tracking information security risks identified within the ISMS scope.
+
+## Scope
+
+This register applies to strategic, operational, project, supplier, exception, and incident-related information security risks.
+
+## Data Fields / Expected Columns
+
+The risk register should record at least:
+
+- risk ID
+- date identified
+- risk title
+- affected asset, service, process, or supplier
+- risk description
+- threat and vulnerability summary
+- impact rating
+- likelihood rating
+- overall risk rating
+- treatment decision
+- treatment actions
+- risk owner
+- target date
+- status
+- review date
+- linked records or evidence
+
+## Ownership
+
+This register should be owned by [Role]. Individual risk entries should have assigned risk owners responsible for treatment and review.
+
+## Update Frequency
+
+The register should be updated when new risks are identified, risk status changes, treatment actions are completed, or review dates are reached. It should be reviewed at least as part of formal management review.
+
+## Retention
+
+Current and superseded versions should be retained in line with document and records retention requirements.
+
+## Template Table
+
+| Risk ID | Date Identified | Risk Title | Affected Asset / Service | Risk Description | Impact | Likelihood | Overall Rating | Treatment Decision | Risk Owner | Target Date | Status | Review Date | Linked Records / Evidence |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [R-001] | [DD Month YYYY] | [Short title] | [System / service / supplier] | [Description] | [Low/Medium/High] | [Low/Medium/High] | [Low/Medium/High] | [Mitigate / Accept / Avoid / Transfer] | [Role] | [DD Month YYYY] | [Open / In Progress / Accepted / Closed] | [DD Month YYYY] | [Risk assessment / exception / incident] |
+
+## Related Documents
+
+- Risk Assessment and Treatment Methodology
+- Risk Assessment Procedure
+- Exception Management Procedure
+- Corrective Action Procedure

04-registers/security-exceptions-register-template.md

@@ -0,0 +1,63 @@
+Title: Security Exceptions Register Template
+Document ID: [REG-EXCEPTION-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Security Exceptions Register Template
+
+## Purpose
+
+This template provides the structure for recording and tracking approved security exceptions and their review status.
+
+## Scope
+
+This register applies to approved deviations from ISMS policies, standards, procedures, and mandatory security controls.
+
+## Data Fields / Expected Columns
+
+The register should record at least:
+
+- exception ID
+- date raised
+- requesting owner
+- affected requirement
+- affected asset, service, or process
+- business justification
+- risk summary
+- compensating controls
+- approver
+- approval date
+- expiry date
+- status
+- review date
+- linked risk or action
+
+## Ownership
+
+This register should be owned by [Role]. Exception owners are responsible for maintaining current status and closing exceptions when no longer needed.
+
+## Update Frequency
+
+The register should be updated when exceptions are requested, approved, rejected, renewed, reviewed, or closed.
+
+## Retention
+
+Current and historical exception records should be retained for auditability and risk traceability in line with retention requirements.
+
+## Template Table
+
+| Exception ID | Date Raised | Requesting Owner | Affected Requirement | Affected Asset / Service | Business Justification | Risk Summary | Compensating Controls | Approver | Approval Date | Expiry Date | Status | Review Date | Linked Risk / Action |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [E-001] | [DD Month YYYY] | [Role] | [Policy / standard / control] | [Asset / service] | [Reason] | [Summary] | [Controls] | [Role] | [DD Month YYYY] | [DD Month YYYY] | [Requested / Approved / Rejected / Closed] | [DD Month YYYY] | [Risk / corrective action] |
+
+## Related Documents
+
+- Exception Management Procedure
+- Risk Assessment Procedure
+- Information Security Policy
+- Risk Register Template

04-registers/supplier-register-template.md

@@ -0,0 +1,61 @@
+Title: Supplier Register Template
+Document ID: [REG-SUPPLIER-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Supplier Register Template
+
+## Purpose
+
+This template provides the structure for recording suppliers relevant to the ISMS and tracking their assurance and review status.
+
+## Scope
+
+This register applies to suppliers, service providers, subprocessors, hosting providers, and other third parties that may affect information security, privacy, resilience, or service delivery.
+
+## Data Fields / Expected Columns
+
+The supplier register should record at least:
+
+- supplier name
+- service provided
+- internal supplier owner
+- risk tier
+- information or access profile
+- contract status
+- assurance status
+- last review date
+- next review date
+- open actions
+- status
+- linked risks or incidents
+
+## Ownership
+
+This register should be owned by [Role]. Each supplier entry should have a named internal owner responsible for review and follow-up.
+
+## Update Frequency
+
+The register should be updated when suppliers are onboarded, reassessed, changed, renewed, suspended, or offboarded. Review dates should reflect risk-based oversight.
+
+## Retention
+
+Supplier records should be retained in line with business, contractual, legal, and assurance needs.
+
+## Template Table
+
+| Supplier Name | Service Provided | Internal Owner | Risk Tier | Information / Access Profile | Contract Status | Assurance Status | Last Review Date | Next Review Date | Open Actions | Status | Linked Risks / Incidents |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [Supplier] | [Service] | [Role] | [Low/Medium/High] | [Access / data handled] | [Draft / Active / Expiring] | [Pending / Reviewed / Limited] | [DD Month YYYY] | [DD Month YYYY] | [Summary] | [Proposed / Active / Offboarded] | [Risk / incident refs] |
+
+## Related Documents
+
+- Supplier Security Policy
+- Supplier Due Diligence Standard
+- Supplier Onboarding and Review Procedure
+- Risk Register Template

04-registers/training-and-awareness-record-template.md

@@ -0,0 +1,59 @@
+Title: Training and Awareness Record Template
+Document ID: [REG-TRAINING-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Training and Awareness Record Template
+
+## Purpose
+
+This template provides the structure for recording completion of security training and awareness activities.
+
+## Scope
+
+This record applies to employees, contractors, and other personnel who are required to complete information security training, awareness, or role-specific security education.
+
+## Data Fields / Expected Columns
+
+The record should capture at least:
+
+- participant name or identifier
+- role or team
+- training or awareness activity
+- training type
+- assigned date
+- completion date
+- completion status
+- evidence reference
+- next due date
+- notes
+
+## Ownership
+
+This record should be owned by [Role]. Managers and training coordinators should support completion tracking where relevant.
+
+## Update Frequency
+
+The record should be updated when training is assigned, completed, refreshed, or overdue status changes.
+
+## Retention
+
+Training records should be retained in line with internal, contractual, and audit requirements.
+
+## Template Table
+
+| Participant | Role / Team | Training Activity | Training Type | Assigned Date | Completion Date | Status | Evidence Reference | Next Due Date | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [Name / ID] | [Role / Team] | [Course / briefing / exercise] | [Induction / Annual / Role-specific] | [DD Month YYYY] | [DD Month YYYY] | [Assigned / Completed / Overdue] | [Record / certificate / system ref] | [DD Month YYYY] | [Notes] |
+
+## Related Documents
+
+- Human Resources Security Policy
+- Information Security Policy
+- Joiner Mover Leaver Procedure
+- Management Review Procedure

05-guidance/README.md

@@ -0,0 +1,19 @@
+# ISMS Guidance Notes
+
+This folder contains supporting guidance for applying the ISMS document set consistently.
+
+Guidance notes are intended to help document owners, reviewers, and operational teams interpret and use the controlled documents. They do not replace policies, standards, procedures, or registers, and they must not be used to override controlled requirements.
+
+## Current Guidance Set
+
+- `document-owner-guidance.md`
+- `evidence-and-audit-readiness-guidance.md`
+- `risk-and-exception-writing-guidance.md`
+- `supplier-assurance-guidance.md`
+- `secure-change-and-deployment-guidance.md`
+
+## How To Use Guidance
+
+- Start with the relevant policy, standard, procedure, or register.
+- Use the guidance note to understand expected depth, evidence quality, and practical interpretation.
+- Where guidance appears to conflict with a controlled document, the controlled document takes precedence.

05-guidance/document-owner-guidance.md

@@ -0,0 +1,62 @@
+# Document Owner Guidance
+
+## Purpose
+
+This guidance note helps document owners maintain ISMS documents consistently and with the right level of quality.
+
+## Who This Is For
+
+This note is for document owners, approvers, reviewers, and anyone asked to update controlled ISMS documents.
+
+## What Good Looks Like
+
+A well-maintained ISMS document should:
+
+- reflect how BlackDice actually operates
+- avoid invented tools, teams, or approvals
+- use clear ownership and review dates
+- align with the related policy, standard, procedure, or register
+- be specific enough to guide behaviour without turning policy into procedure
+
+## Practical Owner Checks
+
+Before updating or approving a document, check:
+
+- the metadata is complete and current
+- the document purpose and scope still match reality
+- cross-references point to the right current documents
+- placeholders still in the document are genuinely unresolved
+- statements about control operation are supportable with evidence
+- the document still fits its type
+
+Policy should say what BlackDice requires.
+
+Standard should say what must be implemented.
+
+Procedure should say how an activity is carried out.
+
+Register or template should say what information must be recorded.
+
+## When A Document Should Be Updated
+
+Review or update the document when:
+
+- the review date is due
+- a control or process changes materially
+- audit or incident findings show it is inaccurate
+- ownership changes
+- supplier, legal, or customer obligations materially change the requirement
+
+## Common Mistakes To Avoid
+
+- keeping placeholders that are already known
+- writing future-state wording as if it is already operational
+- duplicating the same requirement in too many places
+- adding procedural detail into policy documents
+- leaving evidence expectations unclear
+
+## Related Documents
+
+- `../../00-governance/document-and-records-control-standard.md`
+- `../../00-governance/isms-manual.md`
+- `../../00-governance/information-security-policy.md`

05-guidance/evidence-and-audit-readiness-guidance.md

@@ -0,0 +1,61 @@
+# Evidence And Audit Readiness Guidance
+
+## Purpose
+
+This guidance note explains how to think about evidence quality for ISMS operation, internal audit, customer assurance, and management review.
+
+## Evidence Principles
+
+Good evidence should be:
+
+- factual
+- dated
+- attributable to a person, team, or system
+- traceable to a requirement or activity
+- easy to retrieve during review
+
+## Typical Evidence Types
+
+Useful evidence may include:
+
+- approved documents and revision history
+- completed register entries
+- access review outputs
+- change and deployment records
+- incident records and lessons learned
+- supplier review records
+- training completion records
+- audit reports and corrective actions
+
+## What Makes Evidence Weak
+
+Evidence is weak when it:
+
+- is undated
+- cannot be linked to a control or process
+- exists only as informal verbal confirmation
+- contradicts the documented process
+- shows intent but not execution
+
+## Practical Readiness Checks
+
+For important controls, BlackDice should be able to answer:
+
+- what is the requirement
+- who owns it
+- what records show it operates
+- how often it is reviewed
+- what happens when it fails or is overdue
+
+## Working Approach
+
+Where possible, use the operational system of record rather than duplicating evidence manually. If the record sits outside this repository, the related ISMS document should make that clear.
+
+For recurring controls, consistent evidence matters more than polished presentation. A complete and repeatable record is usually more useful than a manually curated summary.
+
+## Related Documents
+
+- `../../00-governance/document-and-records-control-standard.md`
+- `../../03-procedures/internal-audit-procedure.md`
+- `../../03-procedures/management-review-procedure.md`
+- `../../04-registers/internal-audit-plan-template.md`

05-guidance/risk-and-exception-writing-guidance.md

@@ -0,0 +1,74 @@
+# Risk And Exception Writing Guidance
+
+## Purpose
+
+This guidance note helps authors write clearer risk entries, treatment actions, and exception justifications.
+
+## Writing A Useful Risk Entry
+
+A good risk entry should explain:
+
+- what could happen
+- what asset, service, or process is affected
+- why the risk exists
+- what the likely impact is
+- what will be done about it
+
+Short, vague statements such as "security risk exists" are not useful.
+
+## Better Risk Framing
+
+Try to describe risk in terms of:
+
+- threat or failure scenario
+- vulnerability or weakness
+- business or security impact
+
+For example, instead of:
+
+- "Kubernetes risk"
+
+prefer something closer to:
+
+- "Overly permissive cluster administration could allow unauthorised production changes and service disruption."
+
+## Writing Treatment Actions
+
+Treatment actions should be:
+
+- specific
+- owned
+- time-bounded
+- observable when complete
+
+Avoid actions such as:
+
+- "Improve security"
+
+Prefer:
+
+- "Restrict production cluster administration to approved roles and complete access review by [date]."
+
+## Writing A Good Exception Justification
+
+A good exception request should explain:
+
+- what requirement cannot currently be met
+- why that is the case
+- what temporary risk is introduced
+- what compensating controls exist
+- when the exception should expire or be reviewed
+
+## Common Problems
+
+- exception requests with no expiry or review date
+- accepted risks with no named owner
+- treatment actions that describe analysis but not action
+- language that hides impact or uncertainty
+
+## Related Documents
+
+- `../../00-governance/risk-assessment-and-treatment-methodology.md`
+- `../../03-procedures/risk-assessment-procedure.md`
+- `../../03-procedures/exception-management-procedure.md`
+- `../../04-registers/risk-register-template.md`

05-guidance/secure-change-and-deployment-guidance.md

@@ -0,0 +1,57 @@
+# Secure Change And Deployment Guidance
+
+## Purpose
+
+This guidance note helps engineering and operational teams apply the change and deployment controls consistently in a cloud-native environment.
+
+## Key Principle
+
+The goal is not to slow change down. The goal is to make production change deliberate, traceable, and recoverable.
+
+## What Deserves More Scrutiny
+
+Higher-risk changes usually include:
+
+- authentication or authorisation changes
+- changes affecting production access or secrets
+- Kubernetes or infrastructure changes
+- CI/CD pipeline changes
+- logging or monitoring changes
+- customer-impacting configuration changes
+
+## Minimum Practical Checks Before Deployment
+
+Before a production deployment, confirm:
+
+- the change is reviewed and approved at the right level
+- the deployment path is the approved one
+- rollback or recovery is understood
+- monitoring exists to detect failure quickly
+- any customer or operational communication need is understood
+
+## Emergency Change Discipline
+
+Emergency change does not mean uncontrolled change. If a shortcut is needed during an incident or outage, the record still needs to show:
+
+- why the shortcut was necessary
+- who made the decision
+- what was changed
+- what retrospective review is required
+
+## Evidence To Keep
+
+Useful deployment evidence often includes:
+
+- change approval
+- code review or pipeline traceability
+- deployment timestamp
+- deployment owner
+- validation results
+- rollback or follow-up actions where relevant
+
+## Related Documents
+
+- `../../01-policies/change-management-policy.md`
+- `../../02-standards/ci-cd-security-standard.md`
+- `../../03-procedures/change-approval-procedure.md`
+- `../../03-procedures/production-deployment-procedure.md`

05-guidance/supplier-assurance-guidance.md

@@ -0,0 +1,56 @@
+# Supplier Assurance Guidance
+
+## Purpose
+
+This guidance note helps supplier owners and reviewers apply the supplier security documents in a proportionate way.
+
+## Focus On Material Suppliers
+
+Not every supplier needs the same depth of review. More attention should be given to suppliers that:
+
+- host or process important BlackDice data
+- support production service delivery
+- have privileged access
+- affect resilience or customer commitments
+- operate as subprocessors or critical dependencies
+
+## Questions To Ask During Review
+
+Useful supplier review questions often include:
+
+- what service is actually being provided
+- what information is handled
+- what access is granted
+- what happens if the supplier fails
+- what evidence exists for security and resilience
+- what notification obligations apply
+
+## Shared Responsibility
+
+For cloud and managed platforms, supplier review should not stop at "provider is certified". The practical question is which controls remain with BlackDice and which are delivered by the supplier.
+
+That matters most for:
+
+- identity and access
+- configuration
+- logging
+- backup and recovery
+- incident handling
+- data location and retention
+
+## When To Reassess
+
+Reassessment should be triggered when:
+
+- the supplier's role expands
+- the deployment model changes
+- a major incident occurs
+- assurance evidence becomes stale
+- customer or regulatory expectations change
+
+## Related Documents
+
+- `../../01-policies/supplier-security-policy.md`
+- `../../02-standards/supplier-due-diligence-standard.md`
+- `../../03-procedures/supplier-onboarding-and-review-procedure.md`
+- `../../04-registers/supplier-register-template.md`

06-audit-and-review/README.md

@@ -0,0 +1,19 @@
+# Audit And Review Artefacts
+
+This folder contains working artefacts and output templates used to operate the ISMS assurance and review cycle.
+
+Unlike the controlled policy, standard, procedure, and register set, documents in this folder are intended to support execution of audit, management review, and periodic control review activities. Some artefacts may become records of performed activities once completed.
+
+## Current Artefacts
+
+- `internal-audit-report-template.md`
+- `internal-audit-working-paper-template.md`
+- `management-review-pack-template.md`
+- `control-review-note-template.md`
+- `audit-and-review-evidence-log-template.md`
+
+## How To Use This Folder
+
+- Use the procedure set in `../03-procedures` to determine when and how the activity should be performed.
+- Use the templates in this folder to capture working notes, outputs, and review evidence consistently.
+- Where a completed artefact becomes part of the formal ISMS record, retain it in line with document and records retention requirements.

06-audit-and-review/audit-and-review-evidence-log-template.md

@@ -0,0 +1,63 @@
+Title: Audit and Review Evidence Log Template
+Document ID: [REVIEW-EVIDENCE-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Audit And Review Evidence Log Template
+
+## Purpose
+
+This template provides a simple log for tracking evidence collected or referenced during audit and management review activity.
+
+## Scope
+
+This log applies to evidence used in internal audits, management reviews, control reviews, and follow-up assurance activity.
+
+## Data Fields / Expected Columns
+
+The log should record at least:
+
+- evidence reference
+- activity type
+- related audit or review
+- evidence description
+- source location
+- owner
+- date collected or reviewed
+- reviewer
+- notes
+
+## Ownership
+
+This log should be owned by CISO (Paul Jenkins) or a delegated assurance coordinator.
+
+## Update Frequency
+
+The log should be updated as evidence is requested, reviewed, or added to an audit or review pack.
+
+## Retention
+
+Completed logs should be retained with the associated audit or review records in line with retention requirements.
+
+## Template Table
+
+| Evidence Reference | Activity Type | Related Audit / Review | Evidence Description | Source Location | Owner | Date Collected / Reviewed | Reviewer | Notes |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [EV-001] | [Audit / Management Review / Control Review] | [Reference] | [Description] | [Path / system / link reference] | [Role] | [DD Month YYYY] | [Name / Role] | [Notes] |
+
+## Related Documents
+
+- Internal Audit Procedure
+- Management Review Procedure
+- Evidence and Audit Readiness Guidance
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

06-audit-and-review/control-review-note-template.md

@@ -0,0 +1,61 @@
+Title: Control Review Note Template
+Document ID: [REVIEW-CONTROL-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Control Review Note Template
+
+## Purpose
+
+This template provides a lightweight format for recording periodic review of a specific control, process, or requirement outside a full internal audit.
+
+## Review Details
+
+- Review title: [Title]
+- Control or process reviewed: [Name]
+- Review owner: [Role]
+- Review date: [DD Month YYYY]
+- Review period: [Period]
+
+## Review Objective
+
+[State what the review was intended to confirm.]
+
+## Evidence Considered
+
+- [Document or record]
+- [System output]
+- [Interview or walkthrough]
+
+## Review Outcome
+
+| Area Reviewed | Result | Notes | Follow-up Required |
+| --- | --- | --- | --- |
+| [Area] | [Effective / Partially Effective / Ineffective] | [Notes] | [Yes / No] |
+
+## Issues Or Improvement Notes
+
+[Summarise any concerns, gaps, or good practice observed.]
+
+## Actions
+
+| Action | Owner | Due Date | Status |
+| --- | --- | --- | --- |
+| [Action] | [Role] | [DD Month YYYY] | [Open / Closed] |
+
+## Related Documents
+
+- Internal Audit Procedure
+- Management Review Procedure
+- Corrective Action Procedure
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

06-audit-and-review/internal-audit-report-template.md

@@ -0,0 +1,82 @@
+Title: Internal Audit Report Template
+Document ID: [AUD-REPORT-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Internal Audit Report Template
+
+## Purpose
+
+This template provides a consistent structure for reporting the outcome of an internal ISMS audit.
+
+## Audit Details
+
+- Audit reference: [AUD-XXX]
+- Audit title: [Title]
+- Audit scope: [Scope]
+- Audit criteria: [Policies, standards, procedures, clauses, or other criteria]
+- Audit period: [DD Month YYYY to DD Month YYYY]
+- Auditor(s): [Name / Role]
+- Auditee(s): [Name / Role / Team]
+- Report date: [DD Month YYYY]
+
+## Audit Objective
+
+[State the purpose of the audit and what it was intended to confirm.]
+
+## Summary Conclusion
+
+[Summarise whether the audited area appears conformant, effective, partially effective, or materially deficient.]
+
+## Work Performed
+
+Describe the work completed, for example:
+
+- document review
+- interviews
+- walkthroughs
+- sample testing
+- evidence review
+
+## Findings
+
+| Finding ID | Rating | Requirement / Criteria | Finding Summary | Evidence Reference | Owner | Due Date |
+| --- | --- | --- | --- | --- | --- | --- |
+| [F-001] | [Observation / Minor / Major] | [Requirement] | [Summary] | [Evidence] | [Role] | [DD Month YYYY] |
+
+## Positive Practices
+
+[Record notable strengths, effective controls, or improvements observed.]
+
+## Nonconformities And Improvement Areas
+
+[Summarise the main control gaps, recurring issues, or themes.]
+
+## Agreed Actions
+
+| Action ID | Action Description | Owner | Target Date | Linked Finding |
+| --- | --- | --- | --- | --- |
+| [CA-001] | [Action] | [Role] | [DD Month YYYY] | [F-001] |
+
+## Distribution
+
+- [Role / Team]
+- [Role / Team]
+
+## Related Documents
+
+- Internal Audit Procedure
+- Internal Audit Plan Template
+- Corrective Action Procedure
+- Corrective Actions Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

06-audit-and-review/internal-audit-working-paper-template.md

@@ -0,0 +1,73 @@
+Title: Internal Audit Working Paper Template
+Document ID: [AUD-WP-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Internal Audit Working Paper Template
+
+## Purpose
+
+This template provides a structure for audit planning notes, sample records, evidence references, and evaluator observations during an internal audit.
+
+## Audit Details
+
+- Audit reference: [AUD-XXX]
+- Audit topic: [Topic]
+- Auditor: [Name / Role]
+- Date(s): [DD Month YYYY]
+- Area reviewed: [Team / Service / Control Area]
+
+## Audit Criteria
+
+- [Criterion 1]
+- [Criterion 2]
+- [Criterion 3]
+
+## Sample Plan
+
+| Sample Item | Population | Selection Basis | Sample Size | Notes |
+| --- | --- | --- | --- | --- |
+| [Access review records] | [Population] | [Risk / judgement / random] | [Number] | [Notes] |
+
+## Evidence Reviewed
+
+| Evidence Reference | Evidence Description | Date Reviewed | Source | Observation |
+| --- | --- | --- | --- | --- |
+| [EV-001] | [Description] | [DD Month YYYY] | [System / document / interview] | [Observation] |
+
+## Interviews And Walkthroughs
+
+| Interviewee | Role | Date | Topic | Key Notes |
+| --- | --- | --- | --- | --- |
+| [Name] | [Role] | [DD Month YYYY] | [Topic] | [Notes] |
+
+## Auditor Assessment Notes
+
+### Conformant Areas
+
+[Notes]
+
+### Gaps Or Concerns
+
+[Notes]
+
+### Follow-up Questions
+
+[Notes]
+
+## Related Documents
+
+- Internal Audit Procedure
+- Internal Audit Report Template
+- Evidence and Audit Readiness Guidance
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |

06-audit-and-review/management-review-pack-template.md

@@ -0,0 +1,101 @@
+Title: Management Review Pack Template
+Document ID: [MR-PACK-001]
+Version: 0.1 Draft
+Status: Draft
+Owner: CISO (Paul Jenkins)
+Approver: CISO (Paul Jenkins)
+Classification: Internal
+Effective date: [DD Month YYYY]
+Review date: [DD Month YYYY]
+
+# Management Review Pack Template
+
+## Purpose
+
+This template provides a consistent structure for assembling the inputs to a formal ISMS management review.
+
+## Review Details
+
+- Review period: [Period]
+- Review date: [DD Month YYYY]
+- Chair: [Role]
+- Participants: [Names / Roles]
+- Prepared by: [Role]
+
+## Executive Summary
+
+[Summarise the overall status of the ISMS and the key decisions required.]
+
+## Review Inputs
+
+### Information Security Objectives
+
+- current objectives status
+- missed targets or at-risk items
+- proposed new or revised objectives
+
+### Risk And Exception Status
+
+- top open risks
+- newly accepted risks
+- expired or overdue exceptions
+- themes requiring management attention
+
+### Incident And Breach Summary
+
+- material incidents during the period
+- lessons learned
+- any notifiable or high-impact events
+
+### Audit And Assurance Summary
+
+- audits completed
+- key findings and themes
+- overdue corrective actions
+
+### Supplier And Dependency Issues
+
+- key supplier reviews
+- assurance gaps
+- material supplier incidents or changes
+
+### Change And Operational Themes
+
+- significant change failures or concerns
+- recurring operational issues
+- resilience or recovery concerns
+
+### Training And Awareness
+
+- completion status
+- overdue or role-specific gaps
+
+### Improvement Opportunities
+
+- proposed control improvements
+- resourcing or prioritisation needs
+
+## Decisions Required
+
+| Decision Area | Summary | Proposed Decision | Owner |
+| --- | --- | --- | --- |
+| [Area] | [Summary] | [Decision] | [Role] |
+
+## Actions Proposed
+
+| Action | Owner | Target Date | Priority | Linked Input |
+| --- | --- | --- | --- | --- |
+| [Action] | [Role] | [DD Month YYYY] | [Low/Medium/High] | [Risk / audit / incident / objective] |
+
+## Related Documents
+
+- Management Review Procedure
+- Management Review Minutes Template
+- Information Security Objectives Template
+- Corrective Actions Register Template
+
+## Version Control
+
+| Version | Date | Description of Change | Author |
+| --- | --- | --- | --- |
+| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |