Risk Treatment Plan

Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027

1. Purpose

This document is the controlled Risk Treatment Plan required by ISO/IEC 27001:2022 Clause 6.1.3. It states the methodology by which Glassbreak identifies, analyses, and treats information-security risks; the categories under which risks are considered; the treatment options available; and the current register of treated risks with their owners, treatment decisions, and target dates.

The plan operates within the boundaries of the ISMS Scope and references the controls catalogued in the Statement of Applicability.

2. Methodology

2.1 Risk identification

  • The ISMS maintains a continuous risk register. New risks are surfaced from: the annual security audit (most recent: 27 May 2026), incident post-mortems, sub-processor notifications, customer feedback, coordinated-disclosure reports, vulnerability scanning, and architecture review.
  • Identification is scoped to information assets defined in /policies/isms-scope section 6.
  • Each identified risk is recorded with a unique identifier, a plain-language description, the affected asset class, and the threat-actor or scenario it relates to.

2.2 Risk analysis

Risks are analysed qualitatively using a two-dimensional scale of likelihood and impact. Quantitative loss modelling is used only for risks with material financial exposure where it materially changes the treatment decision.

2.3 Likelihood scale

  • L1 — Rare — would only occur in exceptional circumstances; no precedent and no specific indicator that it could happen this year.
  • L2 — Unlikely — could occur at some point but is not expected; no current indicator.
  • L3 — Possible — could occur once over a multi-year window; consistent with industry base rates.
  • L4 — Likely — expected to occur within the annual review window.
  • L5 — Almost certain — expected to occur multiple times within the annual review window or is already occurring.

2.4 Impact scale

  • I1 — Negligible — no measurable customer impact; remediated within an on-call shift.
  • I2 — Minor — measurable but contained customer impact; remediated within a working day; no notifiable breach.
  • I3 — Moderate — single-vertical degradation or a contained data-handling deviation; possible customer-notification obligation; SEV-3 in the Incident Response Policy.
  • I4 — Major — material loss of availability, confirmed exposure of administrative metadata, or a sub-processor compromise affecting one stack; SEV-2.
  • I5 — Severe— confirmed exposure of customer plaintext (only possible through compromise of the customer's own keys), large-scale loss of integrity of the audit log, or unrecoverable data loss; SEV-1.

2.5 Risk rating

The residual risk rating is the product of residual likelihood and residual impact after current controls. Ratings are expressed as L×I (e.g., L3 × I4 = Moderate-Major) and bucketed into:

  • Low (L1×I1 to L2×I2) — treatment by monitoring; accepted unless cheap to mitigate further.
  • Moderate (L2×I3 to L3×I3) — treatment by mitigation where reasonable; otherwise accepted with documented rationale.
  • High (L3×I4 to L4×I3) — treatment is required; if not currently treated, a target date is set and the risk is tracked at every quarterly review.
  • Severe (L4×I4 and above) — treatment is required immediately; the risk is escalated to leadership and remains an active workstream until reduced.

2.6 Risk categories

Every risk is classified along two dimensions: the security property primarily threatened and the asset class affected.

  • Security property: confidentiality (C), integrity (I), availability (A), or a combination (e.g., C+I).
  • Asset class from /policies/isms-scope section 6: Customer plaintext (P), customer ciphertext and metadata (CT), account/contact data (A), cryptographic key material (K), audit and observability data (L), workforce and business records (W), source code and IaC (S).

3. Treatment options

The treatment options recognised by this plan, applied per ISO 27005 guidance:

  • Mitigate — reduce the likelihood, the impact, or both by applying controls. The default for any risk with residual rating Moderate or above.
  • Accept — record and accept the residual risk where treatment is impossible, disproportionate, or already reduced to the lowest reasonable level. Acceptance requires leadership approval for ratings above Moderate and is reviewed at every annual review.
  • Transfer — shift the risk to another party, typically a sub-processor with stronger controls or insurance. Transfer does not absolve Glassbreak of accountability to its customers.
  • Avoid — eliminate the source of the risk by removing the affected activity, technology, or relationship. Used where treatment cost is high relative to the value of the underlying activity.

4. Roles

  • Risk owner — the individual accountable for the treatment of the risk. Typically the Security Officer for risks affecting the platform; the relevant functional lead otherwise.
  • Security Officer — accountable for the operation of the Risk Treatment Plan as a whole, the register, and the quarterly review cycle.
  • Leadership — approves the plan, the risk appetite, and the acceptance of any risk rated High or Severe.

5. Review cadence

  • The register is reviewed at least quarterly. Treatment decisions and target dates are updated.
  • The plan as a whole is reviewed at least annually as part of the ISMS management review.
  • An additional ad-hoc review is triggered by: any SEV-1 or SEV-2 incident, any material change to the architecture or sub-processor mix, any newly identified risk rated High or above, or any external assessment that surfaces a previously unrecognised risk.

6. Risk register — representative entries

The entries below are the representative set drawn from the operational risk register as of the effective date. They are drawn from the May 2026 internal audit and the operational experience of running the platform across two compute stacks. The internal operational register may carry additional entries with non-public detail; the published set covers all material categories.

6.1 R-01 — Compromise of a sub-processor with production access

  • Description. A sub-processor with access to Glassbreak customer ciphertext or metadata suffers a security breach that exposes their internal control surface.
  • Category. Confidentiality + Integrity; CT, L.
  • Current controls. Two independent compute and storage stacks with no shared queue; sub-processors held to documented attestations (SOC 2 / ISO 27001); customer plaintext encrypted client-side before any sub-processor sees it; cross-vertical sync is HMAC-signed.
  • Residual likelihood. L2.
  • Residual impact. I3.
  • Residual rating. Moderate.
  • Treatment. Mitigate. Maintain dual-stack architecture; quarterly review of sub-processor attestation currency; documented switch-out plan per sub-processor in the Supply Chain Risk Management Plan.
  • Owner. Security Officer.
  • Target. Continuous; reviewed quarterly.

6.2 R-02 — Compromise of a production cryptographic signing key

  • Description. An EdDSA JWT signing key for one vertical, or a cross-vertical HMAC key, is exposed or suspected exposed.
  • Category. Integrity + Confidentiality; K.
  • Current controls. Per-vertical signing keys with kid-driven verify map (rotation runbook at docs/operator-jwt-per-vertical.md); HMAC keys rotate on a documented schedule;token_version bump invalidates outstanding tokens; DR scenario 7 exercises the rotation path; secrets held in approved stores only.
  • Residual likelihood. L2.
  • Residual impact. I4.
  • Residual rating. High.
  • Treatment. Mitigate. Quarterly rehearsal of rotation; expand DR scenario 18 to cover end-to-end secrets rotation across both verticals (target tracked in operational backlog).
  • Owner. Security Officer.
  • Target. Continuous; next rehearsal at quarterly review.

6.3 R-03 — Loss of availability of both compute stacks simultaneously

  • Description. AWS and Scaleway are concurrently unavailable, either through a shared dependency, a coordinated attack, or coincidental independent outage.
  • Category. Availability; CT, A.
  • Current controls. Two independent compute stacks with no shared cloud provider, no shared region, no shared queue; direct-backup surfaces (glassbreak.cloud, glass-break.com) bypass Fastly entirely; dual DNS authority on every domain.
  • Residual likelihood. L1.
  • Residual impact. I5.
  • Residual rating. Moderate.
  • Treatment. Mitigate further by adding a third compute stack (Phase 8 hard-disconnect path on glassbreak.dev on Fly.io or GCP). Tracked in the architecture plan, not on the ISMS critical path.
  • Owner. Engineering.
  • Target. Phase 8 (architecture roadmap).

6.4 R-04 — Insider misuse of admin access

  • Description. A workforce member with legitimate admin access uses that access for an unauthorised purpose (curiosity, harassment, exfiltration).
  • Category. Confidentiality + Integrity; CT, A, L.
  • Current controls. Least-privilege admin grants in the access register; MFA on every admin action; admin-action audit log; quarterly access review; sanctions procedure at /policies/sanctions; background-check requirement at /policies/onboarding section 3.2; cryptographic design means Glassbreak administrators cannot read customer plaintext at all.
  • Residual likelihood. L2.
  • Residual impact. I3.
  • Residual rating. Moderate.
  • Treatment. Mitigate. Operationalise just-in-time elevation; close known gaps in admin impersonation logging (audit findings C-3, C-4).
  • Owner. Security Officer.
  • Target. Q3 2026 for the impersonation log hardening; continuous for the standing controls.

6.5 R-05 — Tampering with the audit log

  • Description. An attacker or insider modifies audit-log entries to conceal a prior action.
  • Category. Integrity; L.
  • Current controls. Append-only audit table with database-level controls; observability logs replicated out of the application plane to Grafana Cloud; modification of audit log entries is itself a Gross-category sanctions violation; DR scenario 16 exercises audit chain integrity.
  • Residual likelihood. L2.
  • Residual impact. I4.
  • Residual rating. High.
  • Treatment. Mitigate. Implement a tamper-evident chain (cryptographic chaining of audit entries) for the admin-action audit log; document in the Audit-log Retention Policy.
  • Owner. Engineering.
  • Target. Q4 2026.

6.6 R-06 — Compromise of the source-code or CI/CD supply chain

  • Description. Malicious code is introduced via a compromised dependency, a compromised GitHub Action, or a compromised maintainer account.
  • Category. Integrity; S, CT.
  • Current controls. Lockfiles for npm dependencies; Dependabot; branch protection on main; mandatory PR review; OpenTofu plan-and-review; CI-only deployment; hardware-key 2FA on GitHub admin accounts; OpenTofu state encrypted; CI tokens scoped narrowly.
  • Residual likelihood. L2.
  • Residual impact. I4.
  • Residual rating. High.
  • Treatment. Mitigate. Add SBOM generation and publication; pin GitHub Actions to commit hashes for third-party actions; expand the Supply Chain Risk Management Plan with explicit triggers for review.
  • Owner. Engineering.
  • Target. Q3 2026 for SBOM; Q4 2026 for Action pinning.

6.7 R-07 — Account takeover of a customer organisation owner

  • Description.An attacker takes over the owner account of a customer organisation through credential stuffing, phishing, or session theft, and uses that privilege to exfiltrate ciphertext or invite themselves further into the customer's data.
  • Category. Confidentiality + Integrity; CT, A.
  • Current controls. Argon2id password hashing; TOTP and WebAuthn MFA; refresh-token rotation with family-based reuse detection; rate-limiting; audit log of administrative actions; in-product notification to existing members on owner changes.
  • Residual likelihood. L3.
  • Residual impact. I3.
  • Residual rating. Moderate.
  • Treatment. Mitigate further. Make MFA enforcement a tenant-level requirement that customer admins can mandate for their members; expand step-up authentication on high-blast-radius actions.
  • Owner. Engineering.
  • Target. Continuous; enforcement tooling tracked on product roadmap.

6.8 R-08 — Loss of customer ciphertext via storage failure

  • Description. Permanent loss of customer ciphertext through storage corruption, deletion, or sub-processor failure.
  • Category. Availability; CT.
  • Current controls. Per-vertical storage on independent providers; cross-vertical replication for the storage classes that support it; backup retention (Neon point-in-time recovery up to 30 days; Scaleway managed daily + weekly + monthly snapshots); nightly backup integrity verification (DR scenario 22).
  • Residual likelihood. L2.
  • Residual impact. I4.
  • Residual rating. High.
  • Treatment. Mitigate. Extend backup long-tail retention; document customer-facing recovery SLA in /policies/business-continuity.
  • Owner. Engineering.
  • Target. Q3 2026 for retention extension.

6.9 R-09 — Loss of a domain registrar account

  • Description. Compromise or loss of the registrar account holding a production domain results in NS-record manipulation and subsequent traffic interception or service loss.
  • Category. Confidentiality + Availability; CT, A.
  • Current controls. Hardware-key 2FA on the registrar account; registrar lock on every domain; auto-renew enabled with backup payment method; multi-registrar diversity (Porkbun + Gandi + DNSimple across three production domains); dual DNS authority on every domain.
  • Residual likelihood. L1.
  • Residual impact. I4.
  • Residual rating. Moderate.
  • Treatment. Mitigate. Annual registrar account audit; future fourth registrar for glassbreak.dev Phase 8.
  • Owner. Security Officer.
  • Target. Annual audit; Phase 8 for fourth registrar.

6.10 R-10 — Sub-processor processing of personal data outside the agreed jurisdiction

  • Description. A sub-processor processes personal data outside the jurisdiction declared in the sub-processor list and the DPA.
  • Category. Confidentiality (legal); A.
  • Current controls. Sub-processor list at /legal/sub-processors with declared location; DPA addenda for SCCs / IDTA / FADP; EU-only direct path at glassbreak.cloud for EU-headquartered buyers with a Schrems-II concern; contractual restriction in sub-processor onboarding.
  • Residual likelihood. L2.
  • Residual impact. I3.
  • Residual rating. Moderate.
  • Treatment. Mitigate. Annual sub-processor re-attestation; track sub-processor jurisdictional change notices as a watch item.
  • Owner. Security Officer.
  • Target. Annual cycle.

6.11 R-11 — Workforce phishing leading to credential compromise

  • Description. A workforce member is successfully phished and reveals credentials with production access.
  • Category. Confidentiality + Integrity; K, L, CT.
  • Current controls. Hardware-key MFA where available; phishing-resistant WebAuthn for high-value accounts; mandatory security awareness training on joining and annually thereafter; password-manager standard; the Acceptable Use Standard prohibits credential reuse and forwarding.
  • Residual likelihood. L3.
  • Residual impact. I3.
  • Residual rating. Moderate.
  • Treatment. Mitigate. Phishing simulation on the annual training cycle; reduce surface area of accounts that still rely on TOTP rather than WebAuthn.
  • Owner. Security Officer.
  • Target. Q4 2026.

6.12 R-12 — Loss of capability due to single-point dependency on a workforce member

  • Description. Critical operational knowledge or sole-holder access to a system is concentrated in one workforce member and is lost with that member.
  • Category. Availability; W, K.
  • Current controls. Runbooks for every operational task in docs/; secrets held in shared approved stores rather than personal accounts; onboarding pairing requirements; offboarding credential rotation includes any credential the departing member could access.
  • Residual likelihood. L2.
  • Residual impact. I3.
  • Residual rating. Moderate.
  • Treatment. Mitigate. Maintain documented succession for owner-only sub-processor accounts; periodic re-validation that no operational runbook depends on tacit knowledge alone.
  • Owner. Security Officer.
  • Target. Continuous.

6.13 R-13 — Failure to comply with a customer notification SLA during an incident

  • Description. A SEV-1 or SEV-2 incident occurs and a customer notification is missed, late, or materially incomplete relative to the DPA commitment.
  • Category. Integrity (process); A.
  • Current controls. Documented incident response procedure at /policies/incident-response with severity classification, communication templates, and 72-hour customer-notification SLA; named Communications Lead role per incident.
  • Residual likelihood. L2.
  • Residual impact. I3.
  • Residual rating. Moderate.
  • Treatment. Mitigate. Quarterly tabletop of the communications path end-to-end (BCP/DR plan section 7); template-bank for each SEV / category combination.
  • Owner. Security Officer.
  • Target. Continuous; quarterly drill cycle.

6.14 R-14 — Misrepresentation of compliance posture

  • Description.Glassbreak (or a workforce member) overstates the platform's compliance posture to a customer, an auditor, or a supervisory authority.
  • Category. Integrity (regulatory); W.
  • Current controls. Published gap-assessment pages at /trust/soc-2, /trust/iso-27001, /trust/hipaa, /trust/fedramp stating what is held and what is not; the live trust page publishes only controls measured green for 30+ consecutive days; knowing misrepresentation is a Gross-category sanctions violation (/policies/sanctionssection 3.3).
  • Residual likelihood. L1.
  • Residual impact. I4.
  • Residual rating. Moderate.
  • Treatment. Mitigate. Compliance Officer reviews every external-facing assertion before publication; sales collateral references the published trust pages rather than asserting standalone.
  • Owner. Security Officer.
  • Target. Continuous.

6.15 R-15 — Migration error introducing data corruption or exposure

  • Description. A schema migration is incorrectly written, applied at the wrong time, or applied only on one vertical, leading to data corruption, cross-tenant leakage, or service loss.
  • Category. Integrity; CT, A.
  • Current controls. All migrations are code-reviewed; DR scenario 20 exercises migration safety in CI; CI-only deployment; the database client enforces per-organisation isolation at the query layer.
  • Residual likelihood. L2.
  • Residual impact. I4.
  • Residual rating. High.
  • Treatment. Mitigate. Document the standard-migration-safety checklist in the SDLC procedure; require an explicit rollback plan in every migration PR.
  • Owner. Engineering.
  • Target. Q3 2026.

7. Acceptance of residual risk

Residual risks rated Moderate or below are accepted by the Security Officer on behalf of the organisation. Residual risks rated High require named acceptance by the Security Officer with a target reduction date. Residual risks rated Severe require leadership acceptance and remain active workstreams until reduced; no Severe-rated risk is accepted indefinitely.

8. Records

  • The operational risk register is held under version control in the repository; the published summary in this document reflects the state at the effective date.
  • Risk-treatment decisions, target dates, and ownership are recorded against each entry.
  • Residual-risk acceptances at High or Severe are recorded with the named approver and approval date.
  • Records are retained for at least 5 years.

9. Related documents

Counter-signed PDF copy available on request to compliance@glassbreak.io.

Stay Updated

Get product updates and security insights. No spam, unsubscribe anytime.

We respect your privacy. See our privacy policy.