Risk register
Status: operative document. Version 1.0, 2026-09-18. Owner: Yannick M. Richard. Review cycle: quarterly, or on material change. Companion to the ISMS scope statement. Not a certification document; we hold no certificate. See Standards.
1. Method
Risks are identified against the assets and processes defined in the scope statement, assessed as likelihood and impact on a 1–5 scale each, and scored as their product (1–25). Scoring is deliberately coarse: this register is maintained by one person and a finer scale would imply a precision the assessments do not have.
Treatment options: mitigate (a control reduces it), accept (recorded and carried knowingly), transfer (insurance or contract), avoid (the activity is not performed).
Residual risk is the score remaining after the stated controls. Because the operator is a single individual, several risks that a larger organisation would mitigate by separation of duties are shown as accepted with a compensating control instead. That is recorded honestly rather than hidden behind a paper control.
2. Register
| ID | Risk | Asset / process | L | I | Inherent | Treatment | Controls in place | Residual |
|---|---|---|---|---|---|---|---|---|
| R-01 | Unauthorised access to production hosts | vpn, public, mail | 2 | 5 | 10 | mitigate | SSH key-only authentication; no password auth; access restricted by source address (from= pinning); AmneziaWG management mesh; NOPASSWD sudo limited to named operators; firewall default-deny |
2 |
| R-02 | Compromise of the configuration repository or CI pipeline | Config source, deploy path | 2 | 5 | 10 | mitigate | Public repo with review required; PR-gated CI; secret scanning (gitleaks) on every change; deployment health gate with automatic rollback; secrets held in SOPS/age, not in the repo | 4 |
| R-03 | Leakage of customer traffic metadata (the product’s core promise) | Customer traffic | 3 | 5 | 15 | mitigate | Architecturally not retained; no-log invariants re-asserted daily on-host by the audit; a live canary query is sent and must not appear in any log; published signed report re-asserting this | 2 |
| R-04 | Silent failure of the no-log enforcement (a check stops running and nobody notices) | Evidence systems | 3 | 5 | 15 | mitigate | The audit unit fails non-zero on violation after publishing the signed report, so a violated report exists publicly; the daily series is dated and frozen monthly; a missing day is visible as a gap | 3 |
| R-05 | The audit reports on itself dishonestly (generator compromised) | Evidence systems | 2 | 4 | 8 | accept + mitigate | Accepted: the audit runs on the hosts it audits and a full host compromise could forge a report. Compensating: reports are signed, dated, mirrored off-host, hash-chained per month; the generator is not public source and that limit is published | 8 |
| R-06 | Loss of the signing key or its unauthorised use | Cryptographic key material | 2 | 4 | 8 | mitigate | Key material in the secrets store; fingerprints published so a swap is visible as a diff; key continuity published in the monthly index | 3 |
| R-07 | Loss of customer account or billing records | Account/billing data | 2 | 3 | 6 | mitigate | Encrypted backups; documented restore procedure; recovery drill on the review cycle | 2 |
| R-08 | Host loss / provider outage | All hosts | 3 | 4 | 12 | mitigate + accept | Declarative configuration makes rebuild reproducible from source; backups and disaster-recovery documentation exist; residual accepted: single-provider reliance | 6 |
| R-09 | Supplier dependency failure (hosting, DNS, CA, mail relay) | Supplier relationships | 3 | 3 | 9 | accept | Recorded as dependencies; no contractual SLA available at this scale; the effect is availability, not confidentiality | 9 |
| R-10 | Insider risk — the sole operator | All | 1 | 5 | 5 | accept + mitigate | Accepted: no separation of duties is possible in a one-person operation. Compensating: every change is a signed, reviewed, publicly visible commit; the audit publishes independently of the operator’s intent | 5 |
| R-11 | Phishing / credential theft of the operator | Access credentials | 3 | 5 | 15 | mitigate | Key-only authentication for systems; hardware-backed or passphrase-protected keys; no reuse of credentials between services; MFA on external accounts where offered | 4 |
| R-12 | Regulatory non-compliance in data handling | Personal data | 2 | 4 | 8 | mitigate | Published data inventory and privacy notice; data minimisation by design; documented handling of access requests | 3 |
| R-13 | Unpatched vulnerability in fleet software | Fleet hosts | 4 | 4 | 16 | mitigate | Declarative configuration with pinned inputs; automated build checks; weekly dependency update process with a minimum-age policy for upstream inputs | 5 |
| R-14 | Loss of documentation / key-person dependency | ISMS itself | 3 | 3 | 9 | mitigate | Every procedure documented in version-controlled markdown alongside the configuration it governs; disaster-recovery documentation | 3 |
| R-15 | Change to the no-log posture made quietly | Customer trust | 2 | 5 | 10 | mitigate | Such a change would require a commit to the public configuration and would break the signed daily audit; the audit’s generator enforces the invariants rather than trusting configuration alone | 2 |
3. Risk acceptance
Risks R-05, R-09 and R-10 are formally accepted by the operator with the compensating controls stated above. They are not closed, and they are not presented as mitigated when they are not. This section exists so that a reviewer can see which risks are being carried knowingly rather than missed.
4. Review
This register is reviewed quarterly and on any material change to the fleet, the service, or the threat environment. Each review records the date, the changes made, and the risks whose scores moved.
| Date | Version | Change |
|---|---|---|
| 2026-09-18 | 1.0 | Initial register; 15 risks identified and assessed. |