ISO 27701:2019 Privacy Information Management System

Compliance Documentation for Provii Age Verification Platform

Executive Summary

This document demonstrates Maelstrom AI’s alignment with ISO/IEC 27701:2019, the international standard for Privacy Information Management Systems (PIMS). ISO 27701 extends ISO 27001 with privacy-specific controls for organisations acting as Personally Identifiable Information (PII) controllers and processors.

Compliance Posture

Overall Implementation Rate: 89% (74 of 83 Annex A controls implemented or not applicable)

Key Findings:

1. Architectural Privacy by Design: Provii’s zero knowledge proof architecture provides strong privacy properties that are designed to exceed traditional compliance approaches. The system is designed to make PII collection technically infeasible at the protocol level, not merely discouraged.

2. Data Minimization Excellence: By design, Maelstrom AI collects NO traditional PII through the Provii platform (no names, addresses, emails, phone numbers, or dates of birth). Age verification occurs through cryptographic proofs that reveal only a binary yes/no answer to “is user ≥ age threshold?”

3. Strong Controller Compliance: 74 of 83 Annex A PII controller controls are either fully implemented (58 controls) or not applicable due to the zero-PII architecture (16 controls).

4. Limited Processor Role: Maelstrom AI acts as a processor for minimal operational data only (IP addresses for abuse prevention, retained 90 days).

5. Transparency Leadership: All cryptographic implementations, verification algorithms, and security controls are open source and publicly auditable.

Privacy Implementation Benefits

Provii’s privacy architecture reduces the scope of many traditional privacy controls:

• Simplified consent management. DOB processed ephemerally during issuance and immediately discarded; no PII persisted, simplifying consent requirements
• Minimal data subject access requests. No long-term PII stored (DOB discarded after commitment computation); only transient IP-address logs retained for 90 days
• Simplified data portability. Minimal PII persisted means very limited data to port
• Simplified right to erasure. No long-term personal data persisted; automatic deletion after 90 days
• Minimal cross-border transfer restrictions. Cryptographic proofs contain no PII; only IP logs subject to transfer controls

Identified Gaps

Critical Gaps: None

High Priority Gaps (1):

1. Privacy breach notification procedures need enhancement (UC-027: Privacy Incident Response)

Medium Priority Gaps (3):

1. Formal API versioning strategy (UC-155: API Versioning)
2. Penetration testing (scheduled post-launch) (UC-159: Penetration Testing)
3. Status page enhancements (UC-170: Incident Communication)

Certification Readiness

Timeline to Certification: 12-18 months (if pursued)

Readiness Assessment:

• Documentation. 95% complete (this document + existing ISMS)
• Technical Controls. 92% implemented
• Process Controls. 85% implemented
• Testing & Validation. 70% complete (tabletop exercises planned Q1 2026)

Required Actions Before Certification:

1. ✅ Conduct privacy impact assessments for all system components (Completed: Feb 2026. DPIA)
2. Privacy awareness maintained through professional certifications (CISSP, Security+, PenTest+, SecurityX)
3. Complete first BCP tabletop exercise (Q2 2026)
4. ✅ Implement automated KV backups (Completed: Jan 2025, provii-backup deployed)
5. Conduct penetration testing (Q2 2026)
6. Document privacy breach notification procedures (Q1 2026)
7. Stage 1 audit (documentation review) (Q3 2026)
8. Stage 2 audit (implementation assessment) (Q4 2026)

Introduction

About ISO 27701:2019

ISO/IEC 27701:2019 is the international standard that specifies requirements and provides guidance for establishing, implementing, maintaining, and continually improving a Privacy Information Management System (PIMS). Published in August 2019, it extends ISO/IEC 27001 and ISO/IEC 27002 with additional privacy-specific requirements and controls.

Structure:

• Clauses 1-4. Scope, references, terms, and definitions
• Clause 5. PIMS-specific requirements for ISO 27001 (governance, leadership, planning)
• Clause 6. PIMS-specific guidance for ISO 27002
• Clause 7. Additional guidance for PII controllers and processors
• Clause 8. PIMS-specific requirements relating to ISO/IEC 27002 (extends ISO 27002 controls with privacy-specific guidance)

Annexes:

• Annex A. Additional ISO 27002 controls for PII controllers (83 controls)
• Annex B. Additional ISO 27002 controls for PII processors (24 controls)
• Annex C. Mapping to GDPR
• Annex D. Mapping to other regulations
• Annex E. PII data inventory template

Relationship to ISO 27001: ISO 27701 is an extension of ISO 27001, not a standalone standard. Organisations must implement ISO 27001 as the foundation, then layer ISO 27701 privacy controls on top. Maelstrom AI’s existing ISO 27001-aligned Information Security Management System (ISMS) provides this foundation.

Scope of This Assessment

This compliance documentation covers:

In Scope:

1. Provii Verifier API (verify.provii.app) - Age verification service
2. Provii Issuer API (issuer.provii.app) - Credential issuance platform
3. Provii Wallet SDK - Mobile application for end users
4. Age Verification Flow - Complete challenge-proof-redeem lifecycle
5. Cryptographic Architecture - Zero knowledge proof system
6. Infrastructure - Cloudflare Workers, KV, Durable Objects
7. Development Operations - CI/CD, security scanning, supply chain
8. Business Continuity - Disaster recovery, high availability

Out of Scope (Not Applicable):

1. Human Resources PII (Annex A 7.2.9) - No employees, contractor-only model
2. Marketing PII (Annex A 7.3.7) - No marketing database, no email campaigns
3. E-commerce PII - No online sales, payment processing, or shipping
4. Customer relationship management - No CRM system
5. Traditional database PII - No SQL/NoSQL databases storing personal information

Regulatory Context: While ISO 27701 is regulation-neutral, this assessment considers alignment with:

• GDPR (EU General Data Protection Regulation)
• CCPA/CPRA (California Consumer Privacy Act / Rights Act)
• COPPA (Children’s Online Privacy Protection Act)
• UK Data Protection Act 2018
• Privacy By Design principles (Ann Cavoukian)

Methodology

This compliance assessment was conducted through:

1. Evidence Collection (November 2024 - January 2025)

• Automated code analysis across 8 repositories
• Review of 12 evidence documents
• Analysis of CI/CD pipelines, security configurations
• Infrastructure architecture documentation
• Interview with system architects and security engineers

2. Control Mapping

• Each of 83 Annex A controls mapped to Provii implementations
• Evidence cross-referenced with file paths and line numbers
• Gap analysis for incomplete controls
• Risk assessment for non-applicable controls

3. Documentation Review

• Unified Control Matrix (4,200+ lines)
• Evidence Mapping Document
• Existing ISMS policies (change management, incident response, business continuity, etc.)
• Cryptographic implementation specifications
• Privacy architecture documentation

4. Verification

• Code review of cryptographic primitives
• Verification of security controls in CI/CD
• Infrastructure configuration validation
• Privacy-by-design architectural analysis

Evidence Quality Standards:

• Strong. Direct code evidence with file:line references, verified implementations
• Moderate. Documented procedures with partial implementation evidence
• Weak. Planned controls with design documentation only
• Not Applicable. Controls irrelevant to Provii’s zero-PII architecture

Privacy Management Framework

Clause 5: PIMS-Specific Requirements

ISO 27701 Clause 5 extends ISO 27001 Clause 5 with privacy-specific requirements for organisational context, leadership, planning, support, and operation.

5.1 General

Requirement: The organisation shall establish, implement, maintain, and continually improve a PIMS, including the processes needed and their interactions, in accordance with ISO 27001 Clause 5.

Maelstrom AI Implementation:

Maelstrom AI’s PIMS is integrated into the existing Information Security Management System (ISMS) documented in /trust/security/. The PIMS extends the ISMS with privacy-specific considerations:

• Privacy Policy Foundation. Information Security Policy (information-security-policy.mdx) establishes privacy as a core security objective
• Privacy Risk Management. Risk Register (risk-register.mdx) includes privacy risks (RISK-2025-L006: Privacy incident, RISK-2025-M007: Regulatory compliance)
• Privacy Processes. Change management, incident response, business continuity all consider privacy impacts
• Continuous Improvement. Quarterly ISMS reviews include privacy control effectiveness

Evidence:

• /trust/security/information-security-policy.mdx - ISMS foundation
• /trust/security/risk-register.mdx - Privacy risk identification
• /trust/project tracker - PIMS implementation tracking

Status: ✅ Implemented

Gap: Privacy-specific improvement metrics not yet tracked separately from security metrics. Recommendation: Add privacy KPIs to quarterly review (e.g., privacy-related support requests, DPIA completions, privacy training completion rates).

5.2 Leadership and Commitment

Requirement (5.2.1): Top management shall demonstrate leadership and commitment to the PIMS by ensuring the privacy policy is established and compatible with the strategic direction of the organisation.

Maelstrom AI Implementation:

Privacy leadership is embedded in the organisational structure:

1. ISMS Owner. Privacy policy oversight, strategic privacy decisions
2. Privacy Officer. Operational privacy controls, incident response
3. Privacy-First Architecture. Strategic decision to build zero-PII system from inception

The zero knowledge architecture represents top management’s commitment to privacy as a core design principle, not merely a compliance checkbox.

Evidence:

• /trust/security/information-security-policy.mdx - Lines 18-21 (ISMS Owner ownership)
• Privacy architecture decisions reflected in crypto-implementation-evidence.md
• Unified Control Matrix - Privacy controls prioritised as “Critical”

Status: ✅ Implemented

Gap: Privacy policy not published as standalone document. Currently embedded in Information Security Policy. Recommendation: Extract privacy-specific statements into dedicated Privacy Policy for external publication.

5.3 Organisational Roles, Responsibilities, and Authorities

Requirement (5.3.1): Top management shall ensure that responsibilities and authorities for roles relevant to the PIMS are assigned and communicated.

Maelstrom AI Implementation:

Privacy Roles Defined:

Evidence:

• /trust/security/information-security-policy.mdx - Role definitions
• Incident Response Policy - Privacy incident escalation chain
• Change Management Policy - Privacy review requirements

Status: ✅ Implemented

Gap: No formal Data Protection Officer (DPO) appointed. For EU GDPR compliance, may need DPO if processing scale increases. Currently, Privacy Officer acts as privacy lead.

5.4 Privacy by Design and Privacy by Default

Requirement (5.4.1): The organisation shall adopt privacy by design and privacy by default principles.

Maelstrom AI Implementation:

Provii’s zero knowledge architecture is the ultimate expression of Privacy by Design:

Privacy by Design Principles (Ann Cavoukian’s 7 Principles):

1. Proactive not Reactive: System designed to make PII collection technically infeasible at the protocol level, not just discouraged
2. Privacy as Default: No configuration needed - privacy is architectural, not optional
3. Privacy Embedded in Design: Zero knowledge proofs at the protocol level
4. Full Functionality: Privacy doesn’t compromise age verification effectiveness
5. End-to-End Security: Cryptographic protection throughout lifecycle
6. Visibility and Transparency: Open-source code, public ISMS
7. Respect for User Privacy: User-centric design, no data hoarding

Technical Implementation:

Traditional Age Verification (Privacy-Invasive):
User → Uploads ID Document → Relying Party Stores DOB, Name, Address → Verification

Provii (Privacy-Preserving):
User → Wallet submits DOB attestation + r_bits to Issuer API (one-time issuance, DOB discarded immediately) → Wallet generates ZK Proof locally → Relying Party Receives Yes/No → No PII Stored

The cryptographic proof reveals only:

• cutoff_days: Age threshold (e.g., 18 years = 6,570 days)
• rp_hash: Which website requested verification
• issuer_vk: Which issuer certified the credential
• cred_nullifier: Unique proof identifier (prevents reuse)

Not revealed by design:

• Date of birth
• Actual age
• Name, address, government ID number
• Any linkable identifier across sites

Evidence:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md - Complete PbD analysis
• provii-crypto/crypto-verifier/src/lib.rs - Lines 23-52 (proof verification public inputs)
• Age Verification Flow Evidence - UC-083 through UC-093

Status: ✅ Implemented (Exemplary)

Industry Recognition: Provii’s privacy-by-design approach is designed to exceed ISO 27701 requirements and aligns with NIST Privacy Framework “Predictive-P” (Privacy-Enhancing Technologies).

5.5 Privacy Impact Assessment (PIA/DPIA)

Requirement (5.5.1): The organisation shall establish and implement a process for undertaking privacy impact assessments for new or changed processing of PII.

Maelstrom AI Implementation Status: 🔄 Partially Implemented

Current State:

• Privacy architecture analysis completed (privacy-architecture-evidence.md)
• Risk register includes privacy risks (risk-register.mdx)
• Change management process considers privacy impacts (change-management.mdx)

Status: ✅ Completed. formal Data Protection Impact Assessment conducted (February 2026), covering Verifier API, Issuer API, and Cloudflare sub-processing.

DPIA Process (for future assessments):

1. Screening: Determine if DPIA required (any new PII processing = yes)
2. Stakeholder Consultation: Involve Privacy Officer and affected teams
3. Assessment: Identify data flows, privacy risks, mitigation measures
4. Documentation: Complete DPIA template with sign-off
5. Review: Reassess DPIAs annually or when processing changes
6. Integration: Link DPIA to risk register, change management

Evidence:

• Data Protection Impact Assessment - Formal DPIA
• Unified Control Matrix - UC-006: Privacy Impact Assessment
• Privacy Architecture Evidence - Supporting analysis

Status: 📋 Planned (Q1 2026)

Priority: High (Required for ISO 27701 certification)

Clause 6: Planning

6.1 Actions to Address Risks and Opportunities

Requirement (6.1.1): When planning for the PIMS, the organisation shall determine risks and opportunities related to privacy that need to be addressed.

Maelstrom AI Implementation:

Privacy risks are integrated into the enterprise risk management process:

Privacy-Specific Risks Identified:

1. RISK-2025-L006: Privacy Incident / Data Breach

• Impact: Minor (2) - Limited PII exposure due to zero-PII architecture
• Likelihood: Unlikely (2)
• Risk Score: 4 (Low)
• Mitigation: Zero knowledge architecture (architectural control)
• Evidence: /trust/security/risk-register.mdx - Lines 196-222

2. RISK-2025-M007: Regulatory Non-Compliance (Privacy)

• Impact: Moderate (3) - Fines, reputational damage
• Likelihood: Possible (3)
• Risk Score: 9 (Medium)
• Mitigation: ISO 27701 compliance program, GDPR alignment, legal review
• Evidence: Risk Register - Lines 224-250

3. RISK-2025-M005: KV Data Loss (Operational Data)

• Impact: Moderate (3) - Loss of signing keys, configuration
• Likelihood: Unlikely (2)
• Risk Score: 6 (Medium)
• Mitigation: Automated KV backups (completed Jan 2025, provii-backup deployed)
• Evidence: Business Continuity Evidence - Line 191 (gap identified)

Privacy Opportunities:

1. Privacy Benefits: Zero-PII architecture reduces compliance burden and supports user trust
2. Simplified Compliance: No PII = reduced GDPR, CCPA compliance burden
3. Trust Building: Open-source privacy controls build user confidence
4. Regulatory Leadership: Potential to influence future privacy-preserving identity standards

Evidence:

• /trust/security/risk-register.mdx - Privacy risk identification
• Privacy Architecture Evidence - Competitive analysis of privacy advantages

Status: ✅ Implemented

Gap: Privacy risk assessment not conducted separately from security risk assessment. Recommendation: Add privacy-specific risk categories to risk register (e.g., “Privacy Risk” tag).

6.2 Privacy Objectives and Planning to Achieve Them

Requirement (6.2.1): The organisation shall establish privacy objectives at relevant functions and levels.

Maelstrom AI Implementation:

Privacy Objectives Established:

1. Zero PII Collection: Architectural objective - never collect traditional PII

• Measure: Code audits confirm no PII fields in data models
• Status: ✅ Achieved (verified in privacy-architecture-evidence.md)

2. Cryptographic Privacy: All age verification via zero knowledge proofs

• Measure: 100% of verifications use zkSNARKs
• Status: ✅ Achieved (only verification method available)

3. Minimal Operational Data: Collect only IP addresses for abuse prevention

• Measure: 90-day retention, automatic deletion
• Status: ✅ Achieved (data-lifecycle-evidence.md confirms)

4. Transparency: Public ISMS, open source cryptography

• Measure: All security documentation public, all crypto code public
• Status: ✅ Achieved (public repositories in our GitHub organisation)

5. User Control: Users control when/where credentials are shared

• Measure: Wallet-based architecture, explicit consent per verification
• Status: ✅ Achieved (mobile wallet SDK architecture)

Evidence:

• Privacy Architecture Evidence - Privacy objectives articulated throughout
• Unified Control Matrix - Privacy controls prioritised
• Zero-PII architecture verified in evidence documents

Status: ✅ Implemented

Gap: Privacy objectives not documented in standalone privacy policy. Recommendation: Formalize privacy objectives in dedicated privacy policy document.

Clause 7: Support

7.1 Resources

Requirement (7.1.1): The organisation shall determine and provide resources needed for the PIMS.

Maelstrom AI Implementation:

Privacy Resources Allocated:

1. Personnel:

• ISMS Owner: 20% time on privacy strategy, policy
• Privacy Officer: 40% time on privacy controls, monitoring
• Developers: Privacy-by-design in all development
• Contractors: As needed for audits, legal review

2. Technology:

• Cloudflare Workers, KV, Durable Objects (privacy-preserving infrastructure)
• GitHub Advanced Security (dependency scanning, secret detection)
• Cryptographic libraries (bellman, bls12_381, zero knowledge proof stack)
• CI/CD pipelines with security/privacy gates

3. Budget (Estimated Annual):

• Cloudflare Enterprise: $50,000/year (infrastructure)
• GitHub Enterprise: $21/user/month (development tools)
• Security tooling: $10,000/year (Snyk, CodeQL, etc.)
• Compliance: $25,000/year (audits, certifications, legal)
• Total. ~$100,000/year privacy-related spend

Evidence:

• Infrastructure Evidence - Cloudflare service catalog
• DevOps Evidence - Security tooling inventory
• Supplier Management - Vendor contracts

Status: ✅ Implemented

Gap: No dedicated privacy budget line item. Privacy costs bundled with security. Recommendation: Track privacy-specific costs separately for ROI analysis.

7.2 Competence

Requirement (7.2.1): The organisation shall ensure that persons doing work under its control that affects its privacy performance are competent.

Maelstrom AI Implementation Status: 🔄 Partially Implemented

Current Competence:

• ISMS Owner: Security background, ISO 27001 knowledge
• Cryptography Specialist: Cryptography expertise, privacy-enhancing technologies
• Developers: Zero knowledge proof development, secure coding
• All: Understanding of privacy-by-design principles

Gap: ✅ Resolved. ISMS Owner holds CISSP, Security+, PenTest+, SecurityX. Privacy obligations covered through:

• Professional certifications (privacy included in CISSP domain)
• Code review (privacy considerations in PR feedback)
• Ad-hoc privacy discussions
• Reading ISMS documentation

Recommendation: Sole operator. formal privacy training programme not required. If team grows, implement privacy training:

Privacy Training Program (for future team members):

1. Onboarding (All new team members):

• Privacy fundamentals (GDPR, CCPA, privacy principles)
• Provii’s zero-PII architecture
• Privacy-by-design in practice
• Incident response (privacy breach procedures)

2. Annual Refresher (All team members):

• Regulatory updates
• New privacy controls
• Case studies (privacy incidents in industry)
• Quiz to verify understanding

3. Role-Specific (Engineers):

• Secure coding for privacy
• Cryptographic privacy techniques
• Privacy testing methodologies

4. Documentation:

• Attendance records
• Competence assessments

Evidence:

• Unified Control Matrix - Line 610 (UC-014: Privacy Awareness and Training - Planned)
• No current training materials exist

Status: 📋 Planned (Q1 2026)

Priority: High (Required for ISO 27701 certification)

7.3 Awareness

Requirement (7.3.1): Persons doing work under the organisation’s control shall be aware of the privacy policy and their role in the PIMS.

Maelstrom AI Implementation:

Current Awareness Mechanisms:

1. ISMS documentation (publicly accessible, team members expected to read)
2. Code review (privacy considerations in review feedback)
3. Architecture decisions (privacy-first approach communicated in design)
4. Open communication culture (privacy questions welcome)

Evidence:

• Public ISMS at the Trust Centre (/trust/security)
• Privacy Architecture Evidence - Privacy principles documented
• Development practices show privacy awareness in code

Status: ✅ Implemented (Informal)

Gap: No verification of awareness (no quizzes, acknowledgments, sign-offs). Recommendation: Add privacy policy acknowledgment to onboarding checklist.

7.4 Communication

Requirement (7.4.1): The organisation shall determine the need for internal and external communications relevant to the PIMS.

Maelstrom AI Implementation:

Internal Privacy Communications:

• Privacy Officer to Team: Privacy control updates, incident alerts
• ISMS Owner to Team: Privacy strategy, policy changes
• Engineers to Privacy Officer: Privacy questions, potential issues
• Channels: Signal (urgent), Email (routine), GitHub (code-related)

External Privacy Communications:

• Privacy Policy (drafted; pending publication at provii.app. P-005) - User-facing privacy notice
• ISMS Documentation (public) - Transparency for auditors, partners
• Security Advisories - Privacy-relevant vulnerabilities
• API Documentation - Privacy considerations for integrators

Evidence:

• Incident Response Policy - Communication procedures (incident-response.mdx)
• Business Continuity Plan - Communication templates (business-continuity.mdx)
• Supplier Management - Vendor communication (supplier-management.md)

Status: ✅ Implemented

Gap: No privacy-specific communication plan. Recommendation: Document privacy communication procedures in standalone privacy policy.

7.5 Documented Information

Requirement (7.5.1): The organisation’s PIMS shall include documented information required by ISO 27701 and deemed necessary for the effectiveness of the PIMS.

Maelstrom AI Implementation:

Privacy-Related Documented Information:

Total PIMS Documentation: 10+ core documents, 12 evidence documents, 1 compliance tracker

Evidence:

• All documents listed above exist in /trust/
• Version control via Git (immutable audit trail)
• Public accessibility (transparency commitment)

Status: ✅ Implemented

Strength: Maelstrom AI’s documentation exceeds ISO 27701 requirements by making all PIMS documentation public (except Restricted cryptographic keys). This provides unprecedented transparency.

Annex A: PII Controller Controls

ISO 27701 Annex A defines 83 additional controls for organisations acting as PII controllers. These controls extend ISO 27002 with privacy-specific requirements.

Maelstrom AI’s Controller Role: Maelstrom AI acts as a PII controller for:

1. IP addresses (retained 90 days, hashed with SHA-256, for abuse prevention)
2. Audit logs (challenge creation, proof verification events, retained 90 days)
3. Analytics (aggregated, no PII, retained 30 days)
4. Date of birth (ephemeral processing only. transmitted once during issuance for Pedersen commitment computation, processed in memory, immediately discarded; never stored, logged, or retained)

Maelstrom AI does NOT collect or retain:

• Names, addresses, emails, phone numbers (never collected)
• Government ID numbers (never collected)
• User account data (no accounts, wallet-based architecture)

This limited controller role means many Annex A controls are Not Applicable or significantly simplified.

A.7.2 Conditions for Collection and Processing

A.7.2.1 Identify and Document Purpose

ISO 27701 Requirement: The organisation acting as PII controller should identify and document the specific, explicit, and legitimate purpose(s) for which PII will be processed.

Maelstrom AI Implementation:

Purpose Identification:

Maelstrom AI processes PII for the following specific, explicit, and legitimate purposes:

1. Age Verification Service (Primary Purpose)

• Purpose. Verify that users meet age thresholds for age-restricted content/services
• Legal Basis. Legitimate interest (compliance with age verification laws), contract (with relying parties)
• PII Processed. None (zero knowledge proofs reveal only yes/no)
• Retention. Challenge state (5 minutes), verification result (not stored long-term)

2. Abuse Prevention (Operational Purpose)

• Purpose. Prevent API abuse, DDoS attacks, credential fraud
• Legal Basis. Legitimate interest (security, fraud prevention)
• PII Processed. IP addresses (classified as PII under GDPR)
• Retention. 90 days (audit logs)
• Evidence. /trust/security/data-retention.mdx - Lines 22-29

3. Security Audit Logging (Operational Purpose)

• Purpose. Security incident detection, compliance auditing
• Legal Basis. Legal obligation (security breach notification requirements)
• PII Processed. IP addresses, challenge IDs (pseudonymous), timestamps
• Retention. 90 days (audit logs)
• Evidence. Data Retention Policy - Lines 24-25

4. Service Analytics (Operational Purpose)

• Purpose. Service improvement, capacity planning, error detection
• Legal Basis. Legitimate interest (service optimisation)
• PII Processed. None (aggregated metrics only, no IP addresses in analytics)
• Retention. 90 days (Cloudflare Workers Logs in Grafana Loki)
• Evidence. Logging & Monitoring Evidence - monitoring section

Purpose Limitation Enforcement:

Provii’s architecture enforces purpose limitation:

• No re-purposing possible. Zero-PII architecture means no data to re-purpose
• Minimal data collection. Only IP addresses for abuse prevention, automatically deleted after 90 days
• No secondary uses. No marketing, profiling, tracking, or data sales
• Explicit documentation. All purposes documented in data retention policy

Evidence:

• /trust/compliance/evidence/privacy-controls/privacy-architecture-evidence.md - Lines 11-52 (privacy principles)
• /trust/security/data-retention.mdx - Purpose-specific retention periods
• Unified Control Matrix - Line 89 (UC-001: Purpose Limitation)

Status: ✅ Implemented

Strength: Provii’s purpose limitation is architectural. The system is designed so that it cannot process PII beyond stated purposes because it does not collect PII in the first place.

A.7.2.2 Determine Legal, Statutory and Regulatory Requirements

ISO 27701 Requirement: The organisation acting as PII controller should determine and document the relevant legal, statutory, and regulatory requirements related to the processing of PII.

Maelstrom AI Implementation:

Regulatory Requirements Identified:

Compliance Analysis Status:

• Unified Control Matrix: Maps to GDPR, CCPA, ISO 27001, SOC 2, NIST
• Individual compliance analyses: ✅ Completed. GDPR, CCPA, COPPA, Children’s Code
• Legal review: Needed before production launch

Legal Basis for Processing:

Under GDPR Article 6, Maelstrom AI relies on:

1. Legitimate Interest (Art. 6(1)(f)) - Abuse prevention, security
2. Contract (Art. 6(1)(b)) - Service provision to relying parties
3. Legal Obligation (Art. 6(1)(c)) - Age verification law compliance

Special Categories of Data: Maelstrom AI does NOT process special categories (Art. 9) or criminal conviction data (Art. 10).

Children’s Data: Age verification service may verify children <18, but NO PII is collected from children. Zero knowledge proofs reveal only binary age status, complying with heightened COPPA/Children’s Code protections.

Evidence:

• /trust/compliance/requirements/unified-control-matrix.md - Regulatory mappings throughout
• /trust/project tracker - Compliance roadmap
• Privacy Architecture Evidence - GDPR alignment discussion

Status: ✅ Largely Implemented

Completed:

• ✅ GDPR compliance statement. gdpr-compliance-statement
• ✅ CCPA compliance assessment. ccpa-compliance-statement
• ✅ COPPA safe harbor documentation. coppa-safe-harbor
• ✅ UK Children’s Code compliance. childrens-code-compliance
• ✅ GDPR Article 30 ROPA. ropa-records-of-processing
• ✅ Legal basis for each processing purpose documented in ROPA and GDPR statement

Remaining Gap:

1. Engage privacy counsel for formal legal compliance opinion (P-002 in Planned Work Register (maintained internally; available to auditors and enterprise customers on request))

Priority: High (Legal review required before production launch)

A.7.2.3 Determine and Fulfill Obligations to PII Principals

ISO 27701 Requirement: The organisation acting as PII controller should determine and fulfill obligations to PII principals arising from the processing of PII.

Maelstrom AI Implementation:

GDPR Data Subject Rights:

Implementation Details:

1. Right to Information (Privacy Notice):

• Requirement. Provide transparent information about processing at time of collection
• Maelstrom AI Approach:
• Privacy policy to be published at provii.app/privacy
• In-app privacy notice during first use of wallet
• Relying party disclosure requirements (via API terms)
• Content. Processing purposes, legal basis, retention periods, sub-processors
• Status. 📋 Planned (Q1 2026)

2. Right of Access:

• Requirement. Provide copy of PII upon request
• Maelstrom AI Approach. No PII stored = automated response: “No personal data about you is stored”
• Proof. Code audit confirms no PII fields in data models
• Status. ✅ N/A (simplified by design)

3. Right to Erasure:

• Requirement. Delete PII upon request (subject to exceptions)
• Maelstrom AI Approach:
• IP addresses auto-deleted after 90 days (configurable to delete sooner on request)
• Audit logs can be purged if legally permissible
• Zero-PII architecture means no long-term data to erase
• Status. ✅ Implemented (simplified by design)

4. Request Handling Process:

• Contact. security@maelstrom.au (privacy requests)
• Response Time. 30 days (GDPR requirement)
• Identity Verification. Email confirmation (low risk given minimal PII)
• Status. Documented in incident response procedures

Evidence:

• Privacy Architecture Evidence - Data subject rights analysis (Lines 280-316)
• Unified Control Matrix - Line 735 (UC-026: Privacy Obligations)
• Incident Response Policy - Privacy request handling (to be added)

Status: 🔄 Partially Implemented

Gap:

1. Privacy policy not yet published
2. Data subject request procedures not formally documented
3. No privacy request tracking system

Recommendation:

1. Publish privacy policy (Q1 2026)
2. Document data subject request procedures in incident response policy (Q1 2026)
3. Create privacy request template emails (Q1 2026)
4. Test request handling procedures (Q1 2026)

Priority: High (Required for GDPR compliance)

A.7.2.4 Determine Privacy Impact Assessment

ISO 27701 Requirement: The organisation acting as PII controller should determine whether a privacy impact assessment (PIA) is required by legislation or is otherwise advisable.

Maelstrom AI Implementation Status: 🔄 Partially Implemented

Current State:

Privacy Architecture Analysis Completed:

• privacy analysis in privacy-architecture-evidence.md
• Privacy-by-design principles verified
• Data flow analysis (minimal PII identified)
• Privacy risk assessment (integrated into risk register)

Formal DPIA Status: ✅ Completed. see Data Protection Impact Assessment

DPIA Requirement Assessment:

Under GDPR Article 35, DPIA is required when processing is “likely to result in high risk” to data subjects. High-risk indicators include:

1. ✅ Large-scale processing - Potentially global age verification service
2. ❌ Systematic monitoring - No tracking, profiling, or surveillance
3. ❌ Special category data - No sensitive data (race, health, religion, etc.)
4. ❌ Automated decision-making - No profiling or automated decisions with legal effects
5. ❌ Vulnerable individuals - Children may use service, but no PII persisted (DOB processed ephemerally during issuance only)

Conclusion: DPIA recommended but not strictly required under GDPR Art. 35(3) because:

• No systematic monitoring (zero knowledge proofs, no tracking)
• No special category data processing
• No automated decision-making with legal effects
• Children’s data: DOB processed ephemerally during issuance and immediately discarded, no PII persisted

However, DPIA is advisable as best practice and for ISO 27701 certification.

Proposed DPIA Scope:

1. Verifier API DPIA:

• Processing: IP address collection, challenge creation, proof verification
• Risks: IP address linkability, abuse detection profiling
• Mitigations: 90-day retention, no cross-site tracking, rate limiting
• Timeline: Q1 2026

2. Issuer API DPIA:

• Processing: Officer authentication, credential issuance
• Risks: Issuing officer identification, credential tracking
• Mitigations: Minimal issuer metadata, credential unlinkability (nullifiers)
• Timeline: Q1 2026

3. Cloudflare Sub-Processor DPIA:

• Processing: IP addresses via Cloudflare infrastructure
• Risks: US-based processing (Schrems II), government access
• Mitigations: Standard Contractual Clauses, minimal data collection
• Timeline: Q1 2026

DPIA Process:

1. Screening: Determine DPIA necessity (completed above)
2. Consultation: Involve ISMS Owner, Privacy Officer, legal counsel
3. Assessment: ICO DPIA template (or equivalent)
4. Documentation: Formal DPIA report with sign-off
5. Review: Annual reassessment or when processing changes

Evidence:

• Data Protection Impact Assessment - Formal DPIA (February 2026)
• Privacy Architecture Evidence - Supporting analysis
• Unified Control Matrix - UC-006: Privacy Impact Assessment
• Risk Register - Privacy risks identified

Status: ✅ Completed (February 2026)

Next Review: Annual reassessment or when processing activities change significantly.

A.7.2.5 Identify and Document Special Categories of PII

ISO 27701 Requirement: The organisation acting as PII controller should identify and document any special categories of PII being processed.

Maelstrom AI Implementation:

Special Categories Assessment:

Under GDPR Article 9, “special categories” of personal data include:

• Racial or ethnic origin
• Political opinions
• Religious or philosophical beliefs
• Trade union membership
• Genetic data
• Biometric data (for uniquely identifying a person)
• Health data
• Sex life or sexual orientation

Maelstrom AI Processing: NONE

Provii’s zero knowledge architecture does not process ANY special category data:

1. Age Verification Process:

• User proves age via cryptographic proof
• Proof reveals ONLY: “User is ≥ threshold” (yes/no)
• NO biometric data collected (no facial recognition, fingerprints)
• NO health data (birthdate is NOT revealed)
• NO other special categories

2. Credential Issuance (Issuer API):

• Government-issued ID may be presented to issuing officer for verification
• ID verification happens OFFLINE (in-person or via video call)
• NO ID data stored in Provii systems
• Issuing officer sees ID, but Provii platform does NOT

3. Operational Data:

• IP addresses: NOT special category
• Challenge IDs: Pseudonymous identifiers, NOT special category
• Audit logs: Timestamps, events, NOT special category

Government ID Documents (Important Distinction):

While government IDs may contain photos (potential biometric data) or other sensitive information:

• Provii platform NEVER receives, stores, or processes government IDs
• ID verification is performed by issuing officers (identity proofing providers)
• Provii receives only the cryptographic signature over a credential
• Credential contains NO PII, only mathematical commitments

Evidence:

• Privacy Architecture Evidence - Lines 53-79 (No PII Collection principle)
• Data Lifecycle Evidence - Lines 24-57 (Data NOT collected list)
• Cryptography Evidence - Zero knowledge proof structure (no PII in proofs)

Status: ✅ Implemented (N/A - No Special Categories Processed)

Strength: Provii’s architecture is designed so that processing special category data is not supported by the protocol. This is an architectural property, not merely a policy choice.

Compliance Simplification: By not processing special categories, Maelstrom AI avoids:

• GDPR Article 9(2) legal basis requirements (consent, legal claims, substantial public interest, etc.)
• Enhanced security requirements for special categories
• Additional DPIA requirements
• Stricter data transfer restrictions

A.7.2.6 Limit Processing According to Purpose

ISO 27701 Requirement: The organisation acting as PII controller should limit the processing of PII to what is adequate, relevant, and necessary for the purpose for which it is processed.

Maelstrom AI Implementation:

Data Minimization Principles:

Maelstrom AI implements data minimization at multiple levels:

1. Architectural Minimization (Zero knowledge Proofs):

• Traditional Approach. Collect DOB → Calculate age → Delete DOB (trust-based)
• Provii Approach. DOB transmitted once during issuance for Pedersen commitment computation, then immediately discarded → Cryptographic proof of age (cryptographically enforced; no DOB stored)
• Minimization. Designed so that collecting more data than necessary is not supported by the protocol

2. Operational Minimization (IP Addresses):

• Purpose. Abuse prevention, DDoS protection, fraud detection
• Collection. IP address only (no user-agent, no referrer, no cookies)
• Retention. 90 days (legally adequate for abuse investigation)
• Alternative Considered. No IP logging → Rejected due to abuse risk
• Justification. 30 days is minimum necessary for security incident investigation
• Evidence. /trust/security/data-retention.mdx - Lines 22-29

3. Analytics Minimization:

• Purpose. Service improvement, error detection
• Collection. Aggregated metrics only (no IP addresses in analytics)
• Data Points. Request counts, error rates, response times, geographic distribution (country-level)
• NO Collection. Individual user tracking, session tracking, cookies
• Evidence. Logging & Monitoring Evidence - Analytics section

4. Audit Log Minimization:

• Purpose. Security audit trail, compliance evidence
• Collection. Challenge ID (pseudonymous), event type, timestamp, IP address
• Retention. 90 days (adequate for incident investigation, ISO 27001 compliance)
• NO Collection. User identifiers, credential contents, personal data
• Evidence. Data Retention Policy - Lines 24-25

Purpose Limitation Enforcement:

Linkability Minimization:

Provii prevents cross-site tracking through:

1. Credential Nullifiers: Each proof includes unique nullifier, preventing correlation across sites
2. No Cookies: No HTTP cookies set (stateless API)
3. No Accounts: Wallet-based architecture, no user accounts
4. No Fingerprinting: No browser fingerprinting, device tracking
5. No Third-Party Tracking: No analytics pixels, social media widgets

Evidence:

• Privacy Architecture Evidence - Lines 120-164 (Data Minimization analysis)
• Unified Control Matrix - Line 635 (UC-018: Data Minimization)
• Cryptography Evidence - Nullifier implementation for unlinkability

Status: ✅ Implemented (Exemplary)

Strength: Maelstrom AI’s data minimisation is architecturally enforced, not policy-based. The system is designed so that it cannot collect excess data because the architecture does not support it.

Industry Comparison: Maelstrom AI’s approach through the Provii platform is designed to meet or exceed GDPR Article 5(1)(c) (data minimisation) and represents best-practice implementation of Privacy by Design.

A.7.2.7 Identify and Document Cross-Border Transfers

ISO 27701 Requirement: The organisation acting as PII controller should identify and document transfers of PII across jurisdictional borders, including the countries or international organisations to which PII is transferred.

Maelstrom AI Implementation:

Cross-Border Transfer Analysis:

1. Cloudflare Global Infrastructure:

• Service. Cloudflare Workers, KV, Durable Objects, Pages, Analytics
• Data Processed. IP addresses, challenge state, audit logs
• Geographic Scope. Global edge network (300+ PoPs worldwide)
• Data Location. User-controlled (traffic routed to nearest PoP)
• Transfer Mechanism:
• Standard Contractual Clauses (SCCs) with Cloudflare
• EU-US Data Privacy Framework (DPF) participant
• Cloudflare DPA in place
• Evidence:
• /trust/security/supplier-management.md - Lines 13-33 (Cloudflare relationship)
• Vendor Evidence - Sub-processor data flows

2. GitHub (Development Infrastructure):

• Service. Source code hosting, CI/CD, artifact storage
• Data Processed. Source code (public), CI/CD logs, build artifacts
• Data Location. United States (GitHub.com infrastructure)
• NO PII Transferred. All repositories public, no user data in code
• Transfer Mechanism. GitHub Data Protection Addendum
• Evidence. Vendor Evidence - Lines 78-106

3. npm Registry:

• Service. JavaScript package distribution (provii-agegate SDK)
• Data Processed. Package metadata only, no PII
• Data Location. United States
• Transfer Mechanism. N/A (no PII transferred)

Cross-Border Transfer Map:

GDPR Article 44-50 Compliance (International Transfers):

1. Adequacy Decisions (Art. 45):

• Cloudflare: EU-US Data Privacy Framework participant (adequacy for US transfers)
• GitHub: Standard Contractual Clauses (no adequacy decision for US)

2. Appropriate Safeguards (Art. 46):

• Standard Contractual Clauses with Cloudflare (EU Commission approved)
• Cloudflare DPA incorporates SCCs
• GitHub Data Protection Addendum (based on SCCs)

3. Schrems II Considerations:

• Risk. US government access to data (FISA 702, EO 12333)
• Mitigation. Minimal data collection (only IP addresses), short retention (90 days)
• Assessment. Low risk given:
• No sensitive data (IP addresses only)
• Cloudflare privacy commitments
• EU-US DPF participation

4. Onward Transfers:

• Cloudflare may engage sub-processors (listed in Cloudflare Sub-Processor List)
• Maelstrom AI’s DPA with Cloudflare includes sub-processor notification requirements
• No onward transfers to countries without adequacy decision or SCCs

Cross-Border Transfer Restrictions:

Maelstrom AI does NOT transfer PII to:

• China, Russia, or other high-risk jurisdictions
• Countries without GDPR adequacy decisions or SCCs
• Third parties without DPAs

Evidence:

• Supplier Management - Cloudflare DPA reference
• Vendor Evidence - Sub-processor analysis
• Unified Control Matrix - Line 328 (UC-009: Cross-Border Transfers)

Status: ✅ Implemented

Gap: Transfer Impact Assessment (TIA) not conducted for Cloudflare US transfers. Recommendation: Complete TIA under Schrems II requirements (assess US government access risks, supplementary measures).

Priority: Medium (Should complete before EU user onboarding)

A.7.2.8 Privacy-Preserving Technologies

ISO 27701 Requirement: The organisation acting as PII controller should evaluate and, where appropriate, implement privacy-enhancing technologies (PETs) to reduce privacy risks.

Maelstrom AI Implementation:

Privacy-Enhancing Technologies Deployed:

1. Zero knowledge Proofs (zkSNARKs):

• Technology. Groth16 zkSNARKs on BLS12-381 elliptic curve
• Purpose. Prove age eligibility without revealing date of birth
• Implementation. Bellman library (Rust), WASM compilation for browser
• Privacy Guarantee. Designed to be computationally infeasible to extract DOB from proof
• Evidence:
• provii-crypto/crypto-verifier/src/lib.rs - Proof verification
• Cryptography Evidence - Complete zkSNARK analysis
• Age Verification Flow Evidence - UC-087 (Proof Generation)

2. Credential Nullifiers (Unlinkability):

• Technology. Pedersen commitments for nullifier generation
• Purpose. Prevent credential reuse while maintaining privacy
• Privacy Property. Each proof has a unique nullifier, designed to prevent cross-site correlation
• Implementation. Nullifier derived from credential signature + challenge binding
• Evidence:
• Age Verification Flow Evidence - UC-089 (Nullifier Handling)
• Cryptography Evidence - Nullifier cryptography

3. Pseudonymization (Challenge IDs):

• Technology. UUID v4 (cryptographically random)
• Purpose. Session tracking without user identification
• Privacy Guarantee. No linkage to user identity
• Implementation. Challenge IDs generated per verification session
• Evidence. Cryptography Evidence - Challenge generation

4. Encryption at Rest:

• Technology. AES-256-GCM (Cloudflare KV, secrets)
• Purpose. Protect data confidentiality
• Implementation. Cloudflare infrastructure-level encryption
• Evidence. Infrastructure Evidence - Encryption controls

5. Encryption in Transit:

• Technology. TLS 1.3 (Cloudflare Workers)
• Purpose. Prevent interception of verification requests
• Implementation. Mandatory TLS 1.3, HTTP/3 support
• Evidence. API Security Evidence - TLS enforcement

6. Secure Multi-Party Computation:

• Technology. Threshold cryptography for signing keys
• Purpose. Distribute issuer signing key across multiple parties
• Status. Not implemented. may be evaluated for high-value key management if operational scale warrants
• Evidence. Cryptography Evidence - Future enhancements section

Privacy Impact of PETs:

PET Evaluation Process:

Maelstrom AI has evaluated emerging PETs and determined they are not applicable to current operations:

1. Homomorphic Encryption: Not applicable. Maelstrom AI does not perform analytics on personal data
2. Differential Privacy: Not applicable. no analytics processing of personal data
3. Secure Enclaves (SGX, TrustZone): Not applicable. Cloudflare Workers serverless architecture does not support hardware enclaves

Evidence:

• Privacy Architecture Evidence - Lines 165-200 (Privacy-Enhancing Technologies)
• Cryptography Evidence - Complete PET inventory
• Unified Control Matrix - Line 404 (UC-011: Privacy-Preserving Technologies)

Status: ✅ Implemented (Exemplary)

Strength: Provii’s use of zero knowledge proofs represents a strong approach to privacy-enhancing technologies in identity verification. The approach is designed to exceed ISO 27701 recommendations and aligns with NIST Privacy Framework “Predictive-P” (Privacy-Protective).

Industry Recognition: Zero knowledge age verification is a novel application of zkSNARKs that could set a new standard for privacy-preserving identity proofing.

A.7.3 Obligations to PII Principals

ISO 27701 Annex A Section 7.3 defines controls for obligations that PII controllers owe to data subjects (PII principals). These controls implement transparency, user rights, and accountability.

A.7.3.1 Provide Privacy Notice to PII Principals

ISO 27701 Requirement: The organisation should provide PII principals with clear and easily accessible information about the processing of their PII.

Maelstrom AI Implementation Status: 📋 Planned

Current State:

• Technical documentation (ISMS) publicly available at the Trust Centre (/trust/security)
• Privacy principles documented in privacy-architecture-evidence.md
• No user-facing privacy policy published yet

Gap: No published privacy notice/policy accessible to end users.

Proposed Privacy Notice Structure:

1. Identity and Contact Details:

• Data Controller: Maelstrom AI Pty Ltd ATF Maelstrom AI Holding Trust (ABN 61 633 823 792)
• Contact: privacy@maelstrom.au
• Data Protection Officer: (if appointed)

2. Purposes of Processing:

• Age verification (primary purpose)
• Abuse prevention (IP addresses, 90-day retention)
• Security audit logging (90-day retention)
• Service analytics (aggregated, no PII)

3. Legal Basis:

• Legitimate interest (age verification, abuse prevention)
• Contract (service provision to relying parties)
• Legal obligation (age verification compliance)

4. Categories of PII Processed:

• IP addresses (abuse prevention)
• Challenge IDs (pseudonymous identifiers)
• Timestamps (audit logs)
• NOT processed. Names, emails, addresses, phone numbers, dates of birth

5. Recipients of PII:

• Cloudflare (infrastructure provider, DPA in place)
• Relying parties (receive only yes/no age verification result)
• No other third parties

6. Retention Periods:

• IP addresses: 90 days
• Audit logs: 90 days
• Challenge state: 5 minutes
• Verification proofs: Not stored

7. Data Subject Rights:

• Right to access (simplified: no PII stored)
• Right to erasure (IP addresses deleted on request or after 90 days)
• Right to object (stop using service)
• Right to complain to supervisory authority

8. Automated Decision-Making:

• No profiling or automated decisions with legal effects

9. Cross-Border Transfers:

• Cloudflare global infrastructure (SCCs in place)
• EU-US Data Privacy Framework

10. Source of PII:

• Directly from user (IP address from connection)
• Not collected from third parties

Privacy Notice Accessibility:

• Location. provii.app/privacy
• Format. Web page (HTML), PDF download
• Language. English (primary), translations as needed
• Readability. Plain language, <10th grade reading level
• Last Updated. Prominently displayed
• Version Control. Git history provides audit trail

Evidence:

• Unified Control Matrix - Line 142 (UC-002: Privacy Notice - Planned)
• Privacy Architecture Evidence - Contains elements for privacy notice
• Data Retention Policy - Retention periods documented

Status: 🔄 Partially Implemented

Completed: Privacy policy drafted and available at /legal/privacy-policy within the ISMS site.

Remaining Gap: Policy not yet published to provii.app (tracked as P-005 in Planned Work Register (maintained internally; available to auditors and enterprise customers on request)).

Recommendation:

1. ✅ Draft privacy notice based on proposed structure above. done
2. Legal review by privacy counsel (Q1 2026). tracked as P-002
3. Publish at provii.app/privacy (Q1 2026). tracked as P-005
4. Add link to wallet app UI (Q1 2026)
5. Require relying parties to link to privacy notice (API terms)

Priority: High (Required for GDPR compliance, ISO 27701 certification)

A.7.3.2 Obtain and Record Consent

ISO 27701 Requirement: Where consent is the legal basis for processing, the organisation should obtain and record consent from PII principals.

Maelstrom AI Implementation:

Consent Requirement Analysis:

GDPR Article 6(1) provides six legal bases for processing: (a) Consent - Freely given, specific, informed, unambiguous (b) Contract - Necessary for contract performance (c) Legal obligation - Compliance with legal requirement (d) Vital interests - Protect life of data subject (e) Public task - Performance of public interest task (f) Legitimate interests - Legitimate interests not overridden by data subject rights

Maelstrom AI’s Legal Bases (NOT Consent):

Consent NOT Required for Maelstrom AI’s processing because:

1. Legitimate Interest provides adequate legal basis (GDPR Art. 6(1)(f))
2. Legitimate Interest Assessment (LIA) conducted (in privacy architecture evidence):

• Purpose. Age verification, abuse prevention (legitimate)
• Necessity. Minimal data collection (IP addresses only)
• Balancing Test. User privacy rights NOT overridden (90-day retention, no sensitive data)

3. Relying Party Contract: Service provision to relying parties (GDPR Art. 6(1)(b))

Consent IS NOT OBTAINED because:

• Consent is not the appropriate legal basis (legitimate interest is stronger)
• Consent would be burdensome (extra friction in age verification flow)
• Consent could be withdrawn, interrupting service (legitimate interest is more stable)

Important Distinction:

Maelstrom AI does NOT obtain consent for:

• Processing IP addresses for abuse prevention
• Creating audit logs for security
• Providing age verification service

Relying parties DO obtain consent for:

• Requesting age verification from users
• This is relying party’s responsibility, not Maelstrom AI’s
• Maelstrom AI provides technical infrastructure only

Evidence:

• Privacy Architecture Evidence - Legal basis analysis (Legitimate Interest Assessment)
• Unified Control Matrix - Line 171 (UC-003: Consent Management - N/A for Maelstrom AI)
• GDPR compliance mapping (to be formalized)

Status: ✅ N/A (Consent not required for Maelstrom AI’s processing)

Compliance Note: This control is Not Applicable to Maelstrom AI because consent is not the legal basis for processing. ISO 27701 A.7.3.2 applies “where consent is required,” which is not the case for Maelstrom AI’s operational data processing.

If Consent Were Required (Hypothetical):

• Consent mechanism: Checkbox in wallet app (clear, affirmative action)
• Consent recording: Store consent timestamp, version, user pseudonym
• Withdrawal: “Revoke Consent” button in wallet settings
• Granularity: Separate consent for each processing purpose
• Evidence: Consent logs in audit trail

Priority: N/A (Legitimate interest is appropriate legal basis)

A.7.3.3 Provide Mechanism to Modify or Withdraw Consent

ISO 27701 Requirement: Where consent is the legal basis for processing, the organisation should provide PII principals with an easy means to withdraw or modify consent.

Maelstrom AI Implementation:

Status: ✅ N/A (Consent not the legal basis for processing)

Rationale: As documented in A.7.3.2 above, Maelstrom AI relies on Legitimate Interest (GDPR Art. 6(1)(f)) and Contract (Art. 6(1)(b)) as legal bases, not consent.

Equivalent Right - Right to Object (GDPR Art. 21):

While Maelstrom AI doesn’t use consent, users have equivalent rights:

1. Right to Object to Processing:

• Implementation. User can stop using Provii wallet (uninstall app)
• Effect. No further data processing (no account to delete)
• Complexity. Trivial (just stop using service)

2. IP Address Deletion Request:

• Implementation. Contact privacy@maelstrom.au to request IP address deletion
• Processing Time. <7 days (manual deletion from logs)
• Effect. IP address removed before 90-day automatic deletion
• Evidence. To be documented in privacy policy

3. Service Opt-Out:

• Implementation. Relying parties must offer alternative age verification methods
• This is NOT Maelstrom AI’s responsibility (relying party’s obligation)
• Maelstrom AI provides. Technical infrastructure only

If Consent Were Required (Hypothetical Design):

Consent Withdrawal Mechanism:

1. Wallet App UI:

• Settings → Privacy → Consent Management
• Toggle switches for each consent purpose
• “Withdraw All Consent” button (clear, prominent)

2. Processing:

• Immediate effect (consent withdrawal logged)
• Data deletion within 30 days (or sooner if required)
• Consent withdrawal communicated to relying parties (if applicable)

3. Consequences Disclosure:

• “Withdrawing consent will prevent age verification”
• Clear explanation of service impact

Evidence:

• Unified Control Matrix - Line 199 (UC-004: Consent Modification - N/A)
• Privacy Architecture Evidence - Right to object analysis

Status: ✅ N/A (Consent not used)

Compliance Note: ISO 27701 A.7.3.3 applies “where consent is the legal basis.” Since Maelstrom AI does not use consent, this control is not applicable. However, Maelstrom AI provides equivalent user control through the right to object (stop using service).

A.7.3.4 Provide Access to PII

ISO 27701 Requirement: The organisation should provide PII principals with access to their PII and related processing information upon request.

Maelstrom AI Implementation:

Data Subject Access Request (DSAR) Process:

GDPR Article 15 grants data subjects the right to:

1. Confirmation of whether PII is being processed
2. Access to the PII being processed
3. Information about processing (purposes, categories, recipients, retention, etc.)
4. Copy of the PII (first copy free, subsequent copies at reasonable fee)

Maelstrom AI DSAR Implementation:

Step 1: Request Submission:

• Contact. privacy@maelstrom.au
• Identification. Email address (requestor must prove identity)
• Request Format. Email to privacy@maelstrom.au
• Evidence. Email records retained per data retention policy

Step 2: Identity Verification:

• Method. Email confirmation (low-risk verification given minimal PII)
• Risk Assessment. Low risk (only IP addresses stored)
• Alternative. For high-value requests, request government ID (ironic for age verification service)

Step 3: Data Retrieval:

• IP Addresses. Query Cloudflare logs for requestor’s IP (if within 90-day window)
• Audit Logs. Query KV for challenge IDs associated with requestor (if identifiable)
• Challenge State. Expired (5-minute TTL), not available for retrieval
• Verification Proofs. NOT stored, cannot be retrieved

Step 4: Response Compilation:

• Format. JSON or human-readable summary
• Content:

  {
    "data_subject": "requester@example.com",
    "request_date": "2025-01-15",
    "ip_addresses": [
      {
        "ip": "192.0.2.1",
        "first_seen": "2025-01-10 14:23:15 UTC",
        "last_seen": "2025-01-12 09:45:32 UTC",
        "retention_until": "2025-02-09 14:23:15 UTC"
      }
    ],
    "challenge_ids": [
      {
        "challenge_id": "550e8400-e29b-41d4-a716-446655440000",
        "created": "2025-01-12 09:45:32 UTC",
        "status": "Verified",
        "relying_party": "example.com"
      }
    ],
    "processing_purposes": ["Abuse prevention", "Security audit logging"],
    "legal_basis": "Legitimate interest (GDPR Art. 6(1)(f))",
    "retention_periods": {
      "IP addresses": "90 days",
      "Audit logs": "90 days"
    },
    "recipients": ["Cloudflare (infrastructure provider)"],
    "your_rights": ["Right to erasure", "Right to object", "Right to complain to supervisory authority"]
  }

Step 5: Response Delivery:

• Timeline. Within 30 days (GDPR requirement), target <7 days
• Delivery Method. Email (encrypted if requested)
• Fee. Free (first request), reasonable fee for excessive requests
• Evidence. DSAR log entry (tracking all requests)

Simplified Access for Zero-PII Architecture:

For most users, the response is simple:

“Maelstrom AI does not store any personally identifiable information about you. We do not collect your name, email, address, phone number, or date of birth. The only data associated with your IP address is temporary logs for abuse prevention, which are automatically deleted after 90 days. We found the following IP addresses associated with your request: [list]. No other personal data is stored.”

Evidence:

• Privacy Architecture Evidence - Lines 280-316 (Data subject rights analysis)
• Unified Control Matrix - Line 226 (UC-005: Data Subject Rights - Partially Implemented)
• Data Lifecycle Evidence - Confirms minimal PII storage

Status: 🔄 Partially Implemented

Current Implementation:

• Ability to query IP addresses from Cloudflare logs (manual process)
• Ability to query audit logs from KV (manual process)
• No automated DSAR system

Gap:

1. No DSAR request form or email template
2. No DSAR tracking system (spreadsheet or ticketing system)
3. No identity verification procedure documented
4. No DSAR response timeline monitoring

Recommendation:

1. Document DSAR procedure in privacy policy
2. Implement DSAR tracking spreadsheet
3. Create DSAR response templates (access, erasure, portability)
4. Test DSAR procedure with mock request

Priority: Medium (Email-based process via privacy@maelstrom.au is operational; documentation improvements needed)

A.7.3.5 Provide Data Portability

ISO 27701 Requirement: The organisation should provide PII principals with the ability to receive their PII in a structured, commonly used, and machine-readable format (where applicable).

Maelstrom AI Implementation:

Data Portability Requirement (GDPR Article 20):

Data portability applies when:

1. Processing is based on consent (Art. 6(1)(a)) or contract (Art. 6(1)(b)), AND
2. Processing is carried out by automated means

Maelstrom AI Analysis:

Conclusion: Data portability technically applies but is trivially simple due to minimal PII storage.

Data Portability Implementation:

Portable Data Available:

1. IP Addresses: List of IP addresses associated with user (if identifiable)
2. Challenge IDs: List of verification sessions (pseudonymous)
3. Audit Events: Verification attempts, timestamps

Non-Portable Data (Not User’s Personal Data):

• Cryptographic proofs (mathematical objects, not PII)
• Issuer public keys (public data, not personal)
• System configuration (organisational data, not personal)

Portability Format (JSON):

{
  "data_export": {
    "format": "JSON",
    "specification": "Provii Data Portability v1.0",
    "export_date": "2025-01-15T14:30:00Z",
    "data_subject_id": "requester@example.com",
    "ip_addresses": [
      {
        "ip": "192.0.2.1",
        "first_seen": "2025-01-10T14:23:15Z",
        "last_seen": "2025-01-12T09:45:32Z",
        "geographic_region": "EU"
      }
    ],
    "verification_sessions": [
      {
        "challenge_id": "550e8400-e29b-41d4-a716-446655440000",
        "timestamp": "2025-01-12T09:45:32Z",
        "relying_party_origin": "https://example.com",
        "age_threshold": 18,
        "verification_result": "Approved",
        "issuer_fingerprint": "blake2s:ab12cd34..."
      }
    ],
    "retention_info": {
      "ip_addresses_deleted_after": "90 days",
      "audit_logs_deleted_after": "90 days"
    }
  }
}

Portability Request Process:

1. User requests data export via privacy@maelstrom.au
2. Identity verification (same as DSAR process)
3. Data retrieval from Cloudflare logs and KV
4. JSON generation (automated script, to be developed)
5. Delivery via email (encrypted) or secure download link

“Right to Transmit” to Another Controller:

• GDPR Article 20(2). Right to have data transmitted directly to another controller
• Maelstrom AI Implementation. Not applicable (no other age verification providers use compatible data format)
• Justification. Maelstrom AI’s data (IP addresses, challenge IDs) is not useful to other controllers

Evidence:

• Unified Control Matrix - Line 2551 (UC-050: Data Portability - Simplified by design)
• Privacy Architecture Evidence - Data portability analysis

Status: 🔄 Partially Implemented

Current Implementation:

• Ability to export data manually (JSON format)
• No automated portability request system

Gap:

1. No portability request form
2. No automated JSON export script
3. Data portability not mentioned in privacy policy (to be published)

Recommendation:

1. Document data portability in privacy policy (Q1 2026)
2. Create JSON export script (Q1 2026)
3. Reuse DSAR request form for portability requests (Q1 2026)
4. Test portability with mock request (Q1 2026)

Priority: Medium (Required for GDPR compliance, but simplified by minimal data)

A.7.3.6 Correct or Delete PII

ISO 27701 Requirement: The organisation should provide PII principals with the ability to correct inaccurate or incomplete PII and to delete PII where appropriate.

Maelstrom AI Implementation:

Right to Rectification (GDPR Article 16):

Requirement: Data subjects can request correction of inaccurate personal data.

Maelstrom AI Analysis:

Conclusion: Rectification is Not Applicable to Maelstrom AI’s data because:

1. IP addresses are factual (cannot be “inaccurate”)
2. Challenge IDs are random (no accuracy concept)
3. Timestamps are audit trail (cannot be modified without compromising integrity)
4. Verification results are cryptographically proven (cannot be incorrect)

Right to Erasure (GDPR Article 17):

Requirement: Data subjects can request deletion of personal data in certain circumstances: (a) No longer necessary for the original purpose (b) Consent withdrawn (if consent was the legal basis) (c) Objection to processing (if legitimate interest basis) (d) Unlawfully processed (e) Legal obligation to delete (f) Data collected from children (<16) without parental consent

Maelstrom AI Erasure Implementation:

Automatic Erasure:

• IP addresses: Automatically deleted after 90 days (data retention policy)
• Challenge state: Automatically expires after 5 minutes (ephemeral storage)
• Audit logs: Automatically deleted after 90 days

Manual Erasure Upon Request:

• Process. User emails privacy@maelstrom.au requesting erasure
• Verification. Email confirmation (low-risk verification)
• Scope. Delete IP addresses and audit logs associated with user
• Timeline. Within 7 days of request (faster than 90-day automatic deletion)
• Exceptions:
• Active security investigation (retain until investigation complete)
• Legal hold (retain if litigation pending)
• Audit trail integrity (may pseudonymize instead of delete)

Erasure Request Process:

1. Request Submission:

• Email: privacy@maelstrom.au
• Subject: “Right to Erasure Request”
• Body: “Please delete all personal data associated with my IP address [optional: specify IP]”

2. Verification:

• Email confirmation link
• If IP not specified, identify from sending IP address

3. Deletion Execution:

   # Cloudflare Workers KV deletion
   cf-kv delete --namespace AUDIT_LOGS --key "ip:192.0.2.1"
   
   # Log purge (manual query to Cloudflare Logpush)
   # NOTE: Cloudflare logs are immutable, but excluded from exports after deletion request

4. Confirmation:

• Email notification: “Your personal data has been deleted”
• Timeframe: <7 days from request

Exceptions to Erasure:

Under GDPR Article 17(3), erasure does NOT apply when:

• Legal Obligation. Retention required by law (e.g., financial records)
• Public Interest. Archiving, research, statistics
• Legal Claims. Data needed for legal defence

Maelstrom AI Exceptions:

• Active Abuse Investigation. If IP address under investigation for fraud, retain until investigation complete (document in incident log)
• Legal Hold. If litigation pending, retain relevant data (rare)
• Compliance with NIS2. Security logs may be required for regulatory reporting (90-day retention justified)

Evidence:

• Data Retention Policy - Automatic deletion timelines
• Unified Control Matrix - Line 660 (UC-021: Right to Rectification), Line 2759 (UC-022: Right to Erasure)
• Privacy Architecture Evidence - User rights analysis

Status: ✅ Implemented (Automatic), 📋 Planned (Manual Deletion Process)

Current Implementation:

• Automatic deletion after 90 days (implemented)
• Manual deletion capability (technical process exists, not documented)

Gap:

1. Manual erasure request procedure not documented
2. Erasure request form not created
3. Erasure exceptions not formally defined
4. Erasure tracking log not implemented

Recommendation:

1. Document erasure request procedure in privacy policy (Q1 2026)
2. Create erasure request email template (Q1 2026)
3. Define erasure exceptions policy (Q1 2026)
4. Implement erasure request tracking log (Q1 2026)
5. Test manual erasure process (Q1 2026)

Priority: High (Required for GDPR compliance)

A.7.4 Privacy by Design and Privacy by Default

ISO 27701 Annex A Section 7.4 defines controls for embedding privacy into the design and default settings of systems and processes. These controls implement the GDPR Article 25 principle of data protection by design and by default.

A.7.4.1 Limit Collection

ISO 27701 Requirement: The organisation should limit the collection of PII to what is adequate, relevant, and necessary in relation to the identified purpose(s).

Maelstrom AI Implementation:

Collection Limitation by Design:

Provii’s zero knowledge architecture enforces collection limitation at the protocol level. The system is designed so that collecting PII beyond what is strictly required is not supported.

PII Collection Inventory:

Architectural Enforcement:

1. Issuance Flow: DOB is transmitted to provii-issuer for Pedersen commitment computation on the Jubjub curve. The DOB is processed in memory only, used to compute the commitment, and immediately discarded. It is never written to KV, logs, or any persistent storage.
2. Verification Flow: No PII is transmitted. The user presents a Groth16 zero knowledge proof (BLS12-381) that reveals only a binary yes/no answer to the age threshold query.
3. API Design: provii-verifier (including hosted mode) accepts only cryptographic proof payloads. There are no API fields for names, emails, or other PII.
4. Rate Limiting: shared-rate-limit operates on hashed IP addresses, not raw IPs.

Evidence:

• Privacy Architecture Evidence - Lines 11-52 (data minimisation principles)
• Data Retention Policy - Complete inventory of collected data
• provii-verifier source code - Proof verification endpoint accepts only cryptographic inputs
• provii-issuer source code - DOB ephemeral processing with no persistence

Status: ✅ Implemented

Strength: Collection limitation is enforced by system architecture, not policy. The API interfaces do not accept traditional PII fields during verification.

A.7.4.2 Limit Processing

ISO 27701 Requirement: The organisation should limit the processing of PII to that which is adequate, relevant, and necessary for the identified purposes.

Maelstrom AI Implementation:

Processing Limitation by Purpose:

Processing Restrictions Enforced:

1. No Profiling: No user profiles are created. Each verification is stateless and independent.
2. No Cross-Referencing: Challenge IDs cannot be linked across sessions (random UUIDs with 5-minute TTL).
3. No Secondary Use: Verification proofs are validated and discarded. They are not stored for analytics, training, or any secondary purpose.
4. No Sharing: Verification results (boolean) are returned to the relying party. No PII is shared.

Evidence:

• Privacy Architecture Evidence - Processing limitation analysis
• Data Retention Policy - Purpose-specific processing rules
• Unified Control Matrix - UC-001 (Purpose Limitation)

Status: ✅ Implemented

Strength: Processing limitation is enforced by the cryptographic protocol design. The Groth16 proof system is designed so that it reveals no information beyond the age threshold comparison result.

A.7.4.3 Accuracy and Quality

ISO 27701 Requirement: The organisation should ensure that PII processed is accurate, complete, up-to-date, adequate, and relevant for the purpose of processing.

Maelstrom AI Implementation:

Accuracy by Design:

Issuer Trust Model:

During credential issuance, the accuracy of the DOB depends on the issuer’s identity proofing process. Maelstrom AI does not independently verify the DOB against government records. The issuer signs an Ed25519 attestation confirming they have verified the individual’s identity and date of birth. Maelstrom AI holds each issuer’s public key in KV and validates the attestation signature before computing the Pedersen commitment.

Rectification:

If a credential was issued with an incorrect DOB, the user must obtain a new credential from the issuer. The old Pedersen commitment becomes orphaned (no linkage to the user exists in Maelstrom AI’s systems).

Evidence:

• Cryptography Evidence - Groth16 verification correctness
• Issuer API documentation - Attestation validation flow
• Privacy Architecture Evidence - Data accuracy analysis

Status: ✅ Implemented

A.7.4.4 PII Minimisation Objectives

ISO 27701 Requirement: The organisation should define and document data minimisation objectives and the mechanisms used to meet those objectives.

Maelstrom AI Implementation:

Minimisation Objectives:

1. Zero PII at Verification: No personal data is transmitted or processed during age verification. Only a zero knowledge cryptographic proof is presented.
2. Ephemeral Processing at Issuance: DOB is processed in memory for Pedersen commitment computation and immediately discarded. No persistent storage of DOB occurs.
3. Pseudonymised Operational Data: IP addresses are hashed (SHA-256) before storage. Raw IP addresses are not retained in application-level logs.
4. Minimal Retention: IP addresses and audit logs are automatically deleted after 90 days. Challenge state expires after 5 minutes.
5. No Accounts: Users do not create accounts. There is no user database, no email collection, no password storage.

Mechanisms Enforcing Minimisation:

Evidence:

• Privacy Architecture Evidence - Minimisation objectives (Lines 11-52)
• Data Retention Policy - TTL configuration for all data types
• Cryptography Evidence - Groth16 and Pedersen commitment properties

Status: ✅ Implemented

Strength: Maelstrom AI’s minimisation objectives are not aspirational targets; they are enforced by the cryptographic protocol design. The system is designed so that it cannot collect more data than the minimum because the protocol does not transmit it.

A.7.4.5 PII De-identification and Deletion at End of Processing

ISO 27701 Requirement: The organisation should either delete PII or render it in a form that does not permit identification of PII principals once the original purpose has been fulfilled.

Maelstrom AI Implementation:

De-identification and Deletion by Data Type:

De-identification Techniques Applied:

1. IP Address Hashing: SHA-256 one-way hashing. The hash cannot be reversed to recover the original IP address.
2. Pseudonymous Identifiers: Challenge IDs are random UUIDs with no linkage to user identity.
3. Aggregation: Analytics use aggregated counts only. No individual-level data in analytics.

Deletion Verification:

1. Cloudflare KV TTLs are enforced by the platform. Once a TTL expires, the key-value pair is permanently deleted.
2. No backup or replication of expired data exists.
3. Manual deletion capability exists for erasure requests (privacy@maelstrom.au).

Evidence:

• Data Retention Policy - TTL configuration and deletion schedules
• Privacy Architecture Evidence - De-identification techniques
• Data Lifecycle Evidence - End-of-life data handling

Status: ✅ Implemented

A.7.4.6 Temporary Files

ISO 27701 Requirement: The organisation should ensure that temporary files created during the processing of PII are disposed of within a specified, documented time period.

Maelstrom AI Implementation:

Temporary File Analysis:

Maelstrom AI’s architecture is serverless (Cloudflare Workers). Workers execute in V8 isolates with no filesystem access. This means:

1. No temporary files are created on disk. Workers have no writable filesystem.
2. In-memory processing only. All data processing occurs in memory within the V8 isolate. When the isolate terminates, all in-memory data is destroyed.
3. No /tmp directory. Unlike traditional server environments, Cloudflare Workers do not have access to a temporary directory.

Ephemeral State in KV:

The closest equivalent to “temporary files” in Maelstrom AI’s architecture is ephemeral state stored in Cloudflare KV:

All ephemeral state has explicit TTLs. No manual cleanup is required.

Wallet Mobile Application:

The Provii mobile wallet (client) application (iOS/Android) stores:

• Credential data in platform secure storage (iOS Keychain / Android Keystore)
• No temporary files for PII processing
• Proof generation occurs in memory (provii-mobile-sdk, compiled to native via provii-crypto)

Evidence:

• Cloudflare Workers documentation - V8 isolate model (no filesystem)
• Data Retention Policy - TTL configuration
• provii-mobile source code - Secure storage implementation

Status: ✅ Implemented

Strength: The serverless architecture substantially reduces temporary file risk. There is no writable filesystem to leave residual data on.

A.7.4.7 Retention

ISO 27701 Requirement: The organisation should not retain PII for longer than necessary for the identified purposes.

Maelstrom AI Implementation:

Retention Schedule:

Retention Justification:

1. IP addresses and audit logs are retained for 90 days. This period balances abuse prevention needs with data minimisation, allowing investigation of abuse patterns while limiting exposure. Critical security events (such as detected attacks, replay attempts, and IP blocks) are retained for up to 365 days to support security investigation.
2. 5-minute TTL for challenge state matches the verification flow timeout. A challenge that is not completed within 5 minutes is abandoned.
3. Zero retention for DOB and verification proofs reflects the core privacy-by-design principle: data that is not stored cannot be breached.

Retention Review:

Retention periods are reviewed as part of the annual ISMS review cycle. Any change to retention periods requires update to the data retention policy and this compliance document.

Evidence:

• /trust/security/data-retention.mdx - Authoritative retention schedule
• Unified Control Matrix - UC-023 (Data Retention)
• Privacy Architecture Evidence - Retention justification

Status: ✅ Implemented

A.7.4.8 Disposal

ISO 27701 Requirement: The organisation should have documented policies and procedures for the disposal of PII and should securely dispose of PII when no longer required.

Maelstrom AI Implementation:

Disposal Mechanisms:

Disposal of Infrastructure:

Maelstrom AI uses Cloudflare’s serverless infrastructure exclusively. There are no physical servers, hard drives, or storage media to dispose of. Cloudflare’s SOC 2 Type II report covers secure media disposal for their infrastructure.

Disposal of Credentials (User-Side):

Users can delete their age credential from the Provii mobile wallet app at any time. Credential deletion removes the Pedersen commitment opening values from the device’s secure storage (iOS Keychain / Android Keystore). Once deleted, no copy of the credential exists on Maelstrom AI’s servers.

Evidence:

• Data Retention Policy - Disposal procedures
• Cloudflare SOC 2 Type II report - Media disposal controls
• provii-mobile source code - Credential deletion implementation

Status: ✅ Implemented

A.7.4.9 PII Transmission Controls

ISO 27701 Requirement: The organisation should implement controls to protect PII transmitted over data communication networks.

Maelstrom AI Implementation:

Transmission Security:

Transmission Controls:

1. TLS 1.3 Everywhere: All Cloudflare Workers enforce TLS 1.3 with no fallback to older versions. HTTP requests are redirected to HTTPS.
2. No PII in URLs: No PII is included in URL parameters or query strings. All sensitive data is transmitted in request bodies.
3. No PII in Verification: During the verification flow, zero PII crosses the network. The proof is a mathematical object.
4. Minimal PII in Issuance: During issuance, DOB is transmitted once from the issuer backend to provii-issuer over TLS 1.3. The DOB is contained within a signed Ed25519 attestation.
5. TLS Enforcement: provii-mobile enforces TLS via App Transport Security (iOS) and network security config (Android). All API endpoints are Cloudflare-terminated TLS 1.3.
6. CORS Policy: provii-verifier enforces origin-based CORS restrictions. Only registered relying party origins can call the API.

Post-Quantum Readiness:

Provii’s cryptographic roadmap includes ML-DSA (post-quantum digital signatures) for future-proofing transmission integrity. Current TLS 1.3 provides adequate protection against classical attacks.

Evidence:

• Cloudflare Workers TLS configuration - TLS 1.3 enforcement
• provii-verifier source code - CORS and origin validation
• provii-mobile source code - TLS enforcement and transport security
• Cryptography Evidence - Transmission security analysis

Status: ✅ Implemented

A.7.5 PII Sharing, Transfer, and Disclosure

ISO 27701 Annex A Section 7.5 defines controls for the sharing, transfer, and disclosure of PII to third parties and across jurisdictions. These controls address GDPR Chapter V requirements for cross-border data transfers.

A.7.5.1 Identify Basis for PII Transfer Between Jurisdictions

ISO 27701 Requirement: The organisation should identify and document the relevant basis for transfers of PII between jurisdictions.

Maelstrom AI Implementation:

Cross-Border Transfer Analysis:

Maelstrom AI is an Australian entity (Maelstrom AI Pty Ltd ATF Maelstrom AI Holding Trust, ABN 61 633 823 792, PO Box 169, St Arnaud VIC 3478). Maelstrom AI’s infrastructure runs on Cloudflare’s global network, which processes requests at edge locations worldwide.

Transfer Basis:

Legal Basis for Transfers:

1. Standard Contractual Clauses (SCCs): Cloudflare’s Data Processing Addendum incorporates the European Commission’s SCCs (2021/914) for transfers from the EEA to third countries.
2. Australian Privacy Principles (APPs): APP 8 (Cross-border disclosure) is addressed through Cloudflare’s binding contractual obligations.
3. UK International Data Transfer Agreement (IDTA): Covered by Cloudflare’s UK-specific addendum.

Transfer Impact Assessment:

The risk of cross-border transfers is substantially mitigated by Provii’s architecture:

• Verification flow. No PII crosses borders (zero knowledge proofs contain no personal data).
• Issuance flow. DOB is processed ephemerally at the receiving Cloudflare edge node and is never persisted or replicated.
• Operational data. Only hashed IP addresses are stored in Cloudflare KV. Even if accessed in another jurisdiction, the one-way SHA-256 hash cannot be reversed to recover the original IP address.

Evidence:

• Cloudflare Data Processing Addendum - SCCs and transfer mechanisms
• Privacy Architecture Evidence - Cross-border transfer analysis
• Unified Control Matrix - UC-030 (Cross-Border Transfers)

Status: ✅ Implemented

A.7.5.2 Countries and International Organisations to Which PII Can Be Transferred

ISO 27701 Requirement: The organisation should specify and document the countries and international organisations to which PII can potentially be transferred.

Maelstrom AI Implementation:

Transfer Destinations:

Maelstrom AI’s sole sub-processor is Cloudflare, Inc. (US-headquartered, global infrastructure).

Cloudflare Network Coverage:

Cloudflare operates data centres in 300+ cities across 100+ countries. When a user connects to a Provii API, their request is routed to the nearest Cloudflare Point of Presence (PoP). This means PII (IP addresses at the network level) may be transiently processed in any country where Cloudflare has infrastructure.

PII Storage Locations:

Transfer Safeguards:

1. SCCs: Cloudflare’s DPA with SCCs covers all transfers to countries without an adequacy decision.
2. Data Minimisation: Hashed IP addresses and ephemeral challenge state are the only data that may be replicated globally. Neither constitutes directly identifiable PII.
3. No Transfer to Authorities: Maelstrom AI does not voluntarily transfer PII to any government authority. Any lawful request would be evaluated by legal counsel.

Gap: Cloudflare KV does not currently support region-pinning on Maelstrom AI’s plan. If a future requirement mandates EU-only storage, this would require a plan upgrade or architectural change.

Evidence:

• Cloudflare DPA - Transfer mechanisms and SCCs
• Cloudflare network documentation - PoP locations
• Data Retention Policy - Storage locations

Status: ✅ Implemented

A.7.5.3 Records of PII Disclosure to Third Parties

ISO 27701 Requirement: The organisation should maintain records of disclosures of PII to third parties, including what PII was disclosed, to whom, when, and the basis for disclosure.

Maelstrom AI Implementation:

Third-Party Disclosure Analysis:

Disclosure Controls:

1. Verification Results Are Not PII: The boolean result returned to relying parties (age threshold met: yes or no) does not constitute PII disclosure. It contains no personal data.
2. No Data Sales: Maelstrom AI does not sell, rent, or trade any data to third parties.
3. No Ad Networks: Maelstrom AI does not share data with advertising networks or data brokers.
4. Sub-Processor Register: Cloudflare is the sole sub-processor. The Cloudflare DPA is the record of this processing relationship.

Disclosure Request Log:

If a disclosure request is received from law enforcement or a regulator, it will be logged in the incident management system with:

• Date of request
• Requesting authority
• Legal basis cited
• Data requested
• Data disclosed (if any)
• Legal counsel review outcome

Evidence:

• Audit logs - Verification event records (challenge ID, origin, result, timestamp)
• Cloudflare DPA - Sub-processor relationship record
• Incident Response Policy - Disclosure request handling

Status: ✅ Implemented

A.7.5.4 Notification of PII Disclosure Requests

ISO 27701 Requirement: The organisation should notify PII principals of legally binding requests for disclosure of their PII, where permitted by law.

Maelstrom AI Implementation:

Notification Analysis:

Scenario Assessment:

Practical Constraints:

1. User Identification Difficulty: Maelstrom AI does not collect user emails, names, or contact details. If a disclosure request targets an IP address, Maelstrom AI has no mechanism to notify the associated individual because Maelstrom AI does not know who they are.
2. Hashed IPs: Application-level logs store hashed IPs (SHA-256). Identifying the user behind a hash requires the original IP, which Maelstrom AI does not retain in raw form.
3. No User Accounts: There is no “user account” to send a notification to.

Notification Procedure (Where Feasible):

1. Receive disclosure request and log in incident management system.
2. Legal counsel reviews the request for validity and scope.
3. If notification is legally permitted and the user is identifiable (e.g., through relying party cooperation), notify the user via the available channel.
4. If notification is legally prohibited (gag order), comply with the prohibition and document accordingly.
5. If the user is not identifiable (no contact details), document the inability to notify.

Transparency Report:

Maelstrom AI intends to publish an annual transparency report disclosing:

• Number of disclosure requests received
• Number of requests complied with
• Number of requests challenged
• No specific user data (aggregate statistics only)

Evidence:

• Incident Response Policy - Disclosure request handling
• Privacy Architecture Evidence - User notification constraints

Status: 🔄 Partially Implemented

Current Implementation:

• Legal counsel review process defined
• Incident logging for disclosure requests established

Gap:

1. No published transparency report
2. No formal notification procedure documented
3. No mechanism to contact users (by design. no contact details collected)

Recommendation:

1. Document disclosure notification procedure in privacy policy
2. Publish first transparency report (even if zero requests received)
3. Acknowledge in privacy policy that notification may not be possible due to Provii’s zero-account architecture

Priority: Medium (Required for full ISO 27701 compliance)

Annex B: PII Processor Controls

See ISO 27701 Annex B: Processor Controls for the complete PII processor control mapping.

Docs Interactive Sandbox Scope (Phase 0A)

This section documents the alignment of this ISO 27701:2019 compliance statement with the Phase 0A docs interactive sandbox uplift introduced in April 2026. The docs sandbox surface comprises the gateway endpoints at docs.provii.app/api/*, the credential generators, the embedded API explorer, and the styler iframe origin at preview.docs-sandbox.provii.app. The full scope amendment is recorded in ISMS Scope v1.2.

Why this matters for ISO 27701

The docs sandbox introduces a new pre-contractual processing surface targeted at external developers. Although the surface processes no production end-user PII (real DOB strings are schema-rejected at the gateway boundary), it does process a small set of pseudonymous developer identifiers that fall within the PIMS scope: __Host-docs_session cookie value, server-side session_id, hashed source IP, Cloudflare bot protection cookies, and request metadata.

The sandbox is a developer-facing, low-volume surface. GDPR Art. 35(3) mandatory DPIA criteria are not met. PIMS coverage is nonetheless required because the surface introduces a new lawful-basis profile (Art. 6(1)(b) pre-contractual measures plus Art. 6(1)(f) bot protection legitimate interest), a new sub-processor scope (Cloudflare Cloudflare managed challenge and Cloudflare Super Bot Fight Mode in addition to the existing Cloudflare Workers, Workers Logs, and Grafana Loki sink), a new credential-issuance class (sandbox-scoped credentials carrying the docs-sbx-* and mwallet-sbx-* prefixes), and a new transparency obligation (a developer-facing privacy notice supplementing the main Privacy Policy).

How docs sandbox processing fits the PIMS

The Statement of Applicability gained an ISO 27701:2019 Extension Controls section that documents docs gateway application against the most directly impacted Annex A clauses:

Cross-link to the SOA section: Statement of Applicability, ISO 27701:2019 Extension Controls.

Sub-processor footprint (PIMS view)

The full sub-processor inventory is published at Sub-Processors. For PIMS purposes the docs sandbox uplift adds two additional Cloudflare service usages (Cloudflare managed challenge, Super Bot Fight Mode) and brings two existing platform-attestation services (Apple App Attest, Google Play Integrity) explicitly into the sub-processor inventory. None of these service additions trigger a new transfer mechanism: Cloudflare transfers continue under the existing master DPA with EU SCCs (Decision 2021/914, Module 2) and the UK IDTA; Apple and Google transfers operate under the developer-program agreements already in force for the Provii wallet.

Risk treatment alignment

The PIMS-specific risks introduced by the docs sandbox are treated under the RISK-2026-DOCS-* series in the Risk Register. Of particular relevance to ISO 27701:

Documentation deltas this section drives

The PIMS coverage above is implemented progressively across the Phase 0A delivery waves and ratified at the next quarterly management review per Management Review Record (maintained internally; available to auditors and enterprise customers on request).

Control Implementation Summary

Summary Statistics

Overall Implementation Rate: 74 of 83 controls (89%) implemented or not applicable

Implementation by Category

Compliance Posture by Priority

Critical Finding: All Critical priority controls are fully implemented, demonstrating strong privacy foundation.

Key Strengths

1. Zero knowledge Architecture

Description: Provii’s use of zkSNARKs for age verification represents a strong approach to privacy-preserving technology in identity verification.

Privacy Advantages:

• Computationally Infeasible to extract date of birth from proofs (under current cryptographic assumptions)
• No PII Collection by design, not policy
• Post-Quantum Roadmap. ML-DSA is on the cryptographic roadmap for future-proofing; current proofs use BLS12-381 with 128-bit classical security

Evidence:

• Cryptography Evidence - Complete zkSNARK implementation
• Privacy Architecture Evidence - Zero knowledge principle verification
• Age Verification Flow Evidence - UC-087 (Proof Generation)

Industry Leadership: Provii’s approach is designed to exceed ISO 27701 requirements and may set a new standard for privacy-preserving identity.

2. No PII Collection (Simplified Compliance)

Description: Maelstrom AI does not collect names, addresses, emails, phone numbers, or dates of birth through the Provii platform.

Compliance Simplification:

• No consent management (legitimate interest basis)
• No data subject access requests (nothing to access)
• No data portability complexity (minimal data)
• No right to erasure challenges (automatic deletion)
• No cross-border transfer restrictions (proofs contain no PII)

Evidence:

• Data Lifecycle Evidence - Lines 24-57 (Data NOT Collected list)
• Privacy Architecture Evidence - No PII principle
• Control A.7.2.6 - Data Minimization implementation

Risk Reduction: By not collecting PII, Maelstrom AI substantially reduces privacy breach risk.

3. Open Source Transparency (Trust Through Verifiability)

Description: All cryptographic code, ISMS policies, and security controls are publicly available.

Transparency Benefits:

• Public Auditability. Anyone can verify privacy claims
• Community Security Review. Open-source community can identify vulnerabilities
• Regulatory Confidence. Auditors can inspect implementation without NDA
• User Trust. No “trust us” required, cryptography is verifiable

Evidence:

• All relevant repositories public in our GitHub organisation
• ISMS documentation public at the Trust Centre (/trust/security)
• This ISO 27701 compliance document (public)

Industry Recognition: Transparency at this level is rare in identity verification sector.

4. Privacy by Design (Architectural Controls)

Description: Privacy is architecturally enforced, not policy-enforced.

Design Principles:

• Proactive. Collecting PII is not supported by the protocol, not just discouraged
• Default. Privacy is automatic, no configuration needed
• Embedded. Zero knowledge at protocol level, not application level
• Full Functionality. Privacy doesn’t compromise verification effectiveness
• End-to-End. Cryptographic protection throughout lifecycle
• Visibility. Open-source code provides transparency
• User-Centric. Wallet-based control, user owns credentials

Evidence:

• Privacy Architecture Evidence - Privacy by Design analysis (Lines 165-200)
• Control A.7.2.8 - Privacy-Enhancing Technologies
• Clause 5.4 - Privacy by Design and Default

Alignment: Designed to align with Ann Cavoukian’s 7 Foundational Principles of Privacy by Design.

5. Minimal Operational Data (90-Day Retention)

Description: Only IP addresses collected for abuse prevention, automatically deleted after 90 days.

Data Minimization:

• Purpose. Abuse prevention, DDoS protection, fraud detection only
• Retention. 90 days (minimal necessary for incident investigation)
• No Analytics PII. Aggregated metrics only, no IP addresses in analytics
• No Profiling. No user tracking, behavioural analysis, or fingerprinting

Evidence:

• Data Retention Policy - Lines 22-29 (IP address retention)
• Logging & Monitoring Evidence - Analytics without PII
• Control A.7.2.6 - Purpose Limitation

Compliance: Meets GDPR data minimization (Art. 5(1)(c)) and storage limitation (Art. 5(1)(e)) principles.

Gap Analysis

Critical Gaps (Immediate Action Required)

None Identified

All critical privacy controls are implemented. No critical gaps blocking ISO 27701 certification or GDPR compliance.

High Priority Gaps (Required for Certification)

Gap 1: Privacy Impact Assessments (DPIAs). ✅ RESOLVED

Control: UC-006 (A.7.2.4 - Privacy Impact Assessment) Resolution: Formal Data Protection Impact Assessment completed February 2026. Covers Verifier API, Issuer API, and Cloudflare sub-processing. Annual reassessment scheduled. Completed: February 2026

Gap 3: Privacy Policy Publication

Control: UC-002 (A.7.3.1 - Privacy Notice) Current State: Technical documentation public, no user-facing privacy policy Risk: GDPR Art. 13-14 non-compliance (transparency obligation) Impact: High (GDPR compliance requirement, ISO 27701 requirement)

Remediation:

1. Draft privacy policy based on proposed structure (Q1 2026)
2. Legal review by privacy counsel (Q1 2026)
3. Publish at provii.app/privacy (Q1 2026)
4. Add link to wallet app UI (Q1 2026)
5. Require relying parties to link to privacy notice (API terms update)

Owner: ISMS Owner (approval), Legal Counsel (review), Engineering (publication) Timeline: Q1 2026 Budget: $3,000 (legal review)

Medium Priority Gaps (Should Address Before Certification)

Gap 4: Privacy Breach Notification Procedures

Control: UC-027 (A.7.5.1 - PII Breach Identification) Current State: General incident response procedures, no privacy-specific breach notification Risk: GDPR Art. 33-34 non-compliance (72-hour notification requirement) Impact: Medium (Regulatory requirement, but low breach risk given minimal PII)

Remediation:

1. Document privacy breach notification procedures (Q1 2026)

• Breach classification (PII vs. non-PII)
• 72-hour notification timeline (to DPA)
• Breach notification template (to data subjects, if high risk)

2. Add privacy breach playbook to incident response policy (Q1 2026)
3. Conduct tabletop exercise for privacy breach scenario (Q2 2026)
4. Identify supervisory authority contacts (EU DPAs, ICO, CNIL)

Owner: Privacy Officer Timeline: Q1 2026 Budget: $1,000 (legal template review)

Gap 5: Data Subject Request Procedures

Control: UC-005 (A.7.3.4 - Provide Access to PII) Current State: Technical ability to query data, no formal DSAR process Risk: GDPR Art. 15-22 non-compliance (data subject rights) Impact: Medium (Regulatory requirement, simplified by minimal PII)

Remediation:

1. Document DSAR procedure in privacy policy
2. Implement DSAR tracking system (spreadsheet)
3. Create DSAR response templates (access, erasure, portability)
4. Test DSAR process with mock requests

Owner: Privacy Officer Note: Email-based process via privacy@maelstrom.au is operational; formal documentation improvements needed Budget: $2,000 (web form development, templates)

Gap 6: Automated KV Data Backups

Control: UC-168 (Data Backup Procedures) Current State: Manual KV export scripts, no automation Risk: Data loss if Cloudflare account compromised Impact: Medium (Business continuity risk, not privacy risk)

Remediation:

1. ✅ Implement weekly automated KV exports to Cloudflare R2 (Completed: Jan 2025, provii-backup deployed)
2. Encrypt backups at rest (AES-256)
3. Test KV restoration from backup (Q2 2026)
4. Document backup procedures in BCP (Q1 2026)

Owner: DevOps/Security Lead Timeline: Q1 2026 (restoration testing and BCP documentation remaining) Budget: $500 (Cloudflare R2 storage, minimal)

Low Priority Gaps (Nice to Have)

Gap 7: Status Page for Transparency

Control: UC-170 (Incident Communication) Current State: ✅ Resolved. Custom status page implemented (provii-status) Risk: Users unaware of service outages Impact: Low (Operational transparency, not privacy)

Remediation: ✅ Complete. status.provii.app deployed Owner: Security Lead Budget: $0 (custom implementation on Cloudflare Workers)

Gap 8: Privacy-Specific Metrics

Control: Clause 6 (Performance Evaluation) Current State: Security metrics tracked, no separate privacy KPIs Risk: Privacy performance not measured Impact: Low (Process improvement opportunity)

Remediation: Add privacy KPIs to quarterly ISMS review (Q2 2026) Suggested KPIs:

• Data subject requests received (count)
• DSAR response time (average days)
• Privacy competence evidence (certifications held)
• DPIA completion rate (%)
• Privacy-related support inquiries (count)

Owner: Privacy Officer Timeline: Q2 2026 Budget: $0 (process change only)

Remediation Roadmap

Q1 2026 (High Priority)

Q1 Total Effort: ~10 weeks (across team) Q1 Total Budget: $18,500

Q2 2026 (Medium Priority + Testing)

Q2 Total Effort: ~3 weeks Q2 Total Budget: $15,500

Audit Preparation (if pursued)

Q3 Total Effort: ~3 weeks Q3 Total Budget: $5,000

Certification Audit (when commercially justified)

Estimated Total Effort: ~5 weeks Estimated Total Budget: $15,000 (audit fees)

Total Certification Program Budget: $54,000 (12-18 months) Total Effort: ~21 weeks (distributed across team and timeline)

Certification Readiness Assessment

Current Readiness Score: 75/100

Breakdown by Category:

Assessment: Ready for Stage 1 Audit after Q1 2026 remediation

Readiness by ISO 27701 Clause

Overall Clause Readiness: 88% (Ready for certification with minor gaps)

Timeline to Certification

Target Certification Date: To be determined. will pursue after ISO 27001 certification is achieved and commercially justified.

Prerequisites:

1. Privacy policy publication → BLOCKER
2. DPIA completion → ✅ Completed (Feb 2026)
3. Penetration testing → BLOCKER
4. BCP tabletop exercises → BLOCKER

Risks to Timeline:

• Low Risk. Legal review delays (can expedite with external counsel)
• Low Risk. DPIA complexity (privacy-preserving architecture simplifies)
• Medium Risk. Penetration test findings (may require code changes)
• Low Risk. Certification body availability (book early)

Conclusion

Provii’s privacy architecture represents a significant shift in age verification. By employing zero knowledge proofs, the system is designed to provide strong cryptographic privacy properties that are intended to exceed traditional compliance approaches.

Key Takeaways

1. Architectural Privacy Through Ephemeral Processing: Provii’s architecture provides strong ISO 27701 compliance through a trust-based issuance model where DOB is processed ephemerally and immediately discarded, combined with zero knowledge verification that transmits no PII. No personal data is ever persisted.

2. Simplified Compliance: By processing DOB only transiently during issuance (never storing it) and collecting no other traditional PII (no names, addresses, emails), Maelstrom AI simplifies the majority of privacy compliance requirements. Data subject rights, consent management, and data transfer restrictions are dramatically simplified.

3. Strong Foundation: 89% of ISO 27701 Annex A controls are implemented or not applicable. All Critical controls are fully implemented. The privacy foundation is solid.

4. Path to Certification: With identified gaps remediated, Maelstrom AI will be positioned for ISO 27701 certification. Timeline will be determined after ISO 27001 certification is achieved.

5. Industry Leadership: Provii’s approach has the potential to influence future privacy standards for identity verification. The combination of zero knowledge proofs, open source transparency, and PIMS documentation sets a new benchmark.

Final Assessment

Current Compliance Status: STRONG (89% implementation, all critical controls in place)

Certification Readiness: Documentation and controls aligned for certification when pursued

Privacy Posture: EXEMPLARY (exceeds ISO 27701 requirements in key areas)

Recommendations:

1. Prioritize remediation (privacy policy, DPIAs, training) - These would be prerequisites if certification is pursued
2. Maintain architectural privacy commitment - Zero knowledge approach is a competitive advantage
3. Consider pursuing privacy certification as a differentiator - Few age verification providers are pursuing ISO 27701 certification
4. Engage privacy counsel early - Legal review will accelerate compliance finalization
5. Schedule certification body engagement - Book audits 3-6 months in advance

Risk Assessment:

• Low Risk. Certification failure (strong foundation, clear remediation path)
• Medium Risk. Timeline delays (penetration testing, legal reviews)
• Low Risk. Regulatory non-compliance (GDPR, CCPA alignment strong)

Competitive Position: Provii’s privacy architecture and ISO 27701 alignment positions it among the more privacy-rigorous age verification offerings. Few known age verification competitors have combined:

1. Zero knowledge cryptographic privacy
2. Zero PII collection
3. Open-source transparency
4. ISO 27701 certification being pursued (when commercially justified)

This combination provides a strong foundation for differentiation in the privacy-conscious identity market.

Appendices

Appendix A: Complete Control Mapping Matrix

See Unified Control Matrix for the complete control mapping across all frameworks, including ISO 27701-specific controls.

Appendix B: Evidence Cross-Reference Index

See Evidence Mapping for the evidence cross-reference index linking controls to supporting documentation.

Appendix C: Privacy Policy

See Privacy Policy for the current published privacy policy.

Appendix D: DPIA Templates

See Data Protection Impact Assessment for the formal DPIA covering Provii’s processing activities across Verifier API, Issuer API, and sub-processors.

Appendix E: GDPR Article 30 Records of Processing Activities

See Records of Processing Activities (ROPA) for the formal ROPA document required by GDPR Article 30.

Appendix F: Glossary of Privacy Terms

Key ISO 27701 and privacy terminology used throughout this document:

Document End

Version: 1.0 Date: 2025-11-08 Classification: Public Next Review: 2026-07-08 (or upon significant change) Owner: ISMS Owner Maintained By: Privacy Officer

Revision History:

• v1.0 (2025-11-08): Initial compliance documentation created
• Future revisions will track remediation progress and re-assessments

For questions or clarifications, contact:

• Privacy Inquiries. privacy@maelstrom.au
• Security Inquiries. security@maelstrom.au
• General Inquiries. info@provii.app