fraqtal/agentic-dev
Template
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
fraqtal
2026-07-12 08:15:46 +00:00
commit ee0fec0691
1397 changed files with 127242 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

78
docs/compliance/templates/backup-policy.template.md Normal file
View File

@@ -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]`.

86
docs/compliance/templates/device-policy.template.md Normal file
View File

@@ -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]`.

312
docs/compliance/templates/dsr-procedure.template.md Normal file
View File

@@ -0,0 +1,312 @@
---
status: template
playbook-section: 10
title: "Data Subject Rights (DSR) Fulfilment Procedure"
gdpr-articles: [Art. 15, Art. 16, Art. 17, Art. 18, Art. 20]
last-reviewed: "[FILL IN: YYYY-MM-DD]"
---
# Data Subject Rights (DSR) Fulfilment Procedure
> **Template status** — fill every `[FILL IN: …]` marker before use.
> Cross-references below point to shipped interfaces, endpoints, and ADRs; do not change them.
---
## 1. Purpose & Scope
This procedure governs how `[FILL IN: organisation name]` receives, validates, fulfils, and records requests from data subjects exercising rights under GDPR Articles 15–20.
**Covered rights:**
| GDPR Article | Right | Shipped interface |
| ------------ | --------------------------------- | ----------------------------------------- |
| Art. 15 + 20 | Access + Portability | `IDataExport` (`dsr.export`) |
| Art. 16 | Rectification | `IDataRectify` (`dsr.rectify`) |
| Art. 17 | Erasure ("right to be forgotten") | `IDataDelete` (`dsr.delete`) |
| Art. 18 | Restriction of processing | `IProcessingRestriction` (`dsr.restrict`) |
See [`docs/guides/dsr.md`](../../guides/dsr.md) for the engineering cookbook and [`docs/decisions/adr-025-eu-compliance-baseline.md`](../../decisions/adr-025-eu-compliance-baseline.md) § Epic B for the design rationale.
---
## 2. Roles & Contacts
| Role | Name | Contact |
| -------------------------------- | ------------------------------ | ------------------ |
| Data Protection Officer | [FILL IN: name / DPO provider] | [FILL IN: contact] |
| DSR Coordinator | [FILL IN: name] | [FILL IN: contact] |
| Engineering contact (fulfilment) | [FILL IN: name] | [FILL IN: contact] |
**Intake channel:** `[FILL IN: e.g. privacy@example.com / online form URL]`
---
## 3. Statutory Deadlines
| Stage | Deadline | Extension |
| ------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| Acknowledge receipt | `[FILL IN: e.g. 5 business days]` | — |
| Fulfil or refuse | **1 calendar month** from receipt (GDPR Art. 12(3)) | Up to 2 further months for complex/numerous requests; notify subject within the first month |
| Notify subject of refusal | 1 month | — |
Deadline clock starts when the organisation receives the request — not when identity is verified.
---
## 4. Phase 1 — Receipt & Intake
### 4.1 Intake channels
Accept DSR requests via:
- `[FILL IN: primary channel, e.g. privacy form at https://example.com/privacy/request]`
- `[FILL IN: secondary channel, e.g. email to privacy@example.com]`
- Any written format (GDPR does not mandate a specific form)
### 4.2 Logging the request
Log each incoming request immediately in `[FILL IN: DSR register / issue tracker]` with:
| Field | Value |
| --------------- | --------------------------- |
| Reference ID | `DSR-YYYY-NNN` (sequential) |
| Right requested | Art. 15 / 16 / 17 / 18 / 20 |
| Channel | email / form / letter |
| Received at | ISO 8601 timestamp |
| Deadline | received + 1 month |
| Status | `pending-verification` |
### 4.3 Acknowledgement
Send acknowledgement to the requester within `[FILL IN: e.g. 5 business days]` confirming:
- Receipt of the request
- Reference ID
- Identity verification requirement (§ 5)
- Statutory deadline
Template: `[FILL IN: path to acknowledgement email template]`
---
## 5. Phase 2 — Identity Validation
### 5.1 Verification requirement
GDPR Art. 12(6) permits identity verification when there is reasonable doubt. Always verify for Art. 17 (erasure) and Art. 18 (restriction). For Art. 15 (access) of clearly authenticated users, verification may be satisfied by existing session.
### 5.2 Verification methods
| Method | Acceptable for |
| ---------------------------------------------- | ---------------------------------- |
| Authenticated session in the app | Art. 15, Art. 16 (low-risk fields) |
| Email confirmation to registered address | All rights |
| `[FILL IN: government ID / identity provider]` | Art. 17 cascade-hard, Art. 18 |
### 5.3 Rejected or suspicious requests
If identity cannot be verified after `[FILL IN: e.g. 14 days]`:
1. Close the request with status `identity-unverified`.
2. Notify the requester in writing of the outcome.
3. Log closure in the DSR register.
---
## 6. Phase 3 — Fulfilment
### 6.1 Identify the subject record
Map the verified identity to the system `subjectId` (Payload `users.id` or equivalent auth collection primary key). Cross-reference `compliance/data-map.yml` (generated by `pnpm compliance:data-map`) to enumerate which collections hold personal data for this subject.
```bash
# Regenerate data map to ensure it reflects current schema
pnpm compliance:data-map
```
Review `compliance/data-map.yml` fields tagged `exportable: true` (Art. 15/20) and `restrictable: true` (Art. 18).
### 6.2 Art. 15 + 20 — Access and Portability
**Interface:** `IDataExport.exportSubjectData(subjectId, format)`
**tRPC procedure:** `dsr.export` (query — no mutation)
**GDPR deadline:** respond within 1 month; provide data without charge for first copy.
Invoke via the admin tRPC client or the REST endpoint wired in `apps/web-next`:
```
GET /api/gdpr/export?subjectId=<id>&format=json
GET /api/gdpr/export?subjectId=<id>&format=json-ld # machine-readable JSON-LD
```
The response is a `UserDataBundle`:
- `data` — keyed by Payload collection slug; each bucket contains `asSelf` (rows the subject owns) and `asReference` (rows merely referencing the subject)
- `auditLog` — the subject's audit trail (optional; include for transparency)
- `exportedAt` — ISO 8601 export timestamp for the certificate of fulfilment
**Audit entry emitted:** `EXPORT` action, `resource.type: "data-subject"`, `resource.id: subjectId`.
Deliver the export to the subject via `[FILL IN: secure delivery method, e.g. encrypted download link / secure email]`.
### 6.3 Art. 16 — Rectification
**Interface:** `IDataRectify.updateSubjectField(subjectId, collection, field, value)`
**tRPC procedure:** `dsr.rectify` (mutation)
**Scope:** only fields tagged `custom.pii` in the Payload collection config (i.e. fields indexed in `compliance/data-map.yml`).
```
POST /api/gdpr/rectify
Body: { subjectId, collection, field, value }
```
Steps:
1. Confirm the field is `custom.pii`-tagged in `compliance/data-map.yml`.
2. Confirm the new value passes Payload field validation.
3. Invoke the procedure; the implementation emits a `RESTRICT` audit entry with `reason: "art-16-request"`.
4. Notify the subject that rectification is complete and, if data was shared with third parties, notify them per Art. 19.
Third-party notification log: `[FILL IN: log location]`
### 6.4 Art. 17 — Erasure
**Interface:** `IDataDelete.deleteSubjectData(subjectId, mode)`
**tRPC procedure:** `dsr.delete` (mutation — requires authenticated admin session for `cascade-hard`)
**Returned:** `DeletionCertificate` — retain this as evidence of fulfilment.
**Mode selection:**
| Mode | Effect | Who can invoke |
| ---------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------- |
| `"soft"` | Redacts PII fields in owned rows; NULLs reference fields; row structure preserved | Standard authenticated user or DSR coordinator |
| `"cascade-hard"` | Hard-deletes owned rows where `postDeletion.action === "hard-delete"` per retention policy; NULLs reference fields | Admin role required |
```
POST /api/gdpr/delete
Body: { subjectId, mode: "soft" | "cascade-hard" }
```
**Exemptions** (GDPR Art. 17(3)) — erasure must be refused if data is required for:
- Legal obligation compliance (document refusal in the DSR register)
- Establishment, exercise, or defence of legal claims
**Audit trail pseudonymization:** after deletion, invoke `IAuditLog.eraseSubject(actorId, "pseudonymize")` via the admin tRPC to replace the subject identifier in the audit log with `erased-{hash[0:16]}` (sha256-salted pseudonym per ADR-018). This preserves the event record for regulatory purposes while removing the identifier.
**Retention-policy overrides:** check `compliance/retention-policy.yml` for `postDeletion` rules — some collections may have a grace period (`postDeletion.duration: P30D`) before hard deletion executes.
```bash
# View current retention policy
cat compliance/retention-policy.yml
# Regenerate from Payload field tags
pnpm compliance:retention-policy
```
**DeletionCertificate fields to retain:**
- `subjectId` (or pseudonymized form)
- `mode`, `timestamp`, `reason: "art-17-request"`
- `affected[]` — collections and rows modified
- `auditEntryId` — links to the audit log
### 6.5 Art. 18 — Restriction of Processing
**Interface:** `IProcessingRestriction.setRestriction(subjectId, granted: true)`
**tRPC procedure:** `dsr.restrict` (mutation)
```
POST /api/gdpr/restrict
Body: { subjectId, granted: true }
```
The implementation sets `processingRestrictedAt` on the user record. Downstream use cases check `isRestricted(subjectId)` before processing personal data. The audit channel records a `RESTRICT` audit entry on every state change.
**Grounds for restriction (Art. 18(1)):**
- Accuracy of data is contested (pending Art. 16 rectification)
- Processing is unlawful but erasure is opposed by the subject
- Organisation no longer needs the data but subject requires it for legal claims
- Subject has objected (pending verification of legitimate grounds)
Notify the subject when restriction is lifted: invoke `dsr.restrict` with `granted: false` and send written notice per Art. 18(3).
**Audit entry emitted:** `RESTRICT` (on restriction) / `UNRESTRICT` (on lift).
---
## 7. Phase 4 — Recording & Closure
### 7.1 DSR register update
Update the DSR register entry (§ 4.2) with:
| Field | Value |
| -------------- | ------------------------------------------------- |
| Fulfilled at | ISO 8601 timestamp |
| Outcome | `fulfilled` / `refused` / `partially-fulfilled` |
| Evidence | DeletionCertificate ID or export reference |
| Audit entry ID | From `AuditEntry.correlationId` or `auditEntryId` |
| Status | `closed` |
### 7.2 Subject notification
Notify the data subject of the outcome within the Art. 12(3) deadline:
- Fulfilment: summary of actions taken, delivery method for exports.
- Refusal: grounds for refusal (Art. 12(4)), right to lodge complaint with SA, right to seek judicial remedy.
Template: `[FILL IN: path to outcome notification template]`
### 7.3 Third-party notification log (Art. 19)
If the corrected, erased, or restricted data was previously shared with third parties (sub-processors listed in `compliance/sub-processors.yml`), notify each processor of the subject's request. Record each notification in `[FILL IN: third-party notification log]`.
---
## 8. Consent-Related DSR Interactions
Consent grant and withdrawal are distinct from Art. 17 erasure but often accompany DSR requests. The consent channel ([`docs/guides/consent.md`](../../guides/consent.md)) records:
| Audit action | Trigger |
| ------------------ | -------------------------------------------------------- |
| `CONSENT_GRANT` | Subject grants consent for a category (e.g. `marketing`) |
| `CONSENT_WITHDRAW` | Subject withdraws consent |
| `RESTRICT` | Art. 18 restriction set |
| `UNRESTRICT` | Art. 18 restriction lifted |
If a DSR request also includes consent withdrawal, invoke `IConsent.withdraw(subjectId, categories)` in addition to the relevant DSR procedure. Consent withdrawal does not automatically trigger erasure — only an explicit Art. 17 request does.
---
## 9. Appendix — Command Reference
```bash
# Regenerate PII data map (enumerate affected collections and fields)
pnpm compliance:data-map
# Regenerate retention policy (check postDeletion rules before Art. 17)
pnpm compliance:retention-policy
# Regenerate sub-processor list (for Art. 19 third-party notification)
pnpm compliance:sub-processors
# Regenerate all compliance artifacts in one pass
pnpm compliance:emit-all
# Run fallow audit before closing a DSR-related PR
pnpm fallow:audit
```
---
## 10. Document Control
| Field | Value |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Owner | [FILL IN: DPO or DSR Coordinator] |
| Review cycle | [FILL IN: e.g. annual or on schema change] |
| Next review date | [FILL IN: YYYY-MM-DD] |
| Cross-references | [`docs/decisions/adr-025-eu-compliance-baseline.md`](../../decisions/adr-025-eu-compliance-baseline.md), [`docs/decisions/adr-018-audit-and-compliance.md`](../../decisions/adr-018-audit-and-compliance.md), [`docs/guides/dsr.md`](../../guides/dsr.md), [`docs/guides/audit-and-compliance.md`](../../guides/audit-and-compliance.md), [`docs/guides/consent.md`](../../guides/consent.md), [`../data-map.example.yml`](../data-map.example.yml) |

264
docs/compliance/templates/incident-runbook.template.md Normal file
View File

@@ -0,0 +1,264 @@
---
status: template
playbook-section: 20
title: "Security Incident & Personal Data Breach Runbook"
gdpr-articles: [Art. 33, Art. 34]
last-reviewed: "[FILL IN: YYYY-MM-DD]"
---
# Security Incident & Personal Data Breach Runbook
> **Template status** — fill every `[FILL IN: …]` marker before use.
> Cross-references below point to shipped code and ADRs; do not change them.
---
## 1. Purpose & Scope
This runbook governs the detection, triage, containment, notification, and post-mortem of security incidents and personal data breaches affecting `[FILL IN: product / organisation name]`.
**In scope:** any event that may have compromised the confidentiality, integrity, or availability of personal data processed by this system, including unauthorized access, exfiltration, accidental exposure, and ransomware.
**Out of scope:** non-PII service disruptions (handle via standard on-call runbook). Escalate to this runbook when PII impact cannot be ruled out.
---
## 2. Severity Classification
| Level | Definition | Example |
| ----------------- | ------------------------------------------------- | ---------------------------------------------------- |
| **P0 — Critical** | Confirmed exfiltration or mass exposure of PII | Database dump on public host |
| **P1 — High** | Suspected breach; blast radius unknown | Anomalous `EXPORT` audit entries for non-admin actor |
| **P2 — Medium** | Contained misconfiguration; no confirmed PII leak | Stale presigned URL exposed to wrong tenant |
| **P3 — Low** | Near-miss; no PII accessed | Failed injection attempt blocked by rate-limit |
---
## 3. Roles & Contacts
| Role | Name | Contact |
| ----------------------- | ------------------------------ | ------------------ |
| Incident Commander | [FILL IN: name] | [FILL IN: contact] |
| Data Protection Officer | [FILL IN: name / DPO provider] | [FILL IN: contact] |
| Legal / Counsel | [FILL IN: name] | [FILL IN: contact] |
| Engineering Lead | [FILL IN: name] | [FILL IN: contact] |
| Communications Lead | [FILL IN: name] | [FILL IN: contact] |
**Supervisory Authority (SA):**
- Authority name: `[FILL IN: e.g. ICO / CNIL / BfDI]`
- Online notification portal: `[FILL IN: URL]`
- Emergency phone: `[FILL IN: number]`
---
## 4. Phase 1 — Detection
### 4.1 Automated signals
This template ships two automated detection surfaces. Check both when an alert fires.
#### Sentry error alerting (ADR-014)
Every unhandled exception in `apps/web-next`, `apps/cms`, and `apps/web-tanstack` is captured via `ILogger.captureException` and routed to Sentry ([`docs/decisions/adr-014-instrumentation-sentry.md`](../../decisions/adr-014-instrumentation-sentry.md)). Configure alert rules in Sentry for:
- Spike in `4xx` / `5xx` on auth or DSR routes
- New issue fingerprints in production environment
- Volume anomaly on `[FILL IN: Sentry project slug]`
**Verify DSNs are configured:**
```bash
# Each app has its own Sentry project
echo $WEB_NEXT_SENTRY_DSN
echo $CMS_SENTRY_DSN
echo $WEB_TANSTACK_SENTRY_DSN # if TanStack Start app is in use
```
All three must be non-empty in production. A missing DSN silently disables capture for that app.
#### Audit log anomalies (ADR-018)
The audit channel ([`docs/decisions/adr-018-audit-and-compliance.md`](../../decisions/adr-018-audit-and-compliance.md)) records every `AuditAction` emitted by feature use cases via `AuditLogProtocol.record()`. Actions relevant to breach detection:
| `AuditAction` | Breach signal |
| ------------------- | ----------------------------------------------------- |
| `EXPORT` | Mass export by non-admin actor or from unexpected IP |
| `VIEW` | High-frequency reads on a single `actorId` |
| `PERMISSION_CHANGE` | Privilege escalation outside change-management window |
| `DELETE` | Bulk delete with no corresponding DSR request |
Query the Payload audit logs collection or the aggregated cold archive (`[FILL IN: log aggregation URL, e.g. Vector / Fluent Bit sink]`) for anomalies. Correlate with OTel `correlationId` (trace ID auto-populated by `TraceIdEnrichingAuditLog`).
#### Rate-limit exhaustion (ADR-025 § Epic C)
The rate-limit primitive (`IRateLimit` in `core-shared/rate-limit`, see [`docs/guides/rate-limiting.md`](../../guides/rate-limiting.md)) emits `{ allowed: false, remaining: 0, resetAt }` when a budget is exhausted. Repeated exhaustion on auth or DSR endpoints may indicate credential-stuffing or automated exfiltration.
Check budget tables declared in feature manifests (`rateLimit: { window, budget }`) against observed traffic in `[FILL IN: metrics dashboard URL]`.
#### Security header violations
HSTS, `X-Frame-Options`, and CSP headers are emitted by the security-headers middleware ([`docs/guides/security-headers.md`](../../guides/security-headers.md)). CSP violation reports (if `report-uri` is configured) surface attempted XSS. Check `[FILL IN: CSP report endpoint / dashboard]`.
### 4.2 Manual discovery
If detection was by human observation (e.g., responsible-disclosure report, darknet alert):
1. Log the reporter's contact and discovery timestamp.
2. Do not confirm or deny breach details to the reporter until DPO is engaged.
3. Proceed to Phase 2.
---
## 5. Phase 2 — Triage
**Target time: within [FILL IN: e.g. 2 hours] of detection.**
### 5.1 Triage checklist
- [ ] Page Incident Commander and DPO.
- [ ] Open incident channel: `[FILL IN: e.g. #incident-YYYYMMDD in Slack / Teams]`.
- [ ] Document initial facts: detected at, detected by, affected system(s).
- [ ] Classify severity (§ 2).
- [ ] Determine if personal data is involved (see § 5.2).
- [ ] Initiate 72-hour DPA notification clock if P0 or P1 (§ 7.1).
### 5.2 PII impact assessment
Use the generated data map (`compliance/data-map.yml`, generated by `pnpm compliance:data-map` from Payload `custom.pii` field tags) to enumerate which collections and fields may be affected. Cross-reference with the scope of the incident (endpoint, DB table, S3 bucket, etc.).
Key questions:
- Which `piiCategory` values are in the affected scope? (e.g. `contact-email`, `identification-name`)
- Are any `restrictable: true` subjects affected (i.e. users who invoked Art. 18)?
- Was the `auditLogs` collection itself compromised? (Audit trail integrity is required for Art. 33 notification.)
---
## 6. Phase 3 — Containment
**Target time: within [FILL IN: e.g. 4 hours] of confirmation for P0/P1.**
### 6.1 Immediate actions
- [ ] Revoke or rotate compromised credentials (`[FILL IN: credential management system]`).
- [ ] Block actor at network/WAF level if attack is ongoing (`[FILL IN: WAF / CDN control panel URL]`).
- [ ] If a specific `actorId` is confirmed malicious: suspend account in Payload admin (`apps/cms`, port 3001).
- [ ] If a tRPC or REST route is the attack vector: deploy an emergency rate-limit tightening or disable the route (`[FILL IN: deployment method]`).
- [ ] Preserve evidence: take read-only snapshots of affected tables, CloudWatch / log streams, and network flow logs before any cleanup.
### 6.2 Audit trail preservation
The audit log collection is append-only (`update: () => false` Payload access rule per ADR-018). Do not attempt to delete or modify audit entries. If the audit collection itself is a target, freeze DB-level access and take a snapshot:
```bash
# [FILL IN: adapt to your database provider]
pg_dump --schema-only --table=audit_logs $DATABASE_URL > audit_logs_schema_snapshot.sql
pg_dump --data-only --table=audit_logs $DATABASE_URL > audit_logs_data_snapshot.sql
```
---
## 7. Phase 4 — Notification
### 7.1 Regulatory notification deadlines
| Obligation | Deadline | Trigger |
| -------------------------------------------- | -------------------------------- | -------------------------------------------------------------------------- |
| GDPR Art. 33 — notify Supervisory Authority | **72 hours** from becoming aware | Any breach involving personal data unless unlikely to risk rights/freedoms |
| `[FILL IN: national DPA requirement]` | **[FILL IN: e.g. 24 hours]** | `[FILL IN: condition]` |
| GDPR Art. 34 — notify affected data subjects | Without undue delay | High risk to rights and freedoms |
**Clock start:** the moment the organisation "becomes aware" — typically when the Incident Commander or DPO confirms the incident in § 5.1, not when it was first detected.
### 7.2 Supervisory Authority notification (Art. 33)
Prepare the notification using the SA's online portal (`[FILL IN: URL]`). Required fields per Art. 33(3):
- Nature of the breach (categories and approximate number of records / data subjects)
- Name and contact details of DPO: `[FILL IN: DPO name, email, phone]`
- Likely consequences of the breach
- Measures taken or proposed
Attach:
- Incident timeline (from detection to containment)
- Affected `piiCategories` from `compliance/data-map.yml`
- Audit log extract covering the incident window (redact unrelated subjects)
**If full facts are not available within 72 hours:** submit an initial notification marked "partial" and follow up without delay. GDPR Art. 33(4) explicitly permits phased notification.
### 7.3 Data subject notification (Art. 34)
Threshold: notification is required when the breach is likely to result in **high risk** to the rights and freedoms of individuals (e.g. identity theft, financial loss, discrimination).
- Drafting: `[FILL IN: communications lead]` drafts notice in plain language.
- Channel: `[FILL IN: e.g. in-app banner + email via transactional provider]`
- Content: nature of breach, DPO contact, likely consequences, mitigation steps.
- Timing: `[FILL IN: target send window, e.g. within 48 hours of Art. 33 notification]`
### 7.4 Internal stakeholder notification
| Stakeholder | When | Channel |
| ----------------------- | ---------------------------- | ----------- |
| Executive team | P0/P1: immediately | `[FILL IN]` |
| Customer success | Before customer-facing comms | `[FILL IN]` |
| Board / audit committee | Within `[FILL IN]` hours | `[FILL IN]` |
---
## 8. Phase 5 — Post-mortem
**Target: within [FILL IN: e.g. 5 business days] of containment.**
### 8.1 Post-mortem checklist
- [ ] Timeline reconstruction (detection → triage → containment → notification).
- [ ] Root cause analysis (five-whys or equivalent).
- [ ] Blast radius: confirmed data subjects affected, `piiCategories` exposed, duration of exposure.
- [ ] Audit log review: were anomalous `AuditAction` entries present before detection? Were `from.ipTruncated` values suspicious?
- [ ] Control gaps identified.
- [ ] Remediation actions with owner and deadline.
- [ ] Lessons learned.
### 8.2 Remediation tracking
Document each action in `[FILL IN: issue tracker, e.g. Linear / GitHub Issues]` with:
- Linked ADR or guide (e.g. ADR-018, ADR-014)
- Owner
- Target date
- Verification step (e.g. `pnpm fallow:audit` green, new test added)
### 8.3 Mandatory follow-up with Supervisory Authority
If the Art. 33 notification was submitted as "partial", file the complete notification with the SA by `[FILL IN: agreed follow-up date]`.
---
## 9. Appendix — Command Reference
```bash
# Inspect running apps and their Sentry DSN status
echo $WEB_NEXT_SENTRY_DSN && echo $CMS_SENTRY_DSN
# Run fallow audit to surface dead exports / drift before post-mortem PR
pnpm fallow:audit
# Regenerate data map to confirm affected PII fields
pnpm compliance:data-map
# Re-emit all compliance artifacts (data-map + retention-policy + sub-processors)
pnpm compliance:emit-all
```
---
## 10. Document Control
| Field | Value |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Owner | [FILL IN: DPO or Engineering Lead] |
| Review cycle | [FILL IN: e.g. annual or after every P0/P1] |
| Next review date | [FILL IN: YYYY-MM-DD] |
| Cross-references | [`docs/decisions/adr-018-audit-and-compliance.md`](../../decisions/adr-018-audit-and-compliance.md), [`docs/decisions/adr-014-instrumentation-sentry.md`](../../decisions/adr-014-instrumentation-sentry.md), [`docs/decisions/adr-025-eu-compliance-baseline.md`](../../decisions/adr-025-eu-compliance-baseline.md), [`docs/guides/audit-and-compliance.md`](../../guides/audit-and-compliance.md), [`docs/guides/rate-limiting.md`](../../guides/rate-limiting.md), [`docs/guides/security-headers.md`](../../guides/security-headers.md) |

103
docs/compliance/templates/offboarding.template.md Normal file
View File

@@ -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]`.

79
docs/compliance/templates/onboarding.template.md Normal file
View File

@@ -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]`.

82
docs/compliance/templates/password-policy.template.md Normal file
View File

@@ -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]`.