This page describes exactly how consent works on VerifyBG, in enough detail that a compliance reviewer can check our claims rather than take them on trust.
No personal data about a subject is retrieved from any source until that subject has signed a consent record. This is enforced server-side on every processing request. A request that has no consent record attached is refused with an error, regardless of what the browser sends.
The full legal name they type, the exact timestamp, their IP address, their browser user agent, and the version of the consent text they were shown. The consent text version is stored so that we can always reconstruct precisely what a given person agreed to, even after the wording changes later.
Consent can be captured at two different strengths, and every record permanently states which one was used. They are never presented as equivalent.
Neither is an Aadhaar-authenticated eSign, and we do not describe either as one anywhere in this product. Aadhaar eSign integration is planned. Because strength is recorded per signature rather than assumed platform-wide, adding it later will not retroactively upgrade or obscure how any earlier consent was actually obtained.
Every consent produces a Certificate of Consent carrying a permanent reference and a QR code. Anyone holding it can confirm it is genuine at verifybg.in/verify/[reference], with no account and no relationship with us. A machine-readable endpoint at /api/verify/[reference] returns the same answer and, importantly, a real HTTP 404 for a reference that was never issued, so an automated check cannot be fooled by a fabricated certificate.
Verification deliberately discloses the consent and its scope, never the findings of any check. Proving that consent lawfully exists and revealing what a background check returned are different acts, and only the first is safe to expose to whoever holds a reference.
Consent records remain verifiable after the underlying personal data is deleted at the end of the retention window. The record then confirms that consent existed and what it covered, without continuing to assert who it was about.
What is recorded as signer context: the name typed, the exact timestamp, IP address, browser user agent, a coarse device description parsed from it, and the timezone the browser reports. Location is deliberately not collected. A consent form has no need for a person's whereabouts, and gathering it merely because it is technically possible would fail the data minimisation the DPDP Act requires.
The consent link and the finished report are protected by different tokens. Holding a consent link never grants access to a completed report, and a report share link cannot be used to sign consent. Report share links additionally expire after seven days and can be revoked at any time by the account holder.
A subject may withdraw consent by writing to our contact page from an address we can reasonably tie to them, or by replying to the consent request.
On withdrawal we record it against the consent, along with how the request reached us and how we satisfied ourselves it genuinely came from the subject. From that moment the consent stops authorising anything: our servers refuse to run any further check against it, and the personal data is brought forward for deletion on the next purge.
The consent record itself is not erased. That record is what evidences the earlier processing was lawful at the time it happened, and destroying it would weaken the subject's position rather than protect it. After withdrawal the record continues to verify, and states plainly that consent was given and has since been withdrawn.
Every consent signature, every check completion, every report view or download, and every dispute is written to an append-only audit log. There is deliberately no code path in this application that edits or deletes an audit entry.