Control map · Regulation (EU) 2016/679
GDPR
Code evidence for the processing principles, data protection by design and security of processing.
Code evidence
3articles checked on every pull requestLive (process)
0none mappedPlanned
0can be evidenced from code or GitHub; not built yetOrganisation-level articles
Policies, people, vendors, physical security and the like, listed below.Toevan gives supporting evidence for 1 of these.Managed by your organisation’s workflowsSome of the GDPR lives in code: where personal data flows, how it is scoped and how it is protected.
The GDPR blueprint gives code evidence for Articles 5, 25 and 32 on every pull request, with supporting evidence for erasure. Lawful basis, records of processing and data subject rights stay with your privacy programme.
Toevan gives evidence for controls; it never certifies them or claims a framework is covered. Whether the evidence is sufficient is your auditor’s judgement.
Code evidence3
Sealed on every pull request. Always partial: the control also asks for things outside code. Rules in the GDPR blueprint check part of each on every pull request.
Art.5Principles relating to processing of personal dataCore PrinciplesArt.25Data protection by design and by defaultDesign RequirementsArt.32Security of processingSecurity
Supporting1
Toevan records related evidence, but the duty is organisational, so it never counts as covered.
Art.17Right to erasure (‘right to be forgotten’)Data Subject RightsSupporting evidence: a rule records evidence related to this duty. The duty itself is an operational process.
Organisation-level articles
Organisation-level controls (policies, people, vendors, physical security and the like) stay with your organisation’s own process; Toevan does not cover them.
Show the list
Core Principles
Data Subject Rights
Controller and Processor
Incident Response
Risk Assessment
International Transfers
Using it in an audit
- Read the code evidence for the period
Each pull request carries sealed code results against the blueprint’s rules, pinned to the commit and the rule-set version in force.
- Test a sample
For each sampled record, check its results, then verify it offline against the published key with openssl and the shell: get the evidence, confirm the key, check the record. To replay the whole chain, Toevan provides the toevan command on request; it is not yet public.
- Recomputed
- Toevan computed it from the code or git history itself.
- Reported + sealed
- GitHub reported it; Toevan captured it at the event and signed it.
- Declared + sealed
- The organisation declared it, such as a change to what is checked; Toevan signed the declaration and its history.
- Toevan record, not sealed
- Held in Toevan’s database but not sealed in the ledger, such as a waiver today. Nothing protects it by a signature.
- Consumed
- Taken from GitHub’s deployment and release records and linked by commit or digest.
- Not captured
- No reliable source was available. Toevan does not infer it.
Test the mapping on a real audit.
Bring one repository and an upcoming audit. We’ll set up the blueprint and walk your auditor through verification.
- One repository, one framework
- Evidence from the first pull request
- Verifiable without a Toevan account