diff --git a/docs/compliance/templates/backup-policy.template.md b/docs/compliance/templates/backup-policy.template.md new file mode 100644 index 0000000..4316699 --- /dev/null +++ b/docs/compliance/templates/backup-policy.template.md @@ -0,0 +1,78 @@ +--- +status: template +playbook-section: 30 +title: "Backup & Data Retention Policy" +last-reviewed: "[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 + +1. `[FILL IN: describe how a restore request is initiated — e.g., ticket to #infra-ops]` +2. `[FILL IN: describe authentication / authorisation required before restore begins]` +3. `[FILL IN: describe restore steps for each data store]` +4. Verify data integrity after restore: `[FILL IN: checksum / row-count / smoke-test procedure]` +5. 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]`. diff --git a/docs/compliance/templates/device-policy.template.md b/docs/compliance/templates/device-policy.template.md new file mode 100644 index 0000000..a44f447 --- /dev/null +++ b/docs/compliance/templates/device-policy.template.md @@ -0,0 +1,86 @@ +--- +status: template +playbook-section: 50 +title: "Acceptable Use & Device Policy" +last-reviewed: "[FILL IN: YYYY-MM-DD]" +--- + +# Acceptable Use & Device Policy + +> **Template status** — fill every `[FILL IN: …]` marker before use. + +> **Not code-enforced** — device management, endpoint security, and acceptable-use controls are implemented outside the application codebase (MDM, EDR, organisational policy). This template documents those controls; the consumer configures and enforces them at the infrastructure and HR level. + +--- + +## 1. Purpose & Scope + +This policy defines the acceptable use of devices and systems for all personnel — employees, contractors, and third-party service providers — who access `[FILL IN: organisation name]`'s systems, data, or networks. + +**Owner:** `[FILL IN: role — e.g., CISO / Head of Engineering]` + +--- + +## 2. Covered Devices + +| Device type | Management requirement | +| -------------------------------------- | -------------------------------------- | +| Company-issued laptops / desktops | `[FILL IN: MDM solution]` | +| Personal devices (BYOD) — if permitted | `[FILL IN: MDM profile / prohibition]` | +| Mobile phones (company-issued) | `[FILL IN:]` | +| Personal mobile devices (BYOD) | `[FILL IN:]` | + +BYOD is `[FILL IN: permitted / not permitted]`. If permitted: `[FILL IN: describe BYOD enrolment requirements]`. + +--- + +## 3. Required Endpoint Controls + +All devices accessing production systems or personal data MUST have: + +- [ ] Full-disk encryption enabled: `[FILL IN: e.g., FileVault / BitLocker / dm-crypt]` +- [ ] Endpoint protection (antivirus / EDR): `[FILL IN: product name]` +- [ ] Automatic OS and software updates enabled +- [ ] Screen lock after `[FILL IN: e.g., 5 minutes]` of inactivity +- [ ] Strong device passcode / PIN (minimum `[FILL IN: e.g., 8 characters]`) +- [ ] Remote-wipe capability enrolled: `[FILL IN: MDM / tool]` +- [ ] VPN required for access to `[FILL IN: e.g., production database, staging environment]` + +--- + +## 4. Acceptable Use + +### 4.1 Permitted uses + +- Business activities of `[FILL IN: organisation name]` +- Reasonable personal use that does not interfere with professional responsibilities +- `[FILL IN: any additional permitted uses]` + +### 4.2 Prohibited uses + +- Accessing, storing, or processing personal data outside approved systems +- Installing unapproved software on managed devices: `[FILL IN: software approval process]` +- Sharing credentials or device access with unauthorised parties +- Using personal cloud storage for business data: `[FILL IN: exceptions, if any]` +- `[FILL IN: any organisation-specific prohibitions]` + +--- + +## 5. Lost or Stolen Devices + +1. Report immediately to `[FILL IN: contact — e.g., IT helpdesk / security@org]`. +2. Remote wipe is initiated within `[FILL IN: e.g., 2 hours]` of report. +3. The incident is assessed for personal-data impact and escalated to the incident runbook if PII was accessible (see [`incident-runbook.template.md`](./incident-runbook.template.md)). +4. Document in `[FILL IN: incident tracker]`. + +--- + +## 6. Device Return & Offboarding + +On termination or role change, devices are returned within `[FILL IN: e.g., 1 business day]` and wiped via `[FILL IN: wipe procedure]`. See [`offboarding.template.md`](./offboarding.template.md) for the full offboarding checklist. + +--- + +## 7. Review Cycle + +This policy is reviewed `[FILL IN: frequency — e.g., annually]`. The next scheduled review is `[FILL IN: YYYY-MM-DD]`. diff --git a/docs/compliance/templates/offboarding.template.md b/docs/compliance/templates/offboarding.template.md new file mode 100644 index 0000000..3369b2f --- /dev/null +++ b/docs/compliance/templates/offboarding.template.md @@ -0,0 +1,103 @@ +--- +status: template +playbook-section: 70 +title: "Staff Offboarding Checklist (Data Access & Security)" +last-reviewed: "[FILL IN: YYYY-MM-DD]" +--- + +# Staff Offboarding Checklist (Data Access & Security) + +> **Template status** — fill every `[FILL IN: …]` marker before use. + +> **Not code-enforced** — access revocation, device return, and data-handover steps are operational controls implemented outside the application codebase. The consumer is responsible for integrating this checklist into their HR and IT offboarding workflow and ensuring it is completed before the final day. + +--- + +## 1. Purpose & Scope + +This checklist ensures that all access, devices, and personal data are securely handled when an employee, contractor, or third-party leaves `[FILL IN: organisation name]` or changes role. + +**Owner:** `[FILL IN: role — e.g., HR / People Ops + IT]` + +**Trigger:** Employment or engagement termination (voluntary or involuntary), role transfer requiring access scope change, contractor end-of-engagement. + +--- + +## 2. Before Final Day — Immediate Actions (Involuntary / High-Risk Departure) + +> Complete this section on the same day for involuntary terminations or where data-exfiltration risk is elevated. + +| # | Task | Owner | Done | +| --- | -------------------------------------------------------------------------------------- | ------------------------ | ---- | +| 1 | Suspend IdP account (`[FILL IN: provider]`) — do NOT delete yet (preserve audit trail) | `[FILL IN: IT]` | ☐ | +| 2 | Revoke active sessions / tokens for all systems | `[FILL IN: IT]` | ☐ | +| 3 | Rotate any shared secrets the individual had access to: `[FILL IN: list]` | `[FILL IN: engineering]` | ☐ | +| 4 | Preserve a copy of the departing individual's work output per data-retention policy | `[FILL IN: manager]` | ☐ | + +--- + +## 3. Final Day — Access Revocation + +| # | System / tool | Action | Confirmed by | Done | +| --- | ----------------------------------------------------------------------------------- | ------------------------------- | ------------ | ---- | +| 1 | `[FILL IN: e.g., GitHub org]` | Remove from org / teams | `[FILL IN:]` | ☐ | +| 2 | `[FILL IN: e.g., Payload CMS admin]` | Delete or deactivate user | `[FILL IN:]` | ☐ | +| 3 | `[FILL IN: e.g., cloud console / IAM]` | Revoke all policies | `[FILL IN:]` | ☐ | +| 4 | `[FILL IN: e.g., monitoring / Sentry]` | Remove member | `[FILL IN:]` | ☐ | +| 5 | `[FILL IN: e.g., HR / payroll system]` | Deactivate | `[FILL IN:]` | ☐ | +| 6 | `[FILL IN: e.g., communication tools]` | Deactivate / transfer ownership | `[FILL IN:]` | ☐ | +| 7 | `[FILL IN: any other system]` | `[FILL IN: action]` | `[FILL IN:]` | ☐ | +| 8 | IdP account: move to suspended → delete after `[FILL IN: e.g., 30-day]` hold period | IT | `[FILL IN:]` | ☐ | + +--- + +## 4. Device Return + +| # | Task | Owner | Done | +| --- | --------------------------------------------------------------------------- | -------------------- | ---- | +| 1 | Device returned by `[FILL IN: deadline — e.g., end of final working day]` | Departing individual | ☐ | +| 2 | Device wiped via MDM (`[FILL IN: MDM tool]`) and wipe logged | `[FILL IN: IT]` | ☐ | +| 3 | Device re-assigned or quarantined per `[FILL IN: asset-management process]` | `[FILL IN: IT]` | ☐ | + +For lost/stolen devices see [`device-policy.template.md`](./device-policy.template.md) § 5. + +--- + +## 5. Data Handover & Retention + +| # | Task | Done | +| --- | --------------------------------------------------------------------------------------------- | ---- | +| 1 | Business-critical files transferred to `[FILL IN: shared location — e.g., team drive]` | ☐ | +| 2 | Personal data on company systems assessed; deleted or anonymised per retention policy | ☐ | +| 3 | Any personal data held in personal tools / local storage destroyed: `[FILL IN: confirmation]` | ☐ | +| 4 | Email forwarding / out-of-office configured for `[FILL IN: duration]` | ☐ | + +--- + +## 6. Exit Interview & Acknowledgement + +| # | Task | Done | +| --- | ------------------------------------------------------------------------------ | ---- | +| 1 | Departing individual reminded of ongoing confidentiality obligations | ☐ | +| 2 | Signed offboarding acknowledgement obtained: `[FILL IN: form name / location]` | ☐ | +| 3 | Final payslip / equipment receipt issued | ☐ | + +--- + +## 7. Post-Departure Review (30 days) + +- Confirm no residual access exists: re-run access audit for `[FILL IN: critical systems]`. +- Review audit log for anomalous activity by the account in the 30 days before departure: `[FILL IN: query / command]`. +- If anomalies found, escalate to the incident runbook (see [`incident-runbook.template.md`](./incident-runbook.template.md)). + +--- + +## 8. Record-Keeping + +Completed offboarding checklists are stored in `[FILL IN: location — e.g., HR system / personnel file]` and retained for `[FILL IN: e.g., 7 years]` per the backup and retention policy (see [`backup-policy.template.md`](./backup-policy.template.md)). + +--- + +## 9. Review Cycle + +This checklist is reviewed `[FILL IN: frequency — e.g., annually or when systems change]`. The next scheduled review is `[FILL IN: YYYY-MM-DD]`. diff --git a/docs/compliance/templates/onboarding.template.md b/docs/compliance/templates/onboarding.template.md new file mode 100644 index 0000000..6bfb177 --- /dev/null +++ b/docs/compliance/templates/onboarding.template.md @@ -0,0 +1,79 @@ +--- +status: template +playbook-section: 60 +title: "Staff Onboarding Checklist (Data Access & Security)" +last-reviewed: "[FILL IN: YYYY-MM-DD]" +--- + +# Staff Onboarding Checklist (Data Access & Security) + +> **Template status** — fill every `[FILL IN: …]` marker before use. + +> **Not code-enforced** — this checklist documents HR and operational controls. Access provisioning, policy acknowledgement, and training completion are tracked outside the application codebase by `[FILL IN: HR system / identity provider / ticketing tool]`. The consumer is responsible for integrating this checklist into their onboarding workflow. + +--- + +## 1. Purpose & Scope + +This checklist ensures that every new employee, contractor, or third-party with access to `[FILL IN: organisation name]`'s systems completes the required security, privacy, and data-access steps before handling personal data. + +**Owner:** `[FILL IN: role — e.g., HR / People Ops + Engineering Lead]` + +--- + +## 2. Before First Day + +| # | Task | Owner | Done | +| --- | ---------------------------------------------------------------------------------------------------- | --------------------- | ---- | +| 1 | Role-based access list agreed with hiring manager | `[FILL IN: e.g., HR]` | ☐ | +| 2 | Identity-provider account created (IdP: `[FILL IN: provider name]`) | `[FILL IN: e.g., IT]` | ☐ | +| 3 | Device provisioned and MDM-enrolled (see [`device-policy.template.md`](./device-policy.template.md)) | `[FILL IN:]` | ☐ | +| 4 | NDA / data-processing agreement signed | `[FILL IN: e.g., HR]` | ☐ | +| 5 | Emergency contact and DPO contact shared with new hire | `[FILL IN: e.g., HR]` | ☐ | + +--- + +## 3. Day 1 — Security & Privacy Orientation + +| # | Task | Owner | Done | +| --- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------- | ---- | +| 1 | Complete data-protection / GDPR awareness training: `[FILL IN: course name / platform]` | New hire | ☐ | +| 2 | Read and acknowledge: Acceptable Use & Device Policy (see [`device-policy.template.md`](./device-policy.template.md)) | New hire | ☐ | +| 3 | Read and acknowledge: Password & Authentication Policy (see [`password-policy.template.md`](./password-policy.template.md)) | New hire | ☐ | +| 4 | Set up MFA on IdP account: `[FILL IN: MFA method + instructions URL]` | New hire + IT | ☐ | +| 5 | Access production systems: `[FILL IN: systems list]` granted at minimum-privilege level | `[FILL IN: e.g., IT / Lead]` | ☐ | + +--- + +## 4. First Week — System Access Provisioning + +| # | System / tool | Access level | Approver | Done | +| --- | -------------------------------------- | ------------------------------------- | ----------------------------- | ---- | +| 1 | `[FILL IN: e.g., GitHub org]` | `[FILL IN: e.g., member / write]` | `[FILL IN: engineering lead]` | ☐ | +| 2 | `[FILL IN: e.g., Payload CMS admin]` | `[FILL IN: e.g., editor / admin]` | `[FILL IN:]` | ☐ | +| 3 | `[FILL IN: e.g., cloud console]` | `[FILL IN: e.g., read-only / scoped]` | `[FILL IN:]` | ☐ | +| 4 | `[FILL IN: e.g., monitoring / Sentry]` | `[FILL IN: e.g., member]` | `[FILL IN:]` | ☐ | +| 5 | `[FILL IN: e.g., HR / payroll system]` | `[FILL IN:]` | `[FILL IN:]` | ☐ | +| 6 | `[FILL IN: any other system]` | `[FILL IN:]` | `[FILL IN:]` | ☐ | + +--- + +## 5. First 30 Days — Compliance Acknowledgement + +| # | Task | Done | +| --- | ----------------------------------------------------------------------------------------------- | ---- | +| 1 | Confirm receipt of this organisation's privacy notice (staff version) | ☐ | +| 2 | Complete any role-specific data-handling training: `[FILL IN: e.g., PCI / HIPAA if applicable]` | ☐ | +| 3 | 30-day check-in with manager on access requirements (reduce if not needed) | ☐ | + +--- + +## 6. Record-Keeping + +Completed checklists are stored in `[FILL IN: location — e.g., HR system / personnel file]` and retained for `[FILL IN: e.g., the duration of employment + 2 years]`. + +--- + +## 7. Review Cycle + +This checklist is reviewed `[FILL IN: frequency — e.g., annually or when systems change]`. The next scheduled review is `[FILL IN: YYYY-MM-DD]`. diff --git a/docs/compliance/templates/password-policy.template.md b/docs/compliance/templates/password-policy.template.md new file mode 100644 index 0000000..11ebcf3 --- /dev/null +++ b/docs/compliance/templates/password-policy.template.md @@ -0,0 +1,82 @@ +--- +status: template +playbook-section: 40 +title: "Password & Authentication Policy" +last-reviewed: "[FILL IN: YYYY-MM-DD]" +--- + +# Password & Authentication Policy + +> **Template status** — fill every `[FILL IN: …]` marker before use. + +> **Not code-enforced** — MFA enforcement, minimum password complexity, and account lockout are **explicitly deferred** in [ADR-025 § Deferred items](../../decisions/adr-025-eu-compliance-baseline.md) because they require identity-infrastructure choices (TOTP/WebAuthn/passkeys), a threat-model-specific policy, and an OTP delivery vendor that are consumer-supplied. This template documents the policy; the consumer implements the technical controls once those choices are made. + +--- + +## 1. Purpose & Scope + +This policy defines the minimum authentication standards for all accounts — human and service — that access systems operated by `[FILL IN: organisation name]`, including `[FILL IN: describe systems — e.g., the application, Payload CMS, cloud infrastructure consoles, CI/CD pipelines]`. + +**Owner:** `[FILL IN: role — e.g., Head of Engineering / CISO]` + +--- + +## 2. Password Requirements + +### 2.1 User accounts + +| Requirement | Minimum standard | Organisation value | +| ----------------------- | ------------------------------------------- | ------------------------------ | +| Minimum length | 12 characters | `[FILL IN:]` | +| Character complexity | No single-class requirement; length > rules | `[FILL IN: any additions]` | +| Breach / pwned-password | Must be checked on creation / change | `[FILL IN: tool / service]` | +| Maximum age | Not enforced unless breach detected | `[FILL IN: or "not enforced"]` | +| Reuse restriction | `[FILL IN: e.g., last 10 passwords]` | `[FILL IN:]` | + +> Reference: NIST SP 800-63B §5.1.1 — length beats complexity rules; mandatory rotation is discouraged. + +### 2.2 Service accounts & API secrets + +- All service secrets are stored in `[FILL IN: secret manager — e.g., AWS Secrets Manager / HashiCorp Vault]`. +- Secrets are rotated `[FILL IN: frequency — e.g., every 90 days or on suspected compromise]`. +- Long-lived credentials are prohibited for `[FILL IN: list systems — e.g., production database, CI/CD pipelines]`. + +--- + +## 3. Multi-Factor Authentication (MFA) + +> **Deferred per ADR-025.** The specific MFA method (TOTP, WebAuthn, SMS) and the enforcement perimeter are consumer decisions. Until those choices are made, document the target state here. + +| Account type | Required MFA method | Enforcement date / trigger | +| ------------------------------ | ---------------------------- | -------------------------- | +| Admin / privileged users | `[FILL IN: e.g., WebAuthn]` | `[FILL IN: YYYY-MM-DD]` | +| All users (application) | `[FILL IN: e.g., TOTP]` | `[FILL IN:]` | +| Service accounts | N/A — use short-lived tokens | — | +| Infrastructure / cloud console | `[FILL IN:]` | `[FILL IN:]` | + +--- + +## 4. Account Lockout & Brute-Force Protection + +> **Deferred per ADR-025.** Lockout thresholds are deferred until the authentication threat model is established. The application ships rate-limit budgets (see `rateLimit` in each feature manifest and ADR-025 § Epic C) but does not hard-lock accounts. + +| Parameter | Target value | Status | +| ------------------------------ | ----------------------------------------------- | ---------------------------- | +| Failed attempts before lockout | `[FILL IN: e.g., 10]` | `[FILL IN: deferred / live]` | +| Lockout duration | `[FILL IN: e.g., 15 minutes]` | `[FILL IN:]` | +| Admin unlock procedure | `[FILL IN: e.g., helpdesk ticket + MFA reset]` | `[FILL IN:]` | +| Notification on lockout | `[FILL IN: e.g., email to user + Sentry alert]` | `[FILL IN:]` | + +--- + +## 5. Privileged Access + +- Privileged (admin) access requires `[FILL IN: approval workflow — e.g., pair-approval in #infra-access]`. +- Privileged sessions are limited to `[FILL IN: duration — e.g., 4-hour session tokens]`. +- All privileged actions are captured by the audit channel (see [`docs/guides/audit-and-compliance.md`](../../guides/audit-and-compliance.md)). + +--- + +## 6. Review Cycle + +This policy is reviewed `[FILL IN: frequency — e.g., annually or after any authentication-related incident]`. The next scheduled review is `[FILL IN: YYYY-MM-DD]`.