Security review
Last reviewed: 2026-06-28 — see the freshness policy.
Learning objectives
After this chapter you will be able to:
- Run a structured security review of an HLS architecture before build.
- Apply threat modeling and a PHI-focused control checklist.
- Produce review evidence that supports HIPAA/HITRUST and a security sign-off.
The review is a gate, not a formality
Before an HLS design is built, it passes a security review — and in regulated settings, it must. The SA owns getting the architecture through it: not by hoping, but by designing to a checklist and threat-modeling the PHI flows up front. A design that reaches review with these answers ready sails through; one that doesn't gets sent back. This is the Validate step made concrete, and it leans on the Security pillar and HIPAA.
Threat-model the PHI flows
Trace PHI through the architecture and ask, at each hop, what could go wrong. A lightweight STRIDE pass works well:
flowchart LR
In["Ingress (EHR/app)"] --> Proc["Processing"] --> Store["Storage (PHI)"] --> Out["Egress (APIs, exports, logs)"]
T["At each hop: Spoofing, Tampering, Repudiation,<br/>Information disclosure, DoS, Elevation"] -.-> In & Proc & Store & Out
Pay special attention to the edges: ingress auth, egress (APIs, exports, logs, backups, support access) — the places PHI leaks are usually at a boundary someone forgot, not in the core store.
PHI-focused control checklist
- Encryption — at rest (AES-256, customer-managed keys) and in transit (TLS 1.2+); no exceptions for "internal" traffic.
- Access — least privilege (IAM + SMART scopes), MFA, automatic session timeout; deny by default.
- Network — PHI stores in private subnets; private endpoints; no public buckets/DBs; egress controls.
- Audit — who accessed which PHI, when; immutable logs retained ≥ 6 years; alerting on anomalous access.
- BAA surface — every vendor touching PHI has a BAA; minimize the count (see HIPAA).
- Secrets — managed secret store, rotation, no secrets in code or env files.
- Data lifecycle — retention, secure deletion, de-identification where data leaves the trust boundary.
- Backups & DR — encrypted, tested restore, RTO/RPO defined.
- Logging hygiene — no PHI in application logs sent to un-covered tooling.
- Incident response — a tested runbook and breach-notification path.
Make it evidence, not opinion
The strongest review posture is policy-as-code + IaC: if encryption, private networking, and access controls are enforced by reusable modules, you can prove they apply uniformly rather than asserting it. That same evidence feeds HITRUST and (for regulated software) GxP validation. Bring to the review: the C4 + data-flow diagrams, the control-to-regime mapping, the threat model, and the IaC that enforces it.
Check yourself
- Where do PHI leaks most commonly hide, and why focus the threat model on the edges?
- List five controls from the checklist and the threat each mitigates.
- Why does policy-as-code + IaC make a security review (and a HITRUST assessment) easier to pass?