psjenkins/ISMS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Paul Jenkins
2026-03-26 09:35:22 +00:00
parent 0d73f76688
commit 5eade2d99b
76 changed files with 5512 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
00-governance/document-and-records-control-standard.md Normal file
View File

@@ -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] |

70
00-governance/information-security-objectives-template.md Normal file
View File

@@ -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

87
00-governance/information-security-policy.md Normal file
View File

@@ -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] |

107
00-governance/isms-manual.md Normal file
View File

@@ -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] |

104
00-governance/isms-scope-statement.md Normal file
View File

@@ -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] |

124
00-governance/risk-assessment-and-treatment-methodology.md Normal file
View File

@@ -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] |

72
00-governance/statement-of-applicability-template.md Normal file
View File

@@ -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

198
00-governance/statement-of-applicability.md Normal file
View File

@@ -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 |