Member identity from Wix
On the My Data page the member is auto-resolved from Wix: token-info to subject_id
to an app-token member read. The flow elevates through /whoami and is HMAC-countersigned,
so the address is never user-supplied.
Security & trust
DPDPA.support handles personal data for your data principals, so its security model is deliberate and conservative. Members never type an email, every session is bound to one tenant, secrets live only in a vault, and erasure is a documented processing freeze — not a quiet delete.
Identity
A data principal proves who they are through their Wix membership — not by typing an address into a box. Identity is resolved server-side, countersigned, and an OTP is sent only to that resolved inbox.
On the My Data page the member is auto-resolved from Wix: token-info to subject_id
to an app-token member read. The flow elevates through /whoami and is HMAC-countersigned,
so the address is never user-supplied.
A one-time passcode is then sent only to the resolved inbox for step-up. Guests who are not members see a members-only message — there is no email input field to abuse.
Sessions & secrets
A session token is HMAC(email | instance | exp). A session minted on
one site is invalid on every other site — cross-tenant replay simply does not authenticate.
API keys, fiduciary IDs, policy IDs and DPO email live in OpenBao per instance, or in Wix. Never in code, never in the browser — the front end holds no secret material.
Consent events flow Wix to CMS over RS256-signed webhooks, verified on receipt, so the system of record only accepts events it can cryptographically trust.
Failure & disclosure
Defense-in-depth extends to error handling and to the emails we send on a fiduciary's behalf. Detail goes to logs; people see generic, tenant-voiced text.
Full detail goes to container logs. The user sees generic, tenant-voiced text, and
a UI safeMsg() scrubs infrastructure names — so internal service names never leak to a
data principal.
The From mailbox stays dpo@cynorsense.com so SPF and DKIM remain
intact; the tenant appears as the display name and Reply-To, and the body discloses that we act as a
processor on behalf of the fiduciary.
Erasure
Under erasure, processing genuinely stops the moment a principal asks — but the record is preserved as compliance proof under a documented legal-hold, then purged with proof when the retention clock expires.
Consents are withdrawn, Wix marketing consent is revoked, email subscriptions are unsubscribed, and marketing labels are stripped. Withdrawal is two-way — pushed CMS to Wix so marketing actually stops.
Data is retained storage-only under a documented legal hold with a retention clock (books and tax law). The frozen state itself is the compliance proof an authority may demand.
A retention engine writes a durable registry record at freeze; a daily sweeper purges expired holds, closes the purge trail with proof, and flips the record to purged.
Trust posture
We describe our security posture honestly. We do not claim certifications we do not hold, and DPDPA.support is not a Board-registered Consent Manager — it is the fiduciary's own compliance platform.
We are building toward the ISO 27001 control set. No assessment has been performed and no certification is claimed — "ready" means we are organizing our Information Security Management practices for future review.
Built toward the Trust Services Criteria. "Ready" means prepared for assessment — we will not imply a report exists before it does.
Run under a named Data Protection Officer at dpo@cynorsense.com — a real, reachable point of contact.
Our Security Statement, Data Processing Addendum and Incident Response plan are published in full. Review them, then install DPDPA.support on your Wix site.