> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Risk management & register

> ISO 27001 clauses 6.1 + 8.2 + 8.3 — our risk assessment methodology, risk treatment process, and the live register of tracked risks.

<Info>
  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.
</Info>

**Owner**: Security Officer · **Reviewed by**: CTO + CEO at management review · **Policy version**: 1.0

## Purpose

Denialbase's risk management process:

1. Identifies risks to the confidentiality, integrity, and availability of information assets.
2. Assesses likelihood and impact to produce a consistent severity score.
3. Decides treatment: **mitigate**, **transfer**, **accept**, or **avoid**.
4. Tracks treatment actions to completion.
5. 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                          |

**Impact** (consequence if it does):

| 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                                                     |

**Inherent risk score** = Likelihood × Impact (range 1–25).

**Residual risk score** = Likelihood × Impact **after controls** are applied.

### 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](/trust/management-review).

### Communication

* Top-5 risks reported to every [management review](/trust/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)

<Warning>
  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](mailto:security@denialbase.com).
</Warning>

### 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](https://github.com/Denialbase/denialbase/pull/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](https://github.com/Denialbase/denialbase/pull/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](https://github.com/Denialbase/denialbase/pull/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](/trust/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 |