Trust, by construction.
A compliance platform earns trust by being inspectable, not by asking for the benefit of the doubt. Here is the security model — described plainly enough for a CISO to verify, line by line.
Six things we can prove.
Not a posture statement — the actual mechanisms that protect personal data inside ConsentEra. Each one is something your team can test.
Field-level encryption
Personal data is encrypted with AES-256-GCM before it touches the database — column by column, not just at the disk.
AES-256-GCMPer-tenant keys, crypto-shred erasure
Every tenant gets its own key, and each person's record is sealed under key material derived beneath it. Erase a person and we destroy that key material — their ciphertext is left permanently unreadable.
Envelope keysDatabase row-level security
Tenant isolation is enforced by the database itself. One tenant cannot read another's rows even if application code is wrong.
Row-level securityTamper-evident audit ledger
Consent receipts and rights actions are written append-only into a hash-chained ledger that's periodically anchored — and re-computable from an export.
Hash-chainedSearch without decrypting
Blind indexing lets your team look up encrypted fields without exposing the plaintext, so day-to-day work never widens the attack surface.
Blind indexKeys you control
Bring your own keys through AWS KMS, Azure Key Vault or HashiCorp Vault. The encryption root stays in your custody, not ours.
BYOK
Erasure that's
final by design.
Deleting rows can leave copies behind. Destroying a key cannot be walked back. That's why erasure in ConsentEra works on the key, not just the record.
No key, no plaintext. The data is left mathematically unreadable.
A root key wraps the data key
Each tenant holds a data key that nothing else can read. A root key — held in your KMS or vault — encrypts that data key. The plaintext data key never rests on disk.
The data key encrypts the record
Every field of personal data is sealed under the tenant's data key with AES-256-GCM. To read anything, the system must first unwrap the data key with the root key.
Erase the person, destroy the key
When someone exercises erasure, we destroy the key material that protects their record. What remains is ciphertext with no key — cryptographically unrecoverable.
Key state · after erasure
Where it lives, who touches it, what we've earned.
The plain version. No badges we don't hold, no claims we can't back. If a question isn't answered here, it's an answer we'll give you on a call.
Data residency
Personal data can be kept within the region you choose. Residency options are agreed in writing before onboarding — ask us what fits your obligations.
Sub-processors
We keep a current list of the third parties that touch infrastructure or data, and what each one does. Ask us and we will send you the current sub-processor list, with notice before it changes.
Security review, on request
Reviewing us for procurement? Ask for the security pack — our control set, data handling, and the answers to the questionnaire you were about to send.
DPDP is phased — the Act was passed in August 2023 and the Rules were notified in November 2025. Consent Manager obligations commence in November 2026, and the substantive duties — notice, consent, rights, breach and children's data — on 13 May 2027. We position ConsentEra as DPDP-ready and keep our claims matched to where the law actually stands.
Found something? Tell us.
Security researchers make this platform safer. If you believe you've found a vulnerability, report it privately and give us a reasonable window to fix it before going public. We won't pursue good-faith research.
enquiry@consentera.inWhat helps us most
- Clear steps to reproduce the issue
- The affected endpoint, page or component
- Impact you believe it has on personal data
- Any proof-of-concept, kept non-destructive
Security you can verify.
Bring your hardest questions on encryption, key custody and isolation. We'll walk your security team through exactly how it works.