Skip to content

Risk Management

Statement

ClaimGuard's risk-management approach today is structured around three documented activities: a Snyk-driven application-security risk pass that produced 188 finding decisions and a versioned .snyk deferral file, a GCP cloud-posture pass that is captured step-by-step in docs/security/HARDENING-LOG.md, and the trust portal itself — which serves as a current-state risk register, where every partial page is a named, public risk we have committed to address.

There is no formal risk register as a standalone artifact, no quantitative likelihood/impact scoring, and no committee-driven risk review cadence. That is the gap that keeps this control at partial.

Implementation

Application-security risk pass (2026-04)

A Snyk-driven sweep classified every Open Source Audit and Snyk Code finding into one of:

  • Fixed in source — direct upgrade pin, code rewrite, or middleware change.
  • Deferred with reason — written .snyk entry with created: and expires: (one year). Categories used: scanner false positives against direct pins, upstream-vendor transitives without released fix, dev-only build-tool transitives, non-reachable code paths.
  • Confirmed not reachable — case-by-case analysis reasoning recorded in docs/security/findings/<id>.md.

Outcome: 188 findings disposed, 19 active deferrals in .snyk, load-bearing pin floors documented in docs/security/README.md. See Snyk remediation summary for the full decision record.

Cloud-posture risk pass (2026-04 → ongoing)

A staged plan (P0 → P1 → P2) is being executed against the production GCP project. Each step has a journal entry in docs/security/HARDENING-LOG.md with the exact gcloud commands and verification. P0 (must-do) is complete; P1 (should-do) is partially complete; P2 is queued. The cross-track sequencing constraint — "never publish a trust portal claim that contradicts the actual posture" — is itself a risk-management decision.

Trust portal as current-state risk register

Every partial page in this portal lists a "Known gaps" section that is, in effect, a public risk register entry:

  • The risk is named.
  • Its mitigation today is named (often: "the product is not yet at customer scale" or "covered by adjacent control X").
  • The remediation plan is named on the page or in the linked HARDENING-LOG.md entry.

Auditors and prospects see the same gap inventory we see internally. That is the deliberate trade-off: we forfeit a polished but optimistic story in exchange for documentation that our customers can trust.

Where risk reviews happen

  • At PR time for code-side risks: see Change management for the protocol.
  • At plan-step time for cloud-side risks: each HARDENING-LOG.md entry has a "Why" field that is the risk-rationale for the change.
  • At deferral creation / renewal for accepted-risk decisions: the .snyk file's created: / expires: model is the formal review trigger. Next renewal: 2027-04-22.
  • Ad hoc when a finding surfaces (e.g., the password_plain column flagged on Authentication was surfaced during evidence-gathering for the trust portal and is queued for a code fix).

What does not exist

  • No standalone risk register as a single document or tool.
  • No quantitative likelihood × impact scoring of risks.
  • No risk-review committee or scheduled cadence beyond the per-deferral annual renewal.
  • No risk-acceptance signature workflow for risks that aren't going to be remediated soon.
  • No business-context risk items separate from technical risk (e.g., key-personnel risk, vendor-lock-in risk, regulatory-change risk).

Status

partial — verified 2026-04-29.

What's in place:

  • A documented application-security risk pass with per-finding decisions and one-year deferral renewals (.snyk).
  • A documented cloud-posture risk pass tracked step-by-step in HARDENING-LOG.md.
  • A public, current-state risk register implicit in the trust portal's "Known gaps" sections.
  • Trigger points for risk review at PR time, at plan-step time, and at deferral renewal.

Known gaps

  • No standalone, normalized risk register with an ID per risk and a single owner.
  • No quantitative risk scoring.
  • No documented risk appetite for the company. Each decision is made on its merits without an explicit "we accept risks below threshold X" rule.
  • No business-context risks (key-personnel, vendor-lock-in, regulatory) on the register today.
  • No risk-review cadence beyond per-deferral expiry.

Roadmap

  • Single risk-register doc with: ID, description, owner, likelihood, impact, status, mitigation, target date. Initial population should pull every "Known gaps" item from the trust portal so the views are consistent.
  • Risk-review cadence — quarterly review of the register with founder sign-off, before SOC 2 fieldwork.
  • Business-context risks added (key-personnel, vendor-lock-in, regulatory).
  • Risk-acceptance signature workflow for items that will not be remediated in the current cycle.