Access
Art. 15- Only with the right permissionBuiltexports are permission-checked and audited
- Signed exportBuiltintegrity an external party can check
- export_user_dataBuiltone call, full subject bundle
Someone asks for their data. Now what?
Every request produces a piece of evidence you can have checked.
This page describes product capabilities. It is not legal advice, and using Provenize does not by itself make an organisation compliant.
In plain words
The GDPR is the European privacy law. It gives people the right to see what data you hold about them, to correct it, and to have it erased.
Provenize helps you carry out such a request and show afterwards that you did. It is a tool, not a guarantee that your organisation is compliant.
A request, step by step
Data rights, and the proof you honoured them.
Your browser has no speech synthesis. The explanation is written out below.
Answer the request. Keep the proof.
Rights, mapped
Each capability mapped to the principle it serves.
Consent
Art. 7- People as a code, not a nameBuiltnever a real name in the consent register
- record_consentBuiltconsents are only added, never overwritten
- Every consent change is an audit eventBuilt
Erasure
Art. 17- erase_userBuilterasure via per-subject key deletion: delete the key, content becomes permanently unreadable, the audit chain stays mathematically verifiable
- Immediate on requestBuilta legal request does not wait for a recycle-bin period
- Erase single items about a personBuiltitems about a person, not just by them
- Signed proof of erasureBuilta piece of evidence for the person themselves
- Finish erasing whole documentsPlanned
Restriction & objection
Art. 21- Retention-hold roleBuiltcontrolled read carve-out for legal obligations
- Left out of search resultsBuilta paused subject is excluded from search
- set_processing_pausedBuiltrestriction stored and audited
Records of processing
Art. 30- generate_ropaBuiltthe register comes from the system itself, not a spreadsheet
- Richer purposes & categories · PDF exportPlanned
Storage limitation
Art. 5(1)(e)- Clear old log entries without breaking the chainBuiltclearing up without breaking the chain
- A retention period per type of dataBuiltplus automatic clearing up
- Retention finished everywherePlanned
Minimisation & privacy by design
Art. 5 / 25- Removing personal detailsBuiltbefore any external model call — best-effort, disclosed
- Only the quoted snippetsBuiltan external model sees loose fragments, never your files
- Test for leaks yourselfBuiltcustomers can run it themselves
- Everything on your own computerBuiltyour files never leave your computer
Security of processing
Art. 32- Continuous security checksBuiltSAST, secrets, CVE scanning
- A log where tampering showsBuiltplus a check you can run yourself
- Rights per roleBuiltplus access enforced in the database
- Signed check number over the whole chainBuiltof the whole chain
- Encrypted local storagePlanned
Replacing names with codes
Pseudonymised by default. Erasable by key deletion.
- A separate key per personBuiltin the log entries
- Erasing means throwing away the keyBuiltchain intact
Evidence instead of promises
Every right comes with proof an auditor can check.
- Signed evidence filesBuiltexports, erasure receipts, conflict resolutions
- Every rights action is an audit event on the chainBuilt
- Proof from leak testsBuiltactively looking for leaked personal details
- Recheck it yourself (verify())Builtanyone holding the data can recheck the history
What it does not do
What this does not do — said out loud.
- Compliance document set (DPA, TOMs) is Planned — drafted with counsel
- Removing personal details is best effort, not perfect — we publish the known gaps
- Software supports compliance; compliance itself is organisational
- At-rest disk encryption is Planned, not built
Want your DPO to poke holes in this?
Become a design partnerThis page describes product capabilities. It is not legal advice, and using Provenize does not by itself make an organisation compliant.