Swipe to see all columns →
| Clause | Requirement | Runback capability | Evidence |
|---|---|---|---|
| Article 5(1)(c) | Personal data shall be adequate, relevant, and limited to what is necessary in relation to the purposes for which it is processed (data minimisation). | In-process PII redaction before anything is sent | A run where PII was redacted before capture See it in the dashboard → |
| Article 5(1)(e) | Personal data shall be kept in a form which permits identification for no longer than is necessary (storage limitation). | Plan-enforced retention window with automated pruning | Your configured data-retention window See it in the dashboard → |
| Article 30 | Maintain a record of processing activities under its responsibility. | Immutable, hash-chained run ledger | An entry in the hash-chained, append-only ledger See it in the dashboard → |
| Article 32 | Implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. | SSO + policy engine + signed audit trail | A captured run in the audit trace See it in the dashboard → |
Honest limits
What this page does not claim.
- GDPR has dozens of articles beyond the four mapped below (lawful basis, DSAR handling, cross-border transfer mechanisms, breach notification timing). Those are organisational and legal obligations Runback does not touch.
- Redaction reduces what personal data reaches Runback's storage; it does not by itself establish a lawful basis for processing it in the first place.
- This is a capability map, not a conformity determination. Whether your deployment satisfies GDPR is a determination for your own assessor — what's listed above is the evidence that argument draws on.