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:
- Privacy by Design: Building systems that can’t collect PII, rather than relying on policy to protect it
- Defence in Depth: Implementing multiple layers of security controls
- Transparency: Making our security practices publicly auditable
- 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
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:
- Identify information assets and threats
- Assess likelihood and impact of risks
- Treat risks through controls or acceptance
- 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 Area | Example Controls |
|---|---|
| Access Control | API authentication, HMAC verification, role-based access |
| Cryptography | Groth16 ZKP, Ed25519 attestation, key management |
| Physical Security | Managed by Cloudflare/GitHub, remote work policies |
| Operations Security | Change management, backup procedures, monitoring |
| Communications Security | TLS everywhere, Cloudflare network security |
| Development Security | Secure SDLC, security testing, supply chain security |
| Supplier Relationships | Cloudflare/GitHub vendor assessment |
| Incident Management | Detection, response, recovery, lessons learned |
| Compliance | Australian Privacy Act, internal audits |
See: Statement of Applicability for full control catalog
Key Supporting Policies
Access Control Policy
Authentication, authorisation, and access management
Cryptography Policy
Cryptographic algorithm selection and key management
Acceptable Use Policy
Appropriate use of company resources and systems
Change Management
Controlled changes to production systems
Incident Response
Detection, response, and recovery from security incidents
Business Continuity
Ensuring service continuity during disruptions
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:
- Detect and report incident
- Assess severity and scope
- Contain the incident
- Eradicate root cause
- Recover services
- 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:
- Security Lead proposes updates
- ISMS Owner reviews and approves
- All team members notified of changes
- Training provided if needed
Exceptions
Security policy exceptions require:
- Written justification and risk assessment
- Compensating controls where possible
- Approval from ISMS Owner
- Time limit and review date
- 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.