Data Subject Request (DSAR) Procedure

Implements: Privacy Policy, GDPR Articles 15-22, CCPA Section 1798.100 Owner: Privacy Officer Last Updated: 19 June 2026 Next Review: 21 November 2026

Scope

This procedure operates at the Maelstrom AI organisation level and covers data subject requests across both platforms — Provii (zero-knowledge age verification) and downpipes (no-custody backup & disaster recovery for the Cloudflare data layer).

In practice, a data subject request reaches Maelstrom against very little personal data, for two distinct architectural reasons:

• Provii uses a zero knowledge architecture: Maelstrom-operated services persist no names, addresses, raw dates of birth or identity-document data, and verification sessions are unlinkable by design. The residual operational data is limited to hashed IPs, session metadata and nullifiers (see below).
• downpipes is no-custody: the engine and console run in the customer’s own Cloudflare account, under the customer’s keys, and Maelstrom holds no customer keys, data or Cloudflare tokens and keeps no standing inbound path. Customer data never enters Maelstrom’s custody, so there is no end-user personal data for Maelstrom to hold, surface or delete in response to a request. A data subject whose data is held within a customer’s downpipes deployment must direct the request to that customer (the controller), who operates the deployment as a complementary user-entity control (CUEC).

The substantive request-handling guidance below therefore concerns the data Maelstrom does process — principally Provii’s residual operational data and operational contact details — while the process steps apply organisation-wide.

Request Channels

DSARs are received via:

• Email. privacy@maelstrom.au
• From controllers. Controller forwards data subject request per DPA terms

Request Types and Responses

Access Request (GDPR Art. 15 / CCPA 1798.100)

What we can provide:

• Whether we process any data about the requester
• Categories of data processed (hashed IP, session metadata, nullifiers)
• Retention periods
• Processing purposes

What we cannot provide:

• The requester’s original IP address (we only store SHA-256 hashes, which are not reversible to recover the original address)
• Verification history linked to a person (Provii sessions are unlinkable by design)
• Date of birth (never stored. discarded after issuance)
• Any end-user data held within a customer’s downpipes deployment (no-custody; that data resides in the customer’s own Cloudflare account, never in Maelstrom’s custody — refer the requester to the customer as controller)

Response: Template letter explaining the relevant architecture — Provii’s zero knowledge design and/or downpipes’ no-custody model — and confirming minimal data processing.

Deletion Request (GDPR Art. 17 / CCPA 1798.105)

What we can delete:

• Nothing user-specific to delete. we don’t have persistent personal data linked to identifiable individuals
• Hashed IP logs expire automatically after 90 days; critical security event logs are retained for up to 365 days
• Challenge sessions expire after 5 minutes

Response: Template letter confirming that Maelstrom AI does not retain personal data that can be linked to the requester, and that all operational data expires automatically. For data held within a customer’s downpipes deployment, the no-custody model means Maelstrom holds nothing to delete and the request is referred to the customer as controller.

Portability Request (GDPR Art. 20)

Response: Not applicable. Maelstrom AI does not hold personal data in a structured, commonly used format that could be ported. For Provii, the zero knowledge architecture means there is no personal data to export; for downpipes, the no-custody model means any portable data resides in the customer’s own Cloudflare account and is exported by the customer, not Maelstrom.

Objection / Restriction (GDPR Art. 21 / Art. 18)

Response: The requester can stop using the relevant service. We do not process personal data for profiling, direct marketing, or any purpose the requester could meaningfully object to. Where the objection concerns a customer’s downpipes deployment, it is referred to that customer as controller.

Processing Steps

1. Receive and Log

• Log the request in the DSAR register with: date received, requester identity/contact, request type, source (direct or via controller)
• Acknowledge receipt within 2 business days

2. Verify Identity

1. For direct requests: Request sufficient information to confirm identity (email address associated with the request)
2. For controller-forwarded requests: The controller has already verified identity
3. Do NOT request excessive identification documents. we hold minimal data

3. Assess and Respond

1. Determine which request type applies, and which platform it concerns
2. If the data is held within a customer’s downpipes deployment (no-custody), Maelstrom holds nothing to action — refer the requester to the customer as controller and record the referral
3. Prepare response using the appropriate template
4. Response deadline: 30 days from receipt (GDPR), 45 days (CCPA)

4. Send Response

1. Send via email to the requester or the forwarding controller
2. Use plain language appropriate to the audience
3. If the requester is a child (or their parent/guardian), adjust language accordingly

5. Close and Record

• Record the response date, outcome, and any notes in the DSAR register
• Retain the DSAR register entry for 90 days (audit log retention period); critical security event logs are retained for up to 365 days

DSAR Register