Information Security Policy

Top-level security policy governing Maelstrom AI's information security program

Public

Purpose

This Information Security Policy establishes the security principles, objectives, and requirements for Maelstrom AI’s Provii platform. It provides the foundation for our ISO 27001:2022 Information Security Management System (ISMS).

Scope

This policy applies to:

  • All team members (employees, contractors, consultants)
  • All information systems within the ISMS scope
  • All information assets, including source code, cryptographic keys, and operational data
  • All third-party service providers with access to our systems

Policy Statement

Maelstrom AI is committed to protecting the confidentiality, integrity, and availability of our zero knowledge age verification platform through a risk-based security program.

We recognise that security is fundamental to our mission of privacy-preserving identity verification. Our security philosophy emphasizes:

  1. Privacy by Design: Building systems that can’t collect PII, rather than relying on policy to protect it
  2. Defence in Depth: Implementing multiple layers of security controls
  3. Transparency: Making our security practices publicly auditable
  4. Continuous Improvement: Regularly assessing and enhancing security posture

Security Objectives

1. Protect Cryptographic Integrity

Objective: Ensure the mathematical soundness and security of our zero knowledge proof systems

How We Achieve This:

  • Using battle-tested cryptographic libraries (bellman, bls12_381)
  • Regular security reviews of cryptographic code
  • Maintaining strict access control for signing keys
  • Testing including fuzzing, property-based tests, and known-answer tests

See: provii-crypto documentation

2. Maintain Service Availability

Objective: Provide reliable age verification services with minimal unplanned downtime

Target: 99.9% uptime for production APIs (best-effort internal objective; no contractual SLA at this tier)

How We Achieve This:

  • Edge-based architecture on Cloudflare’s global network
  • Edge-based redundancy through Cloudflare’s global network with smart placement
  • Rate limiting and DDoS protection
  • Incident response procedures for rapid recovery

See: Business Continuity Plan

3. Secure Software Development

Objective: Produce secure, auditable code through rigorous development practices

How We Achieve This:

  • Security scanning in CI/CD (CodeQL, cargo audit, npm audit)
  • Mutation and property-based testing
  • Code review requirements
  • SLSA Level 3 supply chain security

See: Development Best Practices

4. Protect Operational Secrets

Objective: Safeguard API keys, signing keys, and authentication secrets

How We Achieve This:

  • Cloudflare Workers secrets (never in source code)
  • KV storage with access controls
  • HMAC-based API authentication
  • Regular secret rotation for long-lived credentials
  • Zeroization of secrets in memory after use

See: Cryptography Policy

5. Ensure Compliance

Objective: Meet legal and regulatory requirements, particularly Australian Privacy Act

Status: Zero knowledge architecture significantly simplifies compliance by minimising server-side PII processing. During issuance, the date of birth is transmitted once to the issuer API for Pedersen commitment computation and immediately discarded. During verification, no PII is transmitted.

How We Achieve This:

  • Regular compliance assessments
  • Documented policies and procedures
  • Audit trail for security-relevant events
  • ISO 27001:2022 certification pursuit when commercially justified

Information Security Principles

1. Zero knowledge First

Our architectural principle: If we don’t collect it, we can’t lose it.

2. Radical Transparency

We make our security practices public because:

  • We have nothing to hide (no PII to protect through obscurity)
  • Open scrutiny improves security
  • It builds trust through verifiability
  • Customers can audit our controls without waiting for a sales call

What’s Public: Architecture, policies, procedures, control implementations, source code

What’s Private: Operational secrets (API tokens, signing keys, HMAC secrets)

3. Security by Design

Security is integrated into every phase:

  • Design. Threat modeling before implementation
  • Development. Security scanning, testing, code review
  • Deployment. Hermetic builds, artifact signing, provenance
  • Operation. Monitoring, logging, incident response

4. Defence in Depth

We implement multiple layers of security:

  • Network. Cloudflare DDoS protection, edge security
  • Application. Input validation, rate limiting, HMAC authentication
  • Cryptographic. Zero knowledge proofs, digital signatures
  • Operational. Access controls, audit logging, incident response
  • Supply Chain. SLSA Level 3 compliance, artifact signing

5. Least Privilege

Access rights are minimised:

  • CI/CD jobs have minimal permissions
  • API keys scoped to specific functions
  • Role-based access control where applicable
  • Time-limited credentials for temporary access

Roles and Responsibilities

ISMS Owner

  • Overall accountability for the ISMS
  • Approval of security policies and risk treatments
  • Resource allocation for security initiatives
  • Management review and ISMS effectiveness

Security Lead

  • Implementation and maintenance of security controls
  • Security testing and vulnerability management
  • Incident response coordination
  • Internal security audits

Developer

  • Secure coding practices
  • Security testing integration in development
  • Compliance with security policies
  • Reporting security concerns

All Team Members

  • Completing security awareness training
  • Following the Acceptable Use Policy
  • Reporting security incidents immediately
  • Protecting credentials and access tokens

See: Roles and Responsibilities Matrix

Risk Management

Approach: We follow a risk-based approach to security, focusing resources on the most significant threats to our zero knowledge age verification service.

Process:

  1. Identify information assets and threats
  2. Assess likelihood and impact of risks
  3. Treat risks through controls or acceptance
  4. Monitor effectiveness and emerging threats

Frequency: Risk assessments conducted annually and after significant changes

See: Risk Assessment Methodology | Risk Register

Security Controls

We implement controls based on ISO 27001:2022 Annex A, tailored to our cloud-native, zero knowledge architecture:

Control AreaExample Controls
Access ControlAPI authentication, HMAC verification, role-based access
CryptographyGroth16 ZKP, Ed25519 attestation, key management
Physical SecurityManaged by Cloudflare/GitHub, remote work policies
Operations SecurityChange management, backup procedures, monitoring
Communications SecurityTLS everywhere, Cloudflare network security
Development SecuritySecure SDLC, security testing, supply chain security
Supplier RelationshipsCloudflare/GitHub vendor assessment
Incident ManagementDetection, response, recovery, lessons learned
ComplianceAustralian Privacy Act, internal audits

See: Statement of Applicability for full control catalog

Key Supporting Policies

Compliance Requirements

Australian Privacy Act 1988

Status: Significantly simplified compliance due to zero knowledge architecture

Obligations:

  • We minimise personal information collection; during age verification, no personal information is collected. During credential issuance, a date of birth is processed ephemerally and immediately discarded
  • IP addresses in audit logs are treated as personal data and automatically deleted after 90 days
  • Audit logs retained 90 days for anti-abuse; critical security event logs are retained for up to 365 days

Documentation: Our architecture naturally satisfies privacy principles through technical controls rather than policy restrictions

ISO 27001:2022

Status: ISMS implementation in progress, certification pursued when commercially justified

Requirements Met:

  • ✅ ISMS scope defined
  • ✅ Information security policy established
  • ✅ Risk assessment methodology documented
  • ✅ Statement of Applicability (all 93 controls addressed)
  • ✅ Supporting policies and procedures
  • ✅ Internal audit program

Remaining Work:

  • Achieving 12 months of evidence for certification audit
  • External certification audit process

Security Awareness and Training

All team members receive security awareness training covering:

  • Information security responsibilities
  • Threat surface (phishing, social engineering, supply chain attacks)
  • Secure coding practices
  • Incident reporting procedures
  • Password and credential management
  • Remote work security

Frequency: Initial training on onboarding, annual refreshers, ad-hoc for emerging threats

See: Security Awareness Training Program

Incident Response

Security incidents must be reported immediately to: security@maelstrom.au

Definition of Security Incident:

  • Unauthorized access to systems or data
  • Compromise of cryptographic keys
  • Service disruption or availability issues
  • Vulnerabilities in production systems
  • Supply chain compromise indicators

Response Process:

  1. Detect and report incident
  2. Assess severity and scope
  3. Contain the incident
  4. Eradicate root cause
  5. Recover services
  6. Learn and improve controls

See: Incident Response Policy and Procedure

Non-Compliance

Violations of this policy may result in:

  • Mandatory security training
  • Access restrictions
  • Disciplinary action
  • Termination of access for contractors
  • Legal action (for criminal violations)

Reporting Violations: Team members should report suspected policy violations to the ISMS Owner or Security Lead.

Policy Review and Maintenance

This policy is reviewed:

  • Annually as part of quarterly management review cycle
  • After significant security incidents
  • When changes to ISO 27001 standard occur
  • When significant business or technical changes occur

Review Process:

  1. Security Lead proposes updates
  2. ISMS Owner reviews and approves
  3. All team members notified of changes
  4. Training provided if needed

Exceptions

Security policy exceptions require:

  1. Written justification and risk assessment
  2. Compensating controls where possible
  3. Approval from ISMS Owner
  4. Time limit and review date
  5. Documentation in risk register

No exceptions permitted for:

  • Cryptographic algorithm standards
  • Artifact signing requirements
  • Incident reporting obligations
  • Access to production signing keys

Contact

Security Questions: security@maelstrom.au

Policy Owner: ISMS Owner

Document Location: https://maelstrom.au/trust/security/information-security-policy


Document Information

  • Version. 1.1
  • Effective Date. 2025-01-13
  • Last Updated. 2026-05-21
  • Owner. ISMS Owner
  • Review Frequency. Annually
  • Next Review. 2026-11-21
  • Classification. Public
  • Approved By. ISMS Owner
  • Approval Date. 2025-01-13

Acknowledgment: By accessing Maelstrom AI systems or information, you acknowledge that you have read, understood, and agree to comply with this Information Security Policy.