Risk Assessment Methodology

Purpose

This methodology defines how Maelstrom AI identifies, assesses, prioritises, and treats information security risks across both of the organisation’s platforms — Provii (zero-knowledge age verification) and downpipes (no-custody backup & disaster recovery for the Cloudflare data layer). It supports consistent risk management across our organisation and alignment with ISO 27001:2022 requirements.

The methodology is organisation-level: it applies identically to both platforms. Organisation-level risks (governance, personnel, supply chain, change management) are assessed once for Maelstrom AI; platform-specific risks layer on top — Provii’s cryptographic and identity-assurance risks, and downpipes’ no-custody, in-tenant operating risks. See the ISMS Scope Statement for the system boundary across both products.

Risk Management Framework

We follow a risk-based approach to security, focusing resources where they provide the most protection for both platforms — sound proofs and minimal PII processing for our zero knowledge age verification service, and verifiable, tamper-evident archives under customer-held keys for our no-custody backup service.

graph TD
    A[Identify Assets & Threats] --> B[Assess Risks]
    B --> C[Prioritise Risks]
    C --> D[Select Treatment]
    D --> E[Implement Controls]
    E --> F[Monitor & Review]
    F --> A

Risk Assessment Frequency

Regular Assessments: Annually (Q1 of each year)

Triggered Assessments when:

• Launching new services or major features
• Significant infrastructure changes (new cloud provider, architecture redesign)
• After security incidents
• Changes to threat surface (new attack vectors, vulnerabilities)
• Changes to legal/regulatory requirements
• Prior to ISO 27001 certification audits

Ongoing Monitoring: Continuous monitoring of key risk indicators

Step 1: Asset Identification

Asset Categories

We classify information assets into categories:

Asset Register

We maintain an Asset Register documenting:

• Asset identifier and description
• Asset owner (role)
• Classification (critical, high, medium, low)
• Location (Cloudflare KV, GitHub, etc.)
• Dependencies on other assets

Step 2: Threat Identification

We consider threats across multiple categories:

External Threats

Internal Threats

• Accidental secret exposure in code/logs
• Configuration errors leading to security gaps
• Insufficient access controls
• Lack of security awareness
• Inadequate change management

Environmental Threats

• Developer workstation compromise
• Loss of key personnel (knowledge concentration)
• Natural disasters affecting cloud infrastructure
• Internet infrastructure disruption

Step 3: Vulnerability Assessment

For each asset-threat combination, we identify vulnerabilities:

Technical Vulnerabilities:

• Unpatched dependencies
• Cryptographic implementation bugs
• Weak authentication mechanisms
• Insecure configurations
• Insufficient logging/monitoring

Process Vulnerabilities:

• Lack of code review
• Insufficient testing coverage
• Weak incident response procedures
• Inadequate backup processes

Human Vulnerabilities:

• Insufficient security training
• Credential management weaknesses
• Social engineering susceptibility

Step 4: Risk Analysis

Likelihood Assessment

We assess the likelihood of each risk scenario:

Impact Assessment

We assess business impact if the risk materialises:

Zero knowledge Impact Considerations (Provii)

Because Provii’s operated services don’t store PII, data breach impacts are fundamentally different:

<Check> What We CAN’T Lose:

• User identity information (during verification, no personal information is collected; during issuance, date of birth is processed ephemerally and immediately discarded)
• Personally identifiable data (zero knowledge architecture)
• Age verification history (proofs are ephemeral) </Check>

This significantly simplifies risk assessment compared to traditional identity systems.

No-Custody Impact Considerations (downpipes)

downpipes shifts the impact profile the same way for a different reason: because backups run in the customer’s own Cloudflare account, under the customer’s keys, and Maelstrom holds no customer keys, data or Cloudflare tokens.

A compromise of the vendor control-plane cannot read customer archives, and the licence is fail-open — it never gates backup or restore. Customer-side key loss is, by design, unrecoverable by Maelstrom; that residual is carried as a complementary user-entity control (see the Risk Register).

Risk Scoring

Risk Score = Likelihood × Impact

Step 5: Risk Treatment

For each identified risk, we select a treatment option:

Treatment Options

Control Selection

When mitigating risks, we select controls based on:

1. Effectiveness: Does it meaningfully reduce risk?
2. Cost: Implementation and operational costs
3. Compliance: ISO 27001 Annex A alignment
4. Feasibility: Can we implement it with our architecture?
5. Impact: Does it affect usability or performance?

See Statement of Applicability for selected controls.

Step 6: Risk Treatment Plan

For each risk requiring treatment, we document:

Step 7: Residual Risk

After implementing controls, we assess residual risk:

Residual Risk = Inherent Risk - Control Effectiveness

Acceptance Criteria:

• Critical risks: Must be reduced to Medium or Low
• High risks: Should be reduced to Medium or Low
• Medium risks: May be accepted if cost of further mitigation is excessive
• Low risks: Generally accepted

Approval: ISMS Owner must formally accept all residual risks above Low level.

Step 8: Monitoring and Review

Ongoing Monitoring

We continuously monitor:

Regular Reviews

Quarterly: Review key risk indicators, update risk scores for changing threat surface

Annually: Full risk assessment, review all controls, update risk register

After Incidents: Conduct root cause analysis, update risk assessment, implement lessons learned

Risk Acceptance Criteria

We accept risks when:

1. Score ≤ 4 (Low)
2. Cost of mitigation > value protected
3. Risk is outside our control (e.g., internet infrastructure failure)
4. Compensating controls reduce risk to acceptable level
5. Documented and approved by ISMS Owner

We never accept:

• Risks to cryptographic integrity without strong compensating controls
• Risks that violate legal/regulatory requirements
• Risks with severe impact, regardless of likelihood

Documentation

All risk assessments produce:

1. Risk Register - Living document of all identified risks (view register)
2. Risk Treatment Plan - Actions to mitigate unacceptable risks
3. Risk Acceptance Forms - Documented justification for accepted risks
4. Risk Review Reports - Quarterly and annual reviews

Roles and Responsibilities

Special Considerations

Zero knowledge Architecture (Provii)

Provii’s risk profile is fundamentally different from traditional systems:

No-Custody Architecture (downpipes)

downpipes reshapes the risk profile through custody, not cryptography of identity: backups run in the customer’s own Cloudflare account, under the customer’s keys.

Cloud-Native Risks

Operating entirely on Cloudflare/GitHub:

Advantages:

• No physical security concerns
• Enterprise-grade DDoS protection
• Automatic scaling and resilience

Challenges:

• Dependency on third-party availability
• Limited control over infrastructure
• Account security is critical

For downpipes, the vendor footprint is deliberately minimal — a fail-open control-plane and a static, signature-pinned update channel (updates.downpipes.io) — while the engine and console run inside the customer’s own Cloudflare account (customer-operated). This narrows the vendor-side attack surface but shifts operational responsibility for the running instances to the customer as a complementary user-entity control.

Supply Chain Focus

Given our SLSA Level 3 commitment, supply chain risks receive extra scrutiny:

• Dependency vulnerability scanning in every build
• Hermetic builds prevent tampering
• Artefact signing supports integrity
• Transparency logs enable auditing

For downpipes, the supply chain extends into the customer’s account through the update path, so it is held to the same scrutiny: the update channel is static and signature-pinned, the engine verifies each update against a pinned public key and pulls (never receives a push), and the update-signing key is held offline by the operator and never deployed to any Worker.

Related Documents

• Risk Register - Current risk assessment results
• Statement of Applicability - Controls implementing risk treatments
• ISMS Scope - Assets covered by risk assessments
• Information Security Policy - Overarching security principles

Document Information

• Version. 1.2
• Effective Date. 2025-01-13
• Last Updated. 2026-06-19
• Owner. ISMS Owner
• Maintained By. Security Lead
• Review Frequency. Annually
• Next Review. 2026-11-21
• Classification. Public
• Change (1.2). Methodology re-centred on Maelstrom AI as the organisation; downpipes added as a second in-scope platform (no-custody asset, threat, impact, treatment and special-consideration framing added alongside Provii); the legacy backup worker retired in favour of self-hosted downpipes.