# Data Protection Impact Assessment (DPIA) template · Wave 8 · C7 · 2026-07-13

_This template is invoked whenever a NEW data flow is introduced,
an EXISTING flow substantially changes, or an incident reveals a
gap that needs a re-assessment. Complete a copy per flow in
`docs/dpia/DPIA-{flow-name}-{YYYY-MM-DD}.md`._

## Flow summary

| Field                                     | Value                                                    |
| ----------------------------------------- | -------------------------------------------------------- |
| Flow name                                 |                                                          |
| Owner (product / eng lead)                |                                                          |
| Date of assessment                        |                                                          |
| Trigger (new flow / change / incident)    |                                                          |
| DPIA reviewer                             | DPO name                                                 |
| Reviewer sign-off date                    |                                                          |
| Gov ledger seq of sign-off                | (populated after `kind=DPIA_SIGNED` write)              |

## 1 · Necessity + proportionality

- **Business purpose**: why does this flow exist? What decision
  does the data enable?
- **Alternatives considered**: is there a less-invasive flow that
  achieves the same purpose?
- **Data minimisation**: are we collecting the minimum necessary?
- **Retention**: what is the shortest retention that still
  serves the purpose?

## 2 · Data inventory

| Category           | Field(s) | Legal basis          | Classification tier      | Retention |
| ------------------ | -------- | -------------------- | ------------------------ | --------- |
| Identifier         |          |                      |                          |           |
| Transaction meta   |          |                      |                          |           |
| Behavioural        |          |                      |                          |           |
| Sensitive (Art. 9) |          |                      |                          |           |
| Other              |          |                      |                          |           |

## 3 · Data flow diagram

Sketch the flow from source → KOKON storage → downstream. Mark
crossings of the trust boundary (e.g. KOKON→ARIN gateway, KOKON→
regulator). Attach the diagram or embed a Mermaid diagram inline.

## 4 · Risks + mitigations

For each risk, score likelihood + impact on a 1-5 scale.

| Risk                                          | L | I | Score | Mitigation                                                                 |
| --------------------------------------------- | - | - | ----- | -------------------------------------------------------------------------- |
| Unauthorised access                           |   |   |       | signed user context + PBAC; classification enforcement on reads            |
| Data breach in transit                        |   |   |       | TLS 1.2+, HSTS, no fallback                                                |
| Data breach at rest                           |   |   |       | AES-256-GCM app-layer encryption (Wave 8 · C1)                             |
| Silent data drift / audit tampering           |   |   |       | Hash-chained gov ledger + tamper verifier                                  |
| Over-retention                                |   |   |       | Retention worker (Wave 8 · C3) purges per class                            |
| Subject cannot exercise rights                |   |   |       | DSR endpoints (Wave 8 · C4) + `/ui/privacy` operator page                  |
| Third-party sub-processor breach              |   |   |       | Sub-processor list in `docs/PRIVACY-NOTICE.md`; contractual SCC in place    |
| Cross-border transfer non-compliance          |   |   |       | Standard contractual clauses for US leg; EU-only for KOKON substrate       |
| MFA missing for operators                     |   |   |       | Wave 8 · C5 gauge; policy target ≥ 95% coverage                            |
| Automated decision harm                       |   |   |       | Human-in-the-loop closure required (Wave 6)                                |

Additional flow-specific risks:

| Risk | L | I | Score | Mitigation |
|------|---|---|-------|------------|
|      |   |   |       |            |

## 5 · Consultation

- [ ] DPO consulted
- [ ] Legal consulted
- [ ] Engineering / security consulted
- [ ] Data subjects consulted (or explicit reason why not)
- [ ] Regulator pre-notified where required

## 6 · Residual risk assessment

Post-mitigation: are the residual risks acceptable? If not, what
additional controls are needed? A DPIA that concludes "residual
risk high" must NOT ship the flow without the additional controls
listed below.

Residual risk level: LOW · MEDIUM · HIGH

Additional controls required:
- [ ]
- [ ]

## 7 · Sign-off

| Role                   | Name | Signature / e-signature | Date |
| ---------------------- | ---- | ----------------------- | ---- |
| Flow owner             |      |                         |      |
| DPO                    |      |                         |      |
| Security lead          |      |                         |      |
| Engineering lead       |      |                         |      |

## 8 · Record on-chain

Once signed, record on the gov ledger:

```
POST /api/control/audit/gov-ledger
X-KOKON-OPS-TOKEN: ****
{
  "kind":       "DPIA_SIGNED",
  "actor":      "<DPO name>",
  "external_ref": "DPIA-<flow-name>-<YYYY-MM-DD>",
  "outcome":    "PASS",
  "classification": "RESTRICTED_INTERNAL",
  "payload":    "{\"residual_risk\":\"LOW\",\"additional_controls\":[]}"
}
```

Save the returned `seq` into "Gov ledger seq of sign-off" at the
top of this file.

## 9 · Review cadence

DPIAs are re-visited:

- Every 12 months (mandatory refresh)
- After any material change to the flow
- After any incident touching the flow (S1 or S2)
- On request of the DPO or a regulator
