Initial commit
This commit is contained in:
68
02-standards/data-retention-standard.md
Normal file
68
02-standards/data-retention-standard.md
Normal file
@@ -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] |
|
||||
Reference in New Issue
Block a user