Data Protection Impact Assessment

Formal DPIA for Maelstrom AI's age verification processing activities

Public

Assessment Overview

FieldDetail
Assessment DateFebruary 2026
AssessorISMS Owner
Processing ActivityZero knowledge age verification credential issuance and verification
ControllerMaelstrom AI Pty Ltd ATF Maelstrom AI Holding Trust (trading as Provii)
Legal EntityABN 61 633 823 792
DPIA BasisConducted as good practice; mandatory criteria under Article 35(3) not met (see GDPR Compliance Statement)

1. Description of Processing

Nature

Maelstrom AI provides zero knowledge age verification infrastructure. The system enables users to prove they meet an age threshold (e.g., over 18) without revealing their actual date of birth or any other personal information. The cryptographic protocol uses Groth16 ZK-SNARKs, Pedersen commitments, and RedJubjub signatures to achieve this.

Scope

  • Users. Global, all ages including children (the system verifies age thresholds for under-18s)
  • Geography. Worldwide, with primary regulatory focus on EU/EEA (GDPR) and Australia (Privacy Act 1988)
  • Volume. Variable; scales with relying party adoption
  • Frequency. On-demand per verification request

Context

Maelstrom AI operates in a B2B2C model. Relying parties (websites, applications) integrate Provii’s age verification API. End users interact with Provii through the wallet application and the relying party’s integration. Maelstrom AI acts as both data controller (for operational IP logs) and data processor (when providing verification services on behalf of relying parties).

Purpose

Enable age-gated access to content and services without exposing personal information. The system replaces traditional age verification methods (ID document upload, credit card checks) with a privacy-preserving cryptographic alternative.

Data Processed

Data ElementProcessing StageRetentionNature
Date of birthIssuance onlyEphemeral. processed in memory, immediately discarded after Pedersen commitment computationPersonal data (transient)
IP addressesAll API requests90 days, hashed (HMAC-SHA-256)Personal data
Challenge noncesVerification5-minute TTL (provii-verifier) / 2-minute TTL (provii-issuer), auto-deletedNot personal data (random UUIDs)
Pedersen commitmentsStored in credentialCredential lifetime (user-controlled)Mathematical value, not personal data
Credential nullifiersVerificationImmediate (not retained post-verification)One-way hash, not reversible to personal data
Zero knowledge proofsVerificationNot retainedMathematical proof, not personal data

2. Necessity and Proportionality

Lawful Basis

  • Legitimate interest (Article 6(1)(f)): IP address logging for fraud prevention and service security. A Legitimate Interest Assessment (LIA) has been conducted confirming the processing is necessary and proportionate.
  • Contract performance (Article 6(1)(b)): Challenge creation and proof verification to fulfil age verification service obligations to relying parties.

Data Minimisation

Maelstrom AI’s zero knowledge architecture is designed around the principle of minimum disclosure:

  1. DOB. Processed only during credential issuance, held ephemerally in memory, discarded immediately after Pedersen commitment computation. Never written to persistent storage, logs, or external systems.
  2. IP addresses. The only personal data retained. Hashed with HMAC-SHA-256 in logs. Used solely for anti-abuse and rate limiting.
  3. No collection of. names, email addresses, physical addresses, phone numbers, identity documents, biometric data, financial information, device identifiers, or browsing history.

Storage Limitation

DataRetentionDeletion Mechanism
Date of birthZero (ephemeral in-memory only)Discarded after Pedersen commitment computation; memory zeroised via zeroize crate
IP addresses (hashed)90 daysKV TTL-based auto-deletion
Challenge state5 minutesCloudflare KV TTL-based auto-deletion
Nonce records5 minutes (provii-verifier) / 2 minutes (provii-issuer)Cloudflare KV TTL-based auto-deletion
Audit logs90 days (standard); critical security event logs up to 365 daysKV TTL, cleanup workers

Purpose Limitation

All data processing is strictly limited to credential issuance and age verification. No secondary uses occur:

  • No marketing or advertising
  • No cross-site tracking or user profiling
  • No analytics beyond operational monitoring
  • No third-party data sharing (except Cloudflare as infrastructure sub-processor)
  • No identity resolution or re-identification attempts

3. Risk Assessment

RiskLikelihoodImpactMitigationResidual Risk
DOB interception during issuanceLowHighTLS 1.3 encryption for all transmissions; ephemeral in-memory processing; DOB never written to persistent storage; memory zeroised after useLow
Pedersen commitment linkabilityVery LowMediumCommitments are perfectly hiding (information-theoretic security); random blinding factors prevent linkage between commitments; no centralised commitment databaseVery Low
IP address correlationLowLowIP addresses hashed with HMAC-SHA-256; 90-day automatic expiry; no cross-referencing with external datasets; no persistent user identifiersLow
Service disruption affecting availabilityMediumMediumCloudflare edge distribution across 300+ locations; DDoS protection; edge-based redundancy through Cloudflare’s global network; business continuity procedures documentedLow
Signing key compromiseVery LowHighAES-256-GCM envelope encryption for key storage; Cloudflare Workers Secrets (encrypted, access-controlled); key rotation procedures; credential revocation capabilityLow

4. Measures to Address Risks

Technical Measures

  1. Transport Security: TLS 1.3 preferred for all external communications (TLS 1.2 minimum). HSTS with preload (max-age 31,536,000 seconds). Cloudflare Universal SSL with automatic certificate management.

  2. Ephemeral DOB Processing: Date of birth is received over TLS, held only in memory during Pedersen commitment computation, and immediately discarded. The zeroize crate is used to securely clear memory after processing. DOB is never written to logs, databases, or any persistent storage.

  3. Pedersen Commitment Unlinkability: Commitments use random blinding factors, providing perfect hiding (information-theoretic security). Even with unlimited computational resources, the DOB cannot be extracted from the commitment without the blinding factor. Different blinding factors per credential prevent cross-credential linkage.

  4. IP Address Hashing: All IP addresses are hashed with HMAC-SHA-256 keyed by PII_HASH_KEY before storage in logs. Raw IP addresses are not persisted beyond the request lifecycle. Standard audit log entries are retained for 90 days. Critical security events (such as detected attacks, replay attempts, and IP blocks) are retained for up to 365 days to support security investigation.

  5. Infrastructure Protection: Cloudflare provides DDoS mitigation, Web Application Firewall rules, and edge distribution across 300+ global locations. Multi-layered rate limiting (per-IP, per-client, global) prevents abuse.

  6. Key Management: Signing keys protected with AES-256-GCM envelope encryption. Keys stored in Cloudflare Workers Secrets (encrypted at rest, access-controlled). Key rotation procedures documented in operational runbooks.

Organisational Measures

  1. Access Control: Role-based access control (RBAC) with viewer, admin, and super_admin roles. Quarterly access reviews. Principle of least privilege enforced. MFA required for administrative access.

  2. Security Testing: Automated dependency scanning (cargo audit, npm audit, Dependabot). OWASP ASVS 5.0.0 Level 3 self-assessment for provii-verifier. 25 fuzzing targets for cryptographic code. Property-based testing for security properties.

  3. Incident Response: Documented incident response procedures with severity classification (P0-P3). Breach notification procedures aligned with Article 33 (72-hour notification) and Article 34 (data subject communication).

  4. Audit and Review: audit logging in provii-management and provii-verifier. 90-day audit log retention. Annual internal security audits. Management review of ISMS effectiveness.


5. Consultation

Data Protection Authority Consultation

Article 36 requires prior consultation with the supervisory authority where a DPIA indicates that processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.

Consultation Required: No.

Rationale: The risk assessment demonstrates that all identified risks are effectively mitigated through Maelstrom AI’s cryptographic architecture and data minimisation practices. No high residual risks remain after mitigation measures are applied. The zero knowledge design inherently limits the risk profile by preventing the collection and retention of personal data.

Stakeholder Consultation

  • Relying parties. Informed of Provii’s privacy architecture through published ISMS documentation and technical integration guides
  • End users. Informed through wallet application privacy information and published privacy documentation at docs.provii.app

6. Conclusion

This assessment confirms that Maelstrom AI’s age verification processing is proportionate and necessary. The zero knowledge cryptographic architecture is designed to provide privacy protection that meets or exceeds standard GDPR requirements through strong technical controls rather than procedural controls alone.

Key findings:

  • DOB processing is genuinely ephemeral, with no persistent storage at any layer
  • The only retained personal data (IP addresses) is hashed and auto-expires after 90 days
  • Pedersen commitments provide information-theoretic hiding, making re-identification from stored credentials mathematically infeasible
  • All identified risks have been mitigated to Low or Very Low residual risk levels
  • No high residual risks were identified

Determination: Processing may proceed. No prior consultation with the supervisory authority is required under Article 36.

Reassessment Triggers: This DPIA will be reassessed if:

  • Processing activities change materially (e.g., new data types collected)
  • Processing scale increases significantly
  • The cryptographic protocol is modified
  • New risks are identified through security testing or incident review
  • Regulatory guidance changes interpretation of DPIA requirements

Document Information

FieldValue
Version1.0
OwnerISMS Owner
Date2026-02-13
Next Review2027-02-13
ClassificationPublic
Related DocumentsGDPR Compliance Statement, Data Retention & Disposal Policy, Incident Response, Information Security Policy