Every consent decision and every rights-request step is a hash-linked record. The console verifies all of them on demand; the proof exports; the hash format is published, so an auditor can check it without us.
Section 6(10) puts the burden of proving consent on the Data Fiduciary. A flag in a database, or a vendor's word, is not proof. A chain of hashes you can recompute is.
Evidence is not a module bolted on; every other part of Nyvika writes to it.
Each consent entry hashes the person, purpose, status, notice version, language, source, channel, process, time and the previous entry.
One click recomputes every chain; a person's record page verifies theirs.
Record of processing, consent ledger, consent summary, request register, breach register, processor register, cookie register, audit log, ledger proof.
Notice coverage, consent health, requests in time, breaches reported in time, processor agreements, with published weights.
The ledger identifies people by keyed hashes. Email addresses and phone numbers live only in an encrypted vault, decrypted to act on the person's own instruction and shredded after erasure.
Identifiers are hashed with your organisation's own secret; the ledger holds no addresses.
Contact addresses and connector credentials are encrypted at rest and never logged.
Every console action, by whom, from where, when: exportable as the audit log report.
Every module writes to the same registers and the same hash-chained evidence, so nothing is re-keyed and nothing is lost between teams.
Every decision in the widget is a ledger entry with its notice version and language.
See notice & consent →Request timelines are chained the same way, so lateness and diligence are both provable.
See privacy centre & rights →The breach register report shows the 72-hour outcome of every incident.
See breach response →Export the consent ledger and the ledger-proof report, take the documented hash construction (a short note with test vectors that we share with your auditor), and recompute. If any entry had been altered, the chain breaks at that point.
It is HMAC-chained with your organisation's key. A periodically signed anchor with an asymmetric key is on the roadmap so that verification also survives a full database restore.
In Nyvika's service, in your organisation's partition, hosted in India. Everything exports as CSV or JSON whenever you want a copy outside.
Still have a question? Write to us.
In the demo we verify the ledger in front of you, export the proof and recompute one hash by hand.