Files

Danijel Martinek d32464c94b docs(compliance): add skeleton policy templates (backup, password, device, onboarding, offboarding)

Five skeleton templates for docs/compliance/templates/. Each has YAML
frontmatter (status: template, playbook-section), a "not code-enforced"
banner, and [FILL IN:] markers throughout. password-policy banner cites
ADR-025 §Deferred items by number (MFA + password policy + lockout
deferral). Cross-template relative links all resolve.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-05-20 12:20:35 +00:00

4.2 KiB

Raw Blame History

status, playbook-section, title, last-reviewed

status	playbook-section	title	last-reviewed
template	30	Backup & Data Retention Policy	[FILL IN: YYYY-MM-DD]

Backup & Data Retention Policy

Template status — fill every [FILL IN: …] marker before use.

Not code-enforced — this policy describes operational and organisational controls that are implemented outside the application codebase (infrastructure, vendor configuration, runbooks). The template authors intentionally do not ship backup or retention logic in the template; the consumer supplies those controls.

1. Purpose & Scope

This policy defines how [FILL IN: organisation name] backs up, retains, and securely disposes of personal data and system data held in [FILL IN: describe systems in scope — e.g., PostgreSQL database, object storage, CMS content].

Owner: [FILL IN: role — e.g., Head of Engineering / DPO]

2. Backup Schedule

Data store	Backup frequency	Retention period	Storage location
`[FILL IN: primary database]`	`[FILL IN: e.g., daily]`	`[FILL IN: e.g., 30 days]`	`[FILL IN: e.g., encrypted S3 bucket]`
`[FILL IN: CMS media / uploads]`	`[FILL IN: e.g., daily]`	`[FILL IN: e.g., 90 days]`	`[FILL IN: e.g., object storage]`
`[FILL IN: log data]`	`[FILL IN: e.g., weekly]`	`[FILL IN: e.g., 12 months]`	`[FILL IN: e.g., SIEM / log archive]`
`[FILL IN: any other data store]`	`[FILL IN:]`	`[FILL IN:]`	`[FILL IN:]`

3. Encryption & Access

All backups are encrypted at rest using [FILL IN: algorithm / key service — e.g., AES-256 via AWS KMS].
Backup encryption keys are managed by [FILL IN: key custodian / key management service].
Access to backup storage is restricted to [FILL IN: roles — e.g., infrastructure team, on-call engineers] and controlled via [FILL IN: IAM policy / vault policy].

4. Restore Procedure

[FILL IN: describe how a restore request is initiated — e.g., ticket to #infra-ops]
[FILL IN: describe authentication / authorisation required before restore begins]
[FILL IN: describe restore steps for each data store]
Verify data integrity after restore: [FILL IN: checksum / row-count / smoke-test procedure]
Log the restore event in [FILL IN: audit log / incident tracker].

Recovery Time Objective (RTO): [FILL IN: e.g., 4 hours]

Recovery Point Objective (RPO): [FILL IN: e.g., 24 hours]

5. Data Retention & Disposal

Data category	Retention period	Disposal method
`[FILL IN: user account data]`	`[FILL IN: e.g., account lifetime + 30 days post-erasure request]`	`[FILL IN: cryptographic erasure / secure delete]`
`[FILL IN: audit log entries]`	`[FILL IN: e.g., 7 years]`	`[FILL IN: automated purge job]`
`[FILL IN: application logs]`	`[FILL IN: e.g., 12 months]`	`[FILL IN: log rotation / SIEM TTL]`
`[FILL IN: marketing contact data]`	`[FILL IN:]`	`[FILL IN:]`

Disposal is triggered by [FILL IN: describe the trigger — e.g., automated retention job, manual review cycle] and verified by [FILL IN: describe the verification step].

6. Testing

Backup restores are tested [FILL IN: frequency — e.g., quarterly] by [FILL IN: role]. Results are recorded in [FILL IN: location — e.g., the infra runbook wiki].

7. Review Cycle

This policy is reviewed [FILL IN: frequency — e.g., annually] or after any material change to the backup infrastructure. The next scheduled review is [FILL IN: YYYY-MM-DD].

4.2 KiB Raw Blame History