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 the deferral policy file deferral file, a GCP cloud-posture pass that is captured step-by-step in the internal hardening journal, and the trust portal itself — which serves as a current-state risk register, where every page's "Known gaps" section names public risks we have committed to address.

There is no standalone-artifact risk register with quantitative likelihood/impact scoring or committee-driven review cadence — those are roadmap items as the company scales. The risk-management function itself is operating today through the three documented activities above, with named owners and rolling cadences.

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 the deferral policy file 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 per-finding decision records.

Outcome: a comprehensive finding-disposition pass completed, a small number of accepted-risk deferrals in the deferral policy file, load-bearing pin floors documented in the internal security README. 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 the internal hardening journal with the exact gcloud commands and verification. the must-do tier is complete; P1 (should-do) is partially complete; the lower-priority tier 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 page in this portal that has open work 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 the deferral policy file's created: / expires: model is the formal review trigger. Next renewal: 2027-04-22.
  • Ad hoc when a finding surfaces (e.g., the an admin-recovery field on the user record 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

implemented — verified 2026-05-06. Risk identification, treatment, and tracking are operating across application security (the deferral policy file), cloud posture (HARDENING-LOG.md), and this trust portal's "Known gaps" sections. Known gaps below are scaling-related maturation items.

What's in place:

  • A documented application-security risk pass with per-finding decisions and one-year deferral renewals (the deferral policy file).
  • 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.