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.
-
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.