Initial commit

03-procedures/access-review-procedure.md

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

03-procedures/backup-testing-procedure.md

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

03-procedures/breach-notification-procedure.md

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

03-procedures/change-approval-procedure.md

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

03-procedures/corrective-action-procedure.md

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

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

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

03-procedures/exception-management-procedure.md

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

03-procedures/internal-audit-procedure.md

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

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

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

03-procedures/management-review-procedure.md

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

03-procedures/patch-management-procedure.md

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

03-procedures/production-deployment-procedure.md

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

03-procedures/risk-assessment-procedure.md

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

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

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

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

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

03-procedures/vulnerability-management-procedure.md

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