Risk Register
Risk register
Status: operative document. Version 1.1, 2026-09-28. 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 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 inaccurately (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 off-site backups with a published restore procedure (backup and recovery statement); a file-level restore drill was performed on 2026-09-27 and the database path was restored with point-in-time recovery on 2026-09-28, and the drills are not yet on a cycle; a silent stop of the backup is caught by review, not by an alert | 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 and a file-level restore has been exercised, as has a physical restore of the database path with point-in-time recovery; 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. |
| 2026-09-28 | 1.1 | R-07 and R-08 mitigation text now records the database path’s physical restore with point-in-time recovery (both database hosts, 2026-09-28) beside the 2026-09-27 file-level drill. No likelihood, impact or residual score moved. |