Purpose
This Risk Register documents all identified information security risks for the Provii platform, their current status, and treatment plans. It serves as a living document that is reviewed quarterly and updated after significant changes.
Risk Summary
Critical Risks
0 Active
High Risks
5 Active
Medium/Low Risks
2 Accepted, 15 Mitigated
Critical Risks
None currently identified
All previously critical risks have been mitigated to High or below through implementation of security controls.
High Risks
RISK-2025-H001: Signing Key Compromise
| Attribute | Value |
|---|---|
| Category | Cryptographic |
| Description | RedJubjub signing keys for credential issuance could be compromised through infrastructure breach or insider threat |
| Impact | Severe (5) - Attacker could issue fraudulent credentials, destroying trust |
| Likelihood | Unlikely (2) - Strong access controls, but not impossible |
| Inherent Risk Score | 10 (High) |
| Treatment | Mitigate |
Current Controls:
- Signing keys stored exclusively in Cloudflare Workers KV with access controls
- Keys never appear in source code or logs
- Access limited to provii-issuer Worker only
- Audit logging for all key access
- Secrets zeroized in memory after use
- Multi-factor authentication for Cloudflare console access
Planned Improvements:
- Evaluate hardware security module (HSM) for key storage when key management requirements grow
- Rotate signing keys annually
- Implement split-key ceremony for key generation
Residual Risk Score: 4 (Medium - accepted) Status: Active mitigation, monitoring
RISK-2025-H002: Supply Chain Compromise
| Attribute | Value |
|---|---|
| Category | Supply Chain |
| Description | Malicious code injected into dependencies or build pipeline, compromising distributed artifacts |
| Impact | Major (4) - Users could download compromised software |
| Likelihood | Possible (3) - npm/crates.io attacks have occurred |
| Inherent Risk Score | 12 (High) |
| Treatment | Mitigate |
Current Controls:
- SLSA Level 3 build process
- Hermetic builds with locked dependencies (Cargo.lock, package-lock.json)
cargo auditandnpm auditin every CI build (fails on HIGH vulnerabilities)- Cryptographic signing via Sigstore (keyless)
- Non-falsifiable provenance generation
- Transparency logging in Rekor
- ISMS Owner review (branch protection enforced; full SLSA Level 3 requires two-reviewer policy, which is a noted gap for a sole operator)
Planned Improvements:
- Enable GitHub branch protection for full SLSA Level 3 compliance
- Implement SBOM (Software Bill of Materials) generation
- Add automated Dependabot for dependency updates
Residual Risk Score: 4 (Medium - accepted) Status: Strong mitigation in place, continuous monitoring
RISK-2026-DOCS-H01: Bearer Token XSS Exfiltration via Scalar Supply Chain
| Attribute | Value |
|---|---|
| Category | Application Security / Supply Chain |
| Description | The docs sandbox gateway issues a sandbox bearer token bound to the __Host-docs_session cookie and consumed by the Scalar-rendered API explorer embedded in the docs site. A cross-site scripting payload reaching the docs origin, or a compromise of the Scalar bundle delivered via npm or CDN, could exfiltrate live developer bearer tokens and replay them against docs.provii.app/api/* to consume sandbox credit and mint sandbox issuer client IDs |
| Impact | Major (4). Exfiltrated bearer tokens permit credential mint and credit exhaustion across the affected developer fleet; reputational damage from a docs-origin script compromise |
| Likelihood | Possible (3). Documentation sites have a non-trivial XSS surface (code blocks, sample renderers, third-party widgets) and supply-chain attacks against developer-tooling npm packages are recurring |
| Inherent Risk Score | 12 (High) |
| Treatment | Mitigate |
Current Controls:
__Host-cookie prefix (path=/, secure, no domain attribute)- HMAC-SHA-256 session binding via
DOCS_SESSION_HMAC_KEY(CRYPTO-006) - Strict CSP on the docs origin restricting script-src to known sources
- Subresource Integrity (SRI) on Scalar bundle delivery
- Bearer tokens scoped to sandbox-only KV (
SANDBOX_DOCS_ISSUERS); no production access surface - Production middleware rejects
docs-sbx-*prefixes across body, path, query, and authorisation header - 4-hour session hard cap bounds the exfiltration window
Planned Improvements:
- Pin Scalar bundle hash and verify in CI
- Add CSP report-only header for early signal on script-src violations
- Quarterly review of third-party bundle dependency tree
SOA Cross-References: A.5.7 (Threat Intelligence), A.5.21 (ICT Supply Chain Security), A.8.7 (Protection Against Malware), A.8.25 (Secure Development Lifecycle), A.8.28 (Secure Coding)
Related DPIA: Docs Sandbox DPIA (Risk R-4)
Owner: ISMS Owner Residual Risk Score: 6 (Medium) Status: Active mitigation, monitoring
RISK-2026-DOCS-H02: DOCS_SESSION_HMAC_KEY Leak Forges Sessions Across Developer Fleet
| Attribute | Value |
|---|---|
| Category | Cryptographic / Key Management |
| Description | Compromise of DOCS_SESSION_HMAC_KEY (CRYPTO-006) permits an attacker to forge __Host-docs_session cookies for any developer session ID, bypassing the gateway’s session-binding control. Combined with knowledge of a target session_id, this enables session hijack and credential mint in the target’s name. The same risk class covers leakage of DOCS_ATTESTATION_ED25519_SEED (CRYPTO-007), which would permit forging sandbox attestations |
| Impact | Major (4). Fleet-wide session forgery; sandbox credit exhaustion; loss of audit attribution integrity |
| Likelihood | Unlikely (2). Keys held in Cloudflare Secrets Store, never materialised as JS strings, accessed only by the AttestationSigner closure |
| Inherent Risk Score | 8 (High) |
| Treatment | Mitigate |
Current Controls:
- Both keys held in Cloudflare Secrets Store (internal namespace)
kid-prefixed key rotation on a 90-day cadence; both old and new keys retained for the full 4-hour hard-cap window; single-shotkid-keyed lookup (never try-both-keys)DOCS_ATTESTATION_ED25519_SEEDheld only inside theAttestationSignerclosure atsrc/docs/attestation-signer.ts; never materialised as a JS string- Disjoint sandbox vs production key material. a sandbox key compromise does not affect production attestations
- Production middleware rejects
docs-sbx-*andmwallet-sbx-*prefixes, capping blast radius to the sandbox surface - KV-sweep compromise response procedure documented on the asset register entries
Planned Improvements:
- Quarterly rotation rehearsal with documented cutover timing
- Telemetry on
kiddistribution to detect old-key persistence
SOA Cross-References: A.5.17 (Authentication Information), A.8.5 (Secure Authentication), A.8.24 (Use of Cryptography)
Related DPIA: Docs Sandbox DPIA (Risk R-3, R-5)
Owner: ISMS Owner Residual Risk Score: 3 (Low) Status: Active mitigation, quarterly rotation
RISK-2026-DOCS-H03: Sandbox Feature Flag Hygiene Under Rust Workspace Resolver
| Attribute | Value |
|---|---|
| Category | Build / Supply Chain |
| Description | The Rust workspace at the verifier-API root uses Cargo’s resolver v2 with workspace-level feature unification. A misconfigured workspace member or a transitive dev-dependency that forwards the sandbox feature could collapse sandbox-only code paths into the production binary at build time, weakening the strict docs-sbx-* and mwallet-sbx-* prefix rejection middleware that holds the sandbox-production boundary |
| Impact | Major (4). A sandbox credential reaching the production verifier would defeat the principal protection on the sandbox-production boundary; a sandbox attestation accepted in production would invalidate the disjoint-key-material guarantee |
| Likelihood | Unlikely (2). Workspace audit conducted; CI guard rejects sandbox feature in production target |
| Inherent Risk Score | 8 (High) |
| Treatment | Mitigate |
Current Controls:
- Workspace-level
resolver = "2" - Sandbox features gated behind
cfg(feature = "sandbox")and excluded from the production build matrix - CI guard rejects
sandboxfeature in production target viacargo build --release --no-default-featuresfollowed by an artefact-introspection step that fails the build if any sandbox symbol is reachable - Strict-prefix middleware in production verifier rejects
docs-sbx-*andmwallet-sbx-*before any handler-specific validation - Negative tests cover all four input surfaces (body, path, query,
Authorisationheader)
Planned Improvements:
- Add
cargo deny check featuresto the CI gate - Quarterly review of workspace member feature matrix
SOA Cross-References: A.8.25 (Secure Development Lifecycle), A.8.27 (Secure System Architecture and Engineering), A.8.31 (Separation of Development, Test, Production), A.8.32 (Change Management)
Related DPIA: Docs Sandbox DPIA (Risk R-9)
Owner: ISMS Owner Residual Risk Score: 3 (Low) Status: Active mitigation, CI-enforced
Medium Risks
RISK-2025-M001: Cloudflare Service Disruption
| Attribute | Value |
|---|---|
| Category | Infrastructure |
| Description | Extended outage of Cloudflare Workers, KV, or Durable Objects preventing service operation |
| Impact | Major (4) - Complete service unavailability |
| Likelihood | Unlikely (2) - Cloudflare has strong SLA and redundancy |
| Inherent Risk Score | 8 (Medium) |
| Treatment | Accept + Business Continuity Planning |
Current Controls:
- Cloudflare’s enterprise-grade reliability (Cloudflare-published 99.9% uptime target for Workers; this is Cloudflare’s own stated objective, not a contractual SLA offered by Maelstrom AI)
- Global edge distribution (300+ locations)
- Automatic failover through Cloudflare’s global edge network
- Business Continuity Plan documented
- Status monitoring and incident response procedures
Rationale for Acceptance:
- Cloudflare provides enterprise-grade reliability beyond our ability to improve
- Alternative providers would introduce complexity without significant risk reduction
- Zero-knowledge architecture means credentials are client-held, reducing persistent data exposure risk during outages
Residual Risk Score: 8 (Medium - accepted) Status: Accepted with monitoring
RISK-2025-M002: Dependency Vulnerability Exploitation
| Attribute | Value |
|---|---|
| Category | Technical |
| Description | Critical vulnerability in cryptographic library (bellman, bls12_381, etc.) exploited before we can patch |
| Impact | Major (4) - Could compromise proof verification |
| Likelihood | Unlikely (2) - Using well-audited libraries, vulnerabilities are rare |
| Inherent Risk Score | 8 (Medium) |
| Treatment | Mitigate |
Current Controls:
- Security audits in CI/CD (
cargo audit,npm audit) - Using stable, battle-tested cryptographic libraries
- Monitoring security advisories (GitHub Security Alerts)
- Rapid patch deployment capability (automated CI/CD)
- Monthly dependency review process
Planned Improvements:
- Subscribe to rust-sec advisory mailing list
- Implement automated security patch PRs (Dependabot)
Residual Risk Score: 4 (Low - accepted) Status: Mitigated, ongoing monitoring
RISK-2025-M003: Developer Account Compromise
| Attribute | Value |
|---|---|
| Category | Human |
| Description | Developer GitHub or Cloudflare account compromised through phishing or credential theft |
| Impact | Major (4) - Could deploy malicious code or steal secrets |
| Likelihood | Possible (3) - Phishing is common, humans are fallible |
| Inherent Risk Score | 12 (High initially) |
| Treatment | Mitigate |
Current Controls:
- Required multi-factor authentication (GitHub, Cloudflare)
- Security awareness training (phishing, social engineering)
- Branch protection and code review requirements
- Audit logging for all administrative actions
- Principle of least privilege for account permissions
- Regular access reviews
Planned Improvements:
- Hardware security keys (YubiKey) for critical accounts
Residual Risk Score: 6 (Medium - accepted) Status: Mitigated, annual training
RISK-2025-M004: Insufficient Incident Detection
| Attribute | Value |
|---|---|
| Category | Operational |
| Description | Security incidents occur but aren’t detected promptly, allowing prolonged compromise |
| Impact | Moderate (3) - Delayed response increases damage |
| Likelihood | Possible (3) - Detection is challenging without dedicated SOC |
| Inherent Risk Score | 9 (Medium) |
| Treatment | Mitigate |
Current Controls:
- Structured audit logging (security events in KV)
- Cloudflare Workers Logs (shipped to Grafana Loki) for request patterns
- Rate limiting and ban lists (suspicious behaviour)
- GitHub security alerts for code vulnerabilities
- Incident Response Plan with detection procedures
Planned Improvements:
- Implement automated alerting for anomalous patterns
- Weekly review of audit logs
- Consider SIEM solution for centralized monitoring
Residual Risk Score: 6 (Medium - accepted) Status: Partial mitigation, improvement planned
RISK-2025-M005: Inadequate Backup/Recovery
| Attribute | Value |
|---|---|
| Category | Operational |
| Description | Critical configuration or key material lost without adequate backup, preventing service restoration |
| Impact | Moderate (3) - Service disruption until recreated |
| Likelihood | Rare (1) - automated backup system now operational |
| Inherent Risk Score | 6 (Medium) |
| Treatment | Mitigate |
Current Controls:
- Cloudflare KV automatic replication across regions
- Source code versioned in GitHub (multiple clones)
- Infrastructure as code (wrangler.toml in version control)
- Backup and Recovery Procedures documented
- Signing keys stored in multiple KV namespaces (production, development)
- Automated provii-backup fully operational with scheduled backups:
- Hourly full backups (all KV keys)
- Daily full snapshots (2am UTC)
- Weekly complete backups (Sunday 3am UTC)
- Coverage: 30 KV namespaces, 9 Durable Objects, 2 R2 buckets
- AES-256-GCM encryption at rest, 70-80% compression ratio
- RPO: under 1 hour, RTO: under 4 hours
- Storage: Cloudflare R2 (geo-distributed)
Planned Improvements:
- Test recovery procedures annually
Residual Risk Score: 2 (Low - accepted) Status: Strong mitigation via automated provii-backup
RISK-2026-M006: Intellectual Property Deadline Lapse
| Attribute | Value |
|---|---|
| Category | Legal / Organisational |
| Description | Critical IP deadlines missed (PCT patent filing, trade mark renewals, domain renewals), resulting in loss of rights or protection gaps |
| Impact | Major (4) - Loss of patent priority, trade mark rights, or domain to third party |
| Likelihood | Unlikely (2) - Deadlines documented and tracked, but single-person dependency |
| Inherent Risk Score | 8 (Medium) |
| Treatment | Mitigate |
Current Controls:
- IP Register maintained in provii-admin with all deadlines documented
- IP assets tracked in Asset Register
- Key dates: PCT filing by 2027-02-26, trade mark maintenance per IP Australia schedule, annual domain renewals
- Calendar reminders for upcoming deadlines
Planned Improvements:
- Engage patent attorney for PCT filing management
- Automated domain renewal where possible
- Calendar reminders plus the deadline register in the Business Continuity Plan
Residual Risk Score: 4 (Medium - accepted) Status: Mitigated, monitoring
RISK-2026-DOCS-M01: Shared Sandbox Attestation Replay Across Sessions
| Attribute | Value |
|---|---|
| Category | Application / Cryptographic |
| Description | The docs sandbox uses a shared issuer identity (CRYPTO-003) to mint attestations across the developer fleet. A captured DobAttestation from one developer session could in principle be replayed against a verifier API call attached to a different session_id or client_id if the binding check is weak, yielding a successful sandbox verification without legitimate possession of the issuing session |
| Impact | Moderate (3). Sandbox credit consumption attributed to the wrong session; weakened audit attribution; no production exposure |
| Likelihood | Possible (3). Replay tooling is trivial once a network response is captured |
| Inherent Risk Score | 9 (Medium) |
| Treatment | Mitigate |
Current Controls:
- Each attestation cryptographically binds
session_idandclient_idinto the signed payload; a replayed attestation against a different session is rejected at signature-verification time - Verifier nonces have a 5-minute TTL, capping the replay window
- Replay attempts surface as audit-log anomalies in the weekly security review queue
- Per-session and per-IP rate limits cap the value of any successful replay
Planned Improvements:
- Add a verifier-side nullifier check on the
(session_id, attestation_id)pair to detect cross-session replay deterministically
SOA Cross-References: A.8.5 (Secure Authentication), A.8.24 (Use of Cryptography), A.8.16 (Monitoring Activities)
Related DPIA: Docs Sandbox DPIA (Risk R-7)
Owner: ISMS Owner Residual Risk Score: 4 (Low) Status: Mitigated, audit-log review
RISK-2026-DOCS-M02: Bot Fight Mode Passive Bypass by Patient Bot Farm
| Attribute | Value |
|---|---|
| Category | Operational / Abuse Prevention |
| Description | Cloudflare Bot Fight Mode and WAF managed challenges filter most automated traffic, but a patient bot farm running headless browsers with low request rates, and residential proxy IP rotation could exhaust shared sandbox issuer credit over time without triggering the per-IP rate-limit thresholds |
| Impact | Moderate (3). Sandbox credit exhaustion degrades developer experience; potential for the fleet to be re-provisioned with new sandbox issuer identity; no production exposure |
| Likelihood | Possible (3). The economic cost of running this attack against a free sandbox is low; the surface is publicly disclosed as part of developer documentation |
| Inherent Risk Score | 9 (Medium) |
| Treatment | Mitigate |
Current Controls:
- Cloudflare Bot Fight Mode active on the docs origin
- Cloudflare managed challenge gate on credential-mint endpoints (
POST /api/credentials/issuerand the verifier-credential mint route) - Per-IP and per-session rate limits via KV-backed counters
- KV-sweep response procedure:
wrangler kv:key list --remote --prefix docs-sbx-followed by sweep delete - Quarterly rotation of the shared sandbox issuer identity (CRYPTO-003) limits the cumulative blast radius of a successful exhaustion campaign
Planned Improvements:
- Add anomaly detection on
(unique-IPs / unique-sessions / mint-rate)ratios - Consider Cloudflare Managed Challenge in front of mint endpoints in addition to Cloudflare managed challenge
SOA Cross-References: A.5.7 (Threat Intelligence), A.8.7 (Protection Against Malware), A.8.16 (Monitoring Activities), A.8.23 (Web Filtering)
Related DPIA: Docs Sandbox DPIA (Risk R-6)
Owner: ISMS Owner Residual Risk Score: 4 (Low) Status: Mitigated, monitoring
RISK-2026-DOCS-M03: Mobile Sandbox Abuse at Scale via Residential Proxies
| Attribute | Value |
|---|---|
| Category | Operational / Abuse Prevention |
| Description | The mobile sandbox issuer allowlist SANDBOX_MOBILE_ISSUERS (KV-007) holds mwallet-sbx-* issuer client IDs minted for wallet developers under Decision 13. A coordinated abuse campaign using residential proxy networks could mint a high volume of mwallet-sbx-* entries, exhausting the mobile sandbox credit pool and impairing legitimate wallet developer onboarding |
| Impact | Moderate (3). Mobile sandbox developer experience degraded; KV growth on SANDBOX_MOBILE_ISSUERS; sweep response required |
| Likelihood | Possible (3). Residential proxy services are commoditised; the mobile install surface is the most exposed path |
| Inherent Risk Score | 9 (Medium) |
| Treatment | Mitigate |
Current Controls:
- 7-day TTL on
mwallet-sbx-*install entries (per Decision 13) - Per-install rate limits enforced at mint
- KV-sweep response procedure:
wrangler kv:key list --remote --prefix mwallet-sbx-followed by sweep delete - Allowlist deliberately disjoint from
SANDBOX_DOCS_ISSUERSso a mobile-side compromise does not force a browser-wide credential wipe and vice versa - Quarterly rotation of the shared sandbox issuer identity (CRYPTO-003)
Planned Improvements:
- Per-AS-number mint-rate ceilings to suppress proxy-network bursts
- Telemetry on the
(install-rate / unique-IPs)ratio with alerting
SOA Cross-References: A.8.7 (Protection Against Malware), A.8.16 (Monitoring Activities), A.8.23 (Web Filtering)
Related DPIA: Docs Sandbox DPIA (Risk R-10)
Owner: ISMS Owner Residual Risk Score: 4 (Low) Status: Mitigated, monitoring
RISK-2026-DOCS-M04: Handler Blast Radius on Shared Worker
| Attribute | Value |
|---|---|
| Category | Application / Architecture |
| Description | The docs sandbox gateway runs in the same Cloudflare Worker (provii-demos/demo-web-provii-agegate) as the existing demo agegate handler, sharing memory isolate boundaries within a Worker invocation. A handler bug in one route. for example, a Promise rejection that leaks a partially-constructed AttestationSigner closure into a subsequent invocation, or a request-context bleed across coalesced edge-cache lookups. could cross-contaminate the docs gateway with demo agegate state or vice versa |
| Impact | Moderate (3). Cross-handler state leakage could weaken the disjoint-key-material guarantee or expose demo session state to the docs gateway audit log |
| Likelihood | Possible (3). Worker isolate semantics make full cross-invocation isolation an architectural property of the runtime, not a property the handler can enforce; handler bugs in async code paths are the realistic vector |
| Inherent Risk Score | 9 (Medium) |
| Treatment | Mitigate |
Current Controls:
- Narrowed
DocsEnvbinding excludesDEMO_TOKEN_SECRETand the playground KVs, so the docs handler cannot access demo state even if a state-bleed occurred - Host-and-path guard at the Worker entry routes
docs.provii.app/api/*to the docs handler exclusively; demo and docs paths cannot be confused at routing time AttestationSigneris constructed per-invocation and held only inside a single closure; no static or module-level retention of seed material- Edge cache (
caches.default) is keyed on challenge ID with a 2-second TTL (30 seconds for terminal states), bounding the coalescing window - Code review gate on any change touching either handler requires explicit confirmation that the binding-set narrowing is preserved
Planned Improvements:
- Migrate the docs gateway to its own Worker once the developer onboarding traffic justifies the deployment overhead
- Add an integration test that verifies the demo handler cannot reach docs KV namespaces and vice versa
SOA Cross-References: A.8.27 (Secure System Architecture and Engineering), A.8.31 (Separation of Development, Test, Production), A.8.25 (Secure Development Lifecycle)
Related DPIA: Docs Sandbox DPIA
Owner: ISMS Owner Residual Risk Score: 4 (Low) Status: Mitigated, separation planned
RISK-2026-DOCS-M05: Scalar Supply Chain Compromise via npm
| Attribute | Value |
|---|---|
| Category | Supply Chain |
| Description | The docs site embeds the Scalar API explorer for the interactive API reference. Scalar is delivered via npm and pulled into the docs build at deploy time. A malicious release of an upstream Scalar package, or a transitive dependency takeover, could ship attacker-controlled JavaScript into the docs origin. overlapping with RISK-2026-DOCS-H01 (token exfiltration) but distinct in that it captures the full software-supply-chain class for the docs interactive surface |
| Impact | Moderate (3). Same blast radius as H01 for sandbox bearer tokens; additional risk of degrading developer trust if the docs origin ships compromised script |
| Likelihood | Possible (3). Developer-tooling npm packages are recurring supply-chain attack targets |
| Inherent Risk Score | 9 (Medium) |
| Treatment | Mitigate |
Current Controls:
npm auditand Dependabot enabled on the docs site repository- Strict CSP on the docs origin restricting script-src
- Subresource Integrity on Scalar bundle delivery
- ISMS Owner review on any change touching
package.jsonor the lockfile for the docs site (sole-operator; two-reviewer policy is a noted gap) - Cargo.lock and package-lock.json hermetic-build posture across the provii repos
Planned Improvements:
- Pin Scalar to a known-good version with a hash check in CI
- Subscribe to the Scalar release feed for early signal on suspicious version cadence
- Evaluate Socket.dev or equivalent supply-chain telemetry on the docs site dependency tree
SOA Cross-References: A.5.21 (ICT Supply Chain Security), A.5.22 (Monitoring, Review, Change Management of Supplier Services), A.8.7 (Protection Against Malware), A.8.28 (Secure Coding)
Related DPIA: Docs Sandbox DPIA (Risk R-4)
Owner: ISMS Owner Residual Risk Score: 4 (Low) Status: Mitigated, monitoring
Low Risks
RISK-2025-L001: DDoS Attack on Public APIs
| Attribute | Value |
|---|---|
| Category | Infrastructure |
| Description | Distributed denial of service attack targeting verifier or issuer APIs |
| Impact | Minor (2) - Temporary service degradation |
| Likelihood | Likely (4) - DDoS attacks are common on public services |
| Inherent Risk Score | 8 (Medium initially) |
| Treatment | Mitigate |
Current Controls:
- Cloudflare’s DDoS protection (included in Workers)
- Per-customer hourly rate limiting via KV counters (tier-based, fail-open)
- Origin IP obfuscation through Cloudflare edge
- Automatic scaling of Workers
Residual Risk Score: 2 (Low - accepted) Status: Strong mitigation via Cloudflare
RISK-2025-L002: Insider Threat (Malicious)
| Attribute | Value |
|---|---|
| Category | Human |
| Description | Team member intentionally compromises security or steals secrets |
| Impact | Major (4) - Could compromise keys or insert backdoors |
| Likelihood | Rare (1) - Sole operator; trusted individual |
| Inherent Risk Score | 4 (Low) |
| Treatment | Accept + Monitoring |
Current Controls:
- Background checks during hiring
- Code review requirements (all changes reviewed)
- Audit logging for sensitive operations
- Principle of least privilege
- Separation of duties where possible (limited as a sole operator)
Rationale for Acceptance:
- Sole operator makes traditional insider threat controls less applicable
- Cost of additional controls (e.g., security clearances) exceeds benefit
- Audit trail provides detection capability
Residual Risk Score: 4 (Low - accepted) Status: Accepted with logging
RISK-2025-L003: Certificate Expiration
| Attribute | Value |
|---|---|
| Category | Operational |
| Description | TLS certificates or signing keys expire, causing service disruption |
| Impact | Minor (2) - Brief outage until renewed |
| Likelihood | Unlikely (2) - Cloudflare manages TLS automatically, but other certs exist |
| Inherent Risk Score | 4 (Low) |
| Treatment | Mitigate |
Current Controls:
- Cloudflare manages TLS certificates automatically (Let’s Encrypt with auto-renewal)
- Calendar reminders for credential rotations
- Monitoring for certificate expiration dates
- Documentation of renewal procedures
Residual Risk Score: 2 (Low - accepted) Status: Automated where possible
RISK-2025-L004: Documentation Outdated
| Attribute | Value |
|---|---|
| Category | Operational |
| Description | Security procedures or technical documentation becomes outdated, leading to errors |
| Impact | Minor (2) - Confusion, potential misconfigurations |
| Likelihood | Possible (3) - Documentation drift is common |
| Inherent Risk Score | 6 (Medium initially) |
| Treatment | Mitigate |
Current Controls:
- Annual review of all ISMS documents
- Review date tracking in document metadata
- Updates triggered by significant changes
- Public documentation enables community corrections
- This ISMS published transparently at maelstrom.au/trust
Residual Risk Score: 3 (Low - accepted) Status: Mitigated through review schedule
RISK-2025-L005: Loss of Key Personnel
| Attribute | Value |
|---|---|
| Category | Organisational |
| Description | Critical knowledge lost if key team member becomes unavailable |
| Impact | Moderate (3) - Temporary capability reduction |
| Likelihood | Unlikely (2) - Sole operator; single-operator bus-factor acknowledged, good documentation |
| Inherent Risk Score | 6 (Medium initially) |
| Treatment | Mitigate |
Current Controls:
- documentation (this ISMS, code comments, README files)
- Transparent, public documentation enables knowledge transfer
- Infrastructure as code (no manual configuration)
- Production access held by the ISMS Owner (sole operator); single-operator bus-factor addressed in the Business Continuity Plan
- Standard tools and practices (no bespoke systems)
Residual Risk Score: 3 (Low - accepted) Status: Mitigated through documentation
RISK-2026-DOCS-L01: Cross-Border Transfer of Developer Pseudonymous Identifiers to Cloudflare Global Edge
| Attribute | Value |
|---|---|
| Category | Privacy / Cross-Border Transfer |
| Description | The docs interactive sandbox is served through Cloudflare’s global network. Developer-side state (the __Host-docs_session identifier, hashed source IP, sandbox credential allowlist entries, challenge state) is handled at the Cloudflare data centre nearest the developer. Where a developer is located in the UK or EEA and traffic terminates outside that territory, the pseudonymous identifiers constitute a restricted international transfer under UK GDPR Article 44 and EU GDPR Chapter V. |
| Impact | Minor (2). Only pseudonymous session identifiers and hashed IP are in scope; no direct identifiers, no DOB, no verification data. Worst case is a regulator finding that the transfer mechanism is inadequate, requiring a change of transfer vehicle or additional TOMs rather than data exposure. |
| Likelihood | Likely (4). Cloudflare’s edge network routinely handles requests outside the UK and EEA, so the transfer occurs on every sandbox session for a developer in those territories. |
| Inherent Risk Score | 8 (Medium initially) |
| Treatment | Mitigate |
Current Controls:
- Cloudflare Data Processing Addendum in force, incorporating the European Commission’s Standard Contractual Clauses under Decision 2021/914 (Module 2, controller to processor) for transfers out of the EEA.
- UK International Data Transfer Addendum in force for transfers out of the UK.
- Supplementary technical measures from Section 6 of the Privacy Policy apply unchanged to the sandbox surface, including HMAC-SHA-256 hashing of source IP at ingest and strictly-necessary cookie scoping under
__Host-prefix. - Transfer scope is minimised to pseudonymous identifiers and hashed IP; no raw IP, no DOB, and no customer personal data crosses the border through the docs sandbox.
- Transfer Impact Assessment covered by Section 4 of the ROPA, Activities 2.5 and 2.6.
- Contractual scope for the transfer is set out in the DPA Docs Sandbox Addendum Section 6 (Cross-Border Processing).
- Developer-facing disclosure in the Developer Privacy Notice Section 6.
Planned Improvements:
- Quarterly check against the Cloudflare sub-processor list for changes affecting the transfer route.
- Review the Transfer Impact Assessment when the Docs Sandbox DPIA is reassessed (the R-8 trigger list applies).
SOA Cross-References: A.5.14 (Information Transfer), A.5.34 (Privacy and Protection of PII), ISO 27701:2019 A.7.5.1 and A.7.5.3 (Basis for transfer of PII between jurisdictions; Countries and international organisations to which PII can be transferred).
Related DPIA: Docs Sandbox DPIA (Risk R-8)
Owner: ISMS Owner Residual Risk Score: 3 (Low) Status: Mitigated, monitoring
Accepted Risks
The following risks are formally accepted as within our risk appetite:
| Risk ID | Description | Residual Score | Justification |
|---|---|---|---|
| RISK-2025-M001 | Cloudflare service disruption | 8 (Medium) | Beyond our control; Cloudflare provides best-in-class reliability |
| RISK-2025-L002 | Insider threat (malicious) | 4 (Low) | Sole operator; audit logging provides detection |
| All Low Risks | Various low-priority risks | ≤4 | Cost of further mitigation exceeds benefit |
Approved By: ISMS Owner Approval Date: 2026-02-13
Risk Treatment Status
Completed Treatments (14)
✅ SLSA Level 3 supply chain security ✅ Cloudflare DDoS protection ✅ HMAC API authentication ✅ Audit logging implementation ✅ Code review requirements ✅ Security testing in CI/CD ✅ Multi-factor authentication ✅ Rate limiting implementation ✅ Incident response procedures ✅ Business continuity planning ✅ Backup and recovery procedures ✅ Documentation and transparency ✅ Zero knowledge architecture (minimal PII processing. DOB processed ephemerally during issuance only) ✅ Automated KV backup exports (provii-backup)
In Progress (2)
🔄 Hardware security keys for critical accounts 🔄 Weekly audit log review process
Planned (5)
📋 HSM evaluation (when key management requirements grow) 📋 SBOM generation 📋 Automated security patch PRs (Dependabot) 📋 SIEM evaluation (as operational scale increases) 📋 Annual disaster recovery testing
Monitoring and Review
Key Risk Indicators (KRIs)
We monitor these indicators for early warning signs:
| Indicator | Threshold | Monitoring Frequency |
|---|---|---|
| Failed authentication attempts | >10/hour per IP | Real-time (rate limiter) |
| HIGH/CRITICAL vulnerabilities in dependencies | >0 | Daily (CI/CD) |
| API error rate | >1% | Real-time (Workers Logs in Grafana Loki) |
| Service availability | <99.9% | Real-time (Cloudflare monitoring) |
| Signing key access events | Any unexpected access | Daily (audit log review) |
| GitHub security alerts | Any new alert | Real-time (email notifications) |
Review Schedule
Weekly: Review KRIs, assess new vulnerabilities Monthly: Dependency security review, access audit Quarterly: Full risk register review, update risk scores Annually: Complete risk assessment, methodology review
Next Quarterly Review: 2026-05-13 Next Annual Assessment: 2027-02-13
Changes Since Last Review
Version 2.0. February 2026 Quarterly Review
- RISK-2025-M005 (Inadequate Backup/Recovery): Residual risk reduced from 4 to 2. Likelihood downgraded from Unlikely (2) to Rare (1). Backup-worker is now fully operational with hourly full, daily full, and weekly complete backups covering 30 KV namespaces, 9 Durable Objects, and 2 R2 buckets.
- “Automated KV backup exports” moved from In Progress to Completed Treatments.
- Risk register reviewed and updated February 2026. All risk scores reviewed; no changes to inherent risk scores.
- No new risks identified during this review period.
- All other residual risk scores confirmed as appropriate; no changes required.
Version 2.1. February 2026 Update
- RISK-2026-M006 (IP Deadline Lapse): New medium risk added. Provisional patent (AU 2026901546) and trade mark (PROVII WALLET) filed; deadlines now require active tracking.
- Medium/Low summary updated to reflect new risk (9 Mitigated).
Version 2.2. April 2026 Update (Docs Sandbox Phase 0A)
- Nine new risks added covering the docs interactive sandbox surface introduced in Phase 0A of the docs DX uplift programme:
- High. RISK-2026-DOCS-H01 (bearer token XSS via Scalar supply chain), RISK-2026-DOCS-H02 (
DOCS_SESSION_HMAC_KEYleak forges sessions), RISK-2026-DOCS-H03 (sandbox feature flag hygiene under Rust workspace resolver). - Medium. RISK-2026-DOCS-M01 (shared sandbox attestation replay across sessions), RISK-2026-DOCS-M02 (Bot Fight Mode passive bypass by patient bot farm), RISK-2026-DOCS-M03 (mobile sandbox abuse at scale via residential proxies), RISK-2026-DOCS-M04 (handler blast radius on shared Worker), RISK-2026-DOCS-M05 (Scalar supply chain compromise via npm).
- Low. RISK-2026-DOCS-L01 (cross-border transfer of developer pseudonymous identifiers to Cloudflare global edge), cross-referenced to DPIA risk R-8.
- Each entry cross-references the Docs Sandbox DPIA and the relevant SOA Annex A controls. Entries covering cross-border processing also cross-reference ISO 27701:2019 A.7.5.1 and A.7.5.3.
- Risk summary card counts updated: High 2 → 5, Medium/Low 9 mitigated → 15 mitigated.
Related Documents
- Risk Assessment Methodology - How we assess risks
- Statement of Applicability - Controls implementing risk treatments
- Incident Response - Responding to risk materialization
- Business Continuity - Continuity planning for major risks
Document Information
- Version. 2.3
- Last Assessment Date. 2026-05-21
- Next Review Date. 2026-11-21 (Quarterly)
- Owner. ISMS Owner
- Approved By. ISMS Owner
- Approval Date. 2026-04-13
- Classification. Public