Risk Assessment Methodology

Purpose

This methodology defines how Maelstrom AI identifies, assesses, prioritises, and treats information security risks for the Provii platform. It supports consistent risk management across our organisation and alignment with ISO 27001:2022 requirements.

Risk Management Framework

We follow a risk-based approach to security, focusing resources where they provide the most protection for our zero knowledge age verification service.

graph TD
    A[Identify Assets & Threats] --> B[Assess Risks]
    B --> C[Prioritize 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

Because we 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.

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

Our risk profile is fundamentally different from traditional systems:

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

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

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.1
• Effective Date. 2025-01-13
• Last Updated. 2026-05-21
• Owner. ISMS Owner
• Maintained By. Security Lead
• Review Frequency. Annually
• Next Review. 2026-11-21
• Classification. Public