48 KiB
48 KiB
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
- Replace draft evidence references with actual system-of-record locations, reports, tickets, or operating evidence.
- Confirm whether any controls should be assigned to a function other than the CISO as control owner.
- Add an implementation status date and review cadence for each control.
- Identify any controls that should move from
Documented BaselineorPartially ImplementedtoImplementedonce 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 |