Initial commit

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

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

02-standards/data-retention-standard.md

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

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

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

02-standards/kubernetes-security-standard.md

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

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

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

02-standards/secrets-management-standard.md

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

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

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

02-standards/secure-configuration-standard.md

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

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

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