DPDP SandBox — what to try, and what to watch
This fictional bank site exercises every public DPSuite surface against the
live demo tenant bank-demo. Act as a visitor here, then switch to the
DPSuite console
to see what the institution's compliance team sees. The
Data Principal portal
is the self-service side.
-
Cookie banner — accept, reject, or choose per purpose
On the home page, answer the age gate, then make a choice. Watch the
"DPSuite demo instrumentation" chip (bottom-left): inert tags stay
BLOCKEDuntil their purpose is granted, and the Google Consent Mode signal updates with your decision.Console → Consent: your decision appears as ConsentEvents bound to notice impressions — one event per granted purpose, on the same ledger as every other consent. Rejecting all still records that the notice was shown.
-
Identified consent with a receipt
On Open an account, complete the embedded consent form with a
name + email you'll recognise. You'll get a receipt hash on screen.
Console → Consent: the grant resolves to a real Data Principal (your email, stored encrypted; shown masked). The receipt hash is the tamper-evident digest of the capture.
-
File a rights request
On the Privacy centre, submit e.g. an Access request and note the reference.
Console → Rights queue: the request arrives with its 90-day statutory clock already running. Track the same reference on the portal.
-
Withdraw a consent
On the portal
consent dashboard, withdraw something you granted.
Console → Consent history: the withdrawal lands on the same ledger. Back on the home page, use the instrumentation chip's Reset to clear the browser copy and see the banner again.
-
Granular multi-purpose consent (one screen, per-purpose choices)
In the console as a staff user: Consent → Requests → New request, tick several forms
(e.g. Netbanking servicing + Marketing preferences + Anchor Fixed Deposits) and create a LINK
request. Open the generated link as the recipient: one screen renders every purpose with its own
notice and an individual accept/decline — accept one, decline another, and submit.
Console → Consent: one ConsentEvent per purpose, each with your per-purpose decision — consent is never bundled (a mixed response shows as MIXED on the request). This is the surface for granularity checks: partial grant, partial withdrawal, and no forced "accept all".
-
Nothing pre-selected + essential vs non-mandatory purposes
Every consent screen starts blank: no toggle is pre-ticked, and submission is refused until you
answer every purpose explicitly. Retail netbanking servicing is marked
essential on this tenant —
open its consent form
to see the "Required for service" badge with a plain-language note. Marketing
stays non-mandatory. See both together on
Open an account — the "Application consent — mandatory &
optional on one screen" card: two checkboxes, nothing pre-ticked, the application is blocked
until the mandatory (Bank application) consent is ticked, and the optional (Marketing) box can be
left off with the application unaffected — the refusal itself still records on the ledger.
Declining an essential purpose still records — the badge labels, it never pre-selects and never blocks a refusal (consent stays free under Section 6). Console → Inventory → Purposes: marking a purpose essential requires a recorded rationale — a tenant decision on the audit trail, not a vendor default.
-
OTP-verified consent capture (per form)
Console → Notices → Embed & share: each form has an "Email OTP at capture"
toggle. When on, an "I agree" requires a 6-digit code sent to the person's email — rate-limited,
five wrong attempts kill the code, single-use — and the receipt shows "Verified by email
code" with the verification hash-bound into the consent evidence. Declining never needs a code.
Live on this demo — try it on the hosted Netbanking servicing form: choose "I agree", enter your email, and a 6-digit code arrives before the consent records. Note: while the demo's email account awaits AWS production approval, codes deliver only to pre-verified tester addresses — share your email with the DPSuite team once and it works thereafter. An OTP form with no working transport refuses loudly rather than silently skipping verification — that is by design.
-
Consent expiry (validity period)
Marketing consent on this tenant now carries a 12-month validity (tenant policy
consent.validity_months). Grant marketing consent on Open an account, then Console → Consent → Validate with your receipt hash: the record shows itsexpiresAt; past that instant the ledger answers EXPIRED and a fresh consent is required. -
Notice in Hindi
The published notices for Netbanking servicing, Marketing and Anchor FD each carry an approved
हिन्दी variant (Eighth Schedule languages). The Data Principal portal has a language picker
(23 languages); API surfaces serve a variant via
?lang=hi. - Withdrawal cascade to downstream systems & processors Marketing's data-flow lineage now includes the CRM processor (CloudCRM). Withdraw a marketing consent, then check Console → Consent history and the withdrawal's dispatch list: one stop-processing dispatch is queued per downstream system and processor in the lineage.
-
Scan this site for trackers
Console → Cookies → Scan: scan
https://sandbox.dpsuite.demo.probitygrc.com/. The scanner will find the tracker signatures on the home page (Google, Meta, Hotjar, Segment, DoubleClick) — plus three it has never seen (Microsoft Clarity, HubSpot, LinkedIn) and the server-setBODSESSIONcookie.New findings import as Unclassified — and the banner on this site deliberately stops rendering until you classify them (essential, or non-essential mapped to a purpose). That is the fail-closed doctrine: a banner that cannot honestly describe what it drops must not render. Classify the new items and the banner returns. Note: the scanner reads HTTP responses — it sees markup and server-set cookies, not JavaScript-set cookies; that's expected.