Initial commit

05-guidance/README.md

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

05-guidance/document-owner-guidance.md

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

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

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

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

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

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

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

05-guidance/supplier-assurance-guidance.md

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