This page combines our Risk Management Policy (methodology) with the Risk Register (the live tracked-risks list). External auditors usually want to see these together. Both are reviewed quarterly and whenever a material change occurs.
Purpose
Denialbase’s risk management process:
- Identifies risks to the confidentiality, integrity, and availability of information assets.
- Assesses likelihood and impact to produce a consistent severity score.
- Decides treatment: mitigate, transfer, accept, or avoid.
- Tracks treatment actions to completion.
- Monitors residual risk and reviews periodically.
This aligns with ISO 27001:2022 clauses 6.1.2 + 6.1.3 (risk assessment + risk treatment) and ISO 27005 (guidance).
Methodology
Scope of assessment
- All information assets listed in our asset inventory (applications, infrastructure, data, processes).
- All workforce + vendor relationships.
- All changes to scope trigger a delta assessment.
Identification
Risks are identified from:
- Threat intelligence — industry advisories, CVE monitoring, healthcare-specific threat reports.
- Audit findings — internal and external.
- Incident reviews — root causes of actual incidents.
- Vendor changes — new subprocessors, changed terms, vendor breaches.
- Architecture reviews — new features, new data flows, new integrations.
- Workforce input — anyone can propose a risk; reviewed at next risk meeting.
- Annual threat modeling workshop — facilitated STRIDE walkthrough of the full stack.
Assessment — 5×5 matrix
Each identified risk is scored on two dimensions:
Likelihood (probability the risk materializes in the next 12 months):
| Score | Label | Definition |
|---|
| 5 | Very High | Almost certain — expected within 3 months |
| 4 | High | Likely — expected within 12 months |
| 3 | Medium | Possible — could happen within 12–24 months |
| 2 | Low | Unlikely — possible but not expected |
| 1 | Very Low | Rare — theoretical |
| Score | Label | Definition |
|---|
| 5 | Severe | PHI breach affecting >500 individuals; >$1M cost; existential regulatory action |
| 4 | Major | PHI breach < 500 individuals; material service disruption (>24 hours); significant regulatory inquiry |
| 3 | Moderate | Non-PHI data exposure; service disruption 4–24 hours; minor regulatory notification |
| 2 | Minor | Internal-data exposure; service disruption < 4 hours; localized operational impact |
| 1 | Negligible | No customer impact; internal process friction only |
Rating bands
| Score | Band | Response |
|---|
| 16–25 | Critical | Treat immediately; no acceptance without CEO + Security Officer sign-off |
| 10–15 | High | Treat within 90 days; Security Officer sign-off on treatment |
| 5–9 | Medium | Treat within 180 days; documented treatment plan |
| 1–4 | Low | Monitor; treat if cost-effective |
Treatment decisions
For each risk above the Low band, choose one:
- Mitigate — implement controls to reduce likelihood and/or impact.
- Transfer — contractually shift risk (insurance, BAA indemnification, vendor SLA).
- Accept — document acceptance with rationale and expiry (maximum 12 months, renewable).
- Avoid — eliminate the source (e.g. don’t use the vendor, don’t build the feature).
Every risk above Low has a named owner accountable for the treatment action.
Risk acceptance
For risks we choose to accept (i.e. not fully mitigate):
- Documented in the register with rationale.
- Expiry — acceptance is time-bound (default 6 months).
- Compensating controls — any alternative mitigations in place.
- Approval — Security Officer for Medium/High; CEO + Security Officer for Critical.
- Review — acceptance revisited at every management review.
Communication
- Top-5 risks reported to every management review.
- Critical or High risks with customer-visible implications reported on the Trust Center (this page).
- Internal risk register (with owner names, ticket links, evidence paths) available to all workforce via Google Drive.
Review cadence
| Activity | Cadence |
|---|
| Owner updates their entries | Monthly |
| Full register review with CTO + CEO | Quarterly |
| New-risk intake (any workforce member can propose) | Continuous |
| New-risk triage + classification | Within 14 days of proposal |
| External review (part of audit) | Annual |
| Full methodology review | Annual |
Register (public snapshot — April 2026)
This is a sanitized snapshot. Internal entries include owner names, ticket links, evidence file paths, and private vendor evaluation records. Enterprise customers can request the full internal register under mutual NDA: security@denialbase.com. Critical (score 16–25)
None currently. All Critical risks from the April 2026 audit review have been moved to active treatment with progress tracked quarterly.
High (score 10–15)
| ID | Risk | Category | L × I | Treatment | Target closure |
|---|
| R-2026-001 | Unsigned subprocessor BAAs (GCP, Anthropic, Sentry, SES) create HIPAA compliance gap | Supplier / Legal | 4 × 4 = 16 | Mitigate — BAA execution in progress; technical PHI-minimization compensating controls in place (encryption, scrubbing, private networking, audit logging) | Q3 2026 |
| R-2026-002 | PHI column-encryption migration incomplete — some PHI columns stored as plaintext at the ORM layer despite CMEK at rest | Confidentiality | 3 × 4 = 12 | Mitigate — migration + backfill in progress (PR #78); compensating controls: CMEK, private VPC, audit logging | Q2 2026 |
| R-2026-003 | No formal Incident Response Plan with tested runbook — placeholders in current draft | Operational | 3 × 4 = 12 | Mitigate — IRP formalization + first tabletop exercise | Q2 2026 |
| R-2026-004 | No DR drill executed — backups in place but restore procedure untested at scale | Operational / Availability | 3 × 4 = 12 | Mitigate — schedule first backup-verification + PITR drill | Q2 2026 |
| R-2026-005 | No third-party penetration test — automated SAST + dep scans don’t substitute for adversarial testing | Security | 3 × 4 = 12 | Mitigate — engage CREST-accredited firm; scope external app + infrastructure | Q3 2026 |
| R-2026-008 | No formalized ISP / AUP / policy stack ahead of ISO 27001 audit | Governance | 3 × 4 = 12 | Mitigate — this Trust Center publication; internal sign-off by CEO | Q2 2026 (in progress on this branch) |
Medium (score 5–9)
| ID | Risk | Category | L × I | Treatment | Target closure |
|---|
| R-2026-006 | JWT key rotation has dual-secret validation support but no scheduled rotation cadence executed in production | Security | 2 × 3 = 6 | Mitigate — implementation shipped (PR #76); first rotation drill Q2 2026 | Q2 2026 |
| R-2026-007 | GCP organization policies (block SA key creation/upload) gated behind disabled Terraform flag | Infrastructure | 2 × 3 = 6 | Mitigate — enable in staging first (PR #77); promote to prod after staging confirms | Q2 2026 |
| R-2026-009 | HR onboarding/offboarding records not consolidated — practices exist but not audit-exportable from one place | HR / Governance | 3 × 2 = 6 | Mitigate — consolidate into HR platform with exportable records | Q3 2026 |
| R-2026-010 | LLM prompt-injection or data-exfil risk in AI-generated appeals if scrubbing fails | AI Safety | 2 × 3 = 6 | Mitigate — PHI scrubbing before LLM call; output validation; HITL review for low-confidence; periodic prompt-injection testing | Ongoing monitoring |
| R-2026-011 | Workforce phishing risk — no formal simulation program yet | HR / Security | 2 × 3 = 6 | Mitigate — adopt phishing simulation platform | Q2 2026 |
| R-2026-012 | Key-person dependency (small team) on CTO and Security Officer | Operational | 2 × 3 = 6 | Mitigate — document all CTO-only runbooks; cross-train; external advisor retainer for Security Officer | Q3 2026 |
| R-2026-013 | No Sigstore/cosign image signing yet — supply chain integrity relies on GCP Artifact Registry access control | Supply chain | 2 × 3 = 6 | Mitigate — adopt Sigstore signing + verification at deploy time | Q3 2026 |
| R-2026-014 | No formal asset inventory — controls assume inventory exists | Asset management | 2 × 2 = 4 → adj. 6 for audit-readiness | Mitigate — create and maintain asset inventory | Q2 2026 |
| R-2026-015 | Kaiser-specific integration relies on a single integration point; Kaiser outage impacts a material portion of the book | Availability | 2 × 3 = 6 | Transfer / Mitigate — SLA clauses; fallback for most common flows; diversification | Q4 2026 |
Low (score 1–4)
Tracked internally; not repeated here. Examples include: ESLint rule coverage gaps, documentation freshness drift, minor UX issues with DR runbook clarity.
Relationship to other documents
Threat modeling ──┐
Audit findings ───┼→ Risk register ──→ Risk treatment plan ──→ Actions (tickets)
Incident reviews ─┤ │
Change impact ────┘ ↓
Management review → Resource allocation
- Every audit finding with residual risk becomes a risk register entry.
- Every risk treatment decision is tracked to closure.
- Every quarterly review updates the register and carries outputs into the next management review.
Records retained
| Record | Retention |
|---|
| Internal risk register (versioned) | 6 years |
| Risk acceptance records | 6 years past expiry |
| Management review minutes (risks discussed) | 6 years |
| External audit reports (risks surfaced) | 6 years |
Changelog
| Version | Date | Material changes |
|---|
| 0.1 | 2026-04 | Draft informal register (10 entries) |
| 1.0 | 2026-04 | Formal methodology + 15-entry register with L×I scoring, bands, treatment decisions |
