Skip to main content

Regulated SDLC Guardrails

How software development changes when ePHI is in scope. Industry-standard guardrails first; Starlight's specific application is on the next page.

The bar isn't "we wrote tests." It's "we can produce, on demand, evidence that for every meaningful change to the system, an authorized engineer wrote the code, an authorized reviewer approved it, an automated pipeline tested it, and an authorized release manager deployed it — and that the data the system handles was protected throughout."

The 12 guardrails of a HIPAA-aligned SDLC​

These map cleanly to both the HIPAA Security Rule and the SOC 2 Common Criteria. Get all 12 right and 90% of an audit is automatic.

1 · Threat Modeling Before Code​

  • Run STRIDE or LINDDUN on every new feature that touches ePHI before implementation.
  • Output a brief threat-model artifact (1–2 pages) attached to the design doc.
  • Re-threat-model on architectural change, not just on first design.
  • HIPAA citation: 164.308(a)(1)(ii)(A) Risk Analysis. SOC 2: CC3.1, CC3.2.

2 · Least-Privilege by Default​

  • No service or human gets standing access to production ePHI. Break-glass only, time-bounded, with auto-expiry.
  • Database access via short-lived credentials issued by a session broker (AWS IAM roles + STS, or equivalent) — never long-lived passwords.
  • Engineers debug against synthetic data, not prod, by default. See synthetic data.
  • HIPAA: 164.308(a)(4) Information Access Management, 164.312(a) Access Control. SOC 2: CC6.1, CC6.2.

3 · Code Review with Enforced Approval​

  • Branch protection on main: at least one human reviewer who isn't the author, plus all CI checks green, before merge.
  • Reviewers are tracked by identity (no shared bot accounts approving real changes).
  • For changes that touch authentication, encryption, audit logging, or PHI access boundaries, require two reviewers including a designated security reviewer.
  • HIPAA: 164.308(a)(8) Evaluation. SOC 2: CC8.1 (Change Management).

4 · Automated Static & Dependency Analysis​

  • SAST on every PR (Semgrep, CodeQL, Snyk, GitHub code scanning).
  • SCA / dependency scanning blocks merges on high/critical CVEs in production dependencies.
  • Secret scanning (gitleaks, GitHub secret scanning, AWS Macie on the repo).
  • Lint + typecheck must pass before merge — non-negotiable.

5 · Data Classification at the Schema Level​

  • Every column / field carries a data classification: public | internal | confidential | phi.
  • The classification is enforceable in code: types, attributes, or schema annotations that downstream code can read.
  • ETL, logging, analytics, and AI-prompt construction all consult classification before emitting data.
  • This is the single highest-leverage control for preventing accidental PHI leakage. Build it on day one, not month nine.

6 · Encryption Everywhere, Always​

  • At rest: AES-256 (or stronger) via managed KMS for everything — DBs, object storage, backups, logs containing PHI, message queues.
  • In transit: TLS 1.2+ for every connection, including internal service-to-service. mTLS where the threat model warrants it.
  • In application memory: structured serialization formats that can be redacted or selectively decrypted (envelope encryption for PHI fields).
  • HIPAA Safe Harbor: encrypted PHI is not "unsecured" — see HHS Guidance. This is why we encrypt everything.
  • HIPAA: 164.312(a)(2)(iv), 164.312(e)(2)(ii). SOC 2: CC6.7, CC6.8.

7 · Comprehensive Audit Logging​

  • Who (authenticated identity), what (action + resource), when (UTC timestamp), where (IP / device), outcome (success/failure) — for every PHI access and every privileged action.
  • Logs are write-once / append-only / tamper-evident (CloudTrail with log file integrity validation, or signed log streams).
  • Logs are queryable. Patient's Right to Accounting of Disclosures requires us to answer "show me everyone who saw my chart in the last 6 years."
  • Logs themselves are PHI-classification-aware — we don't log raw PHI in stack traces or request bodies.
  • HIPAA: 164.312(b) Audit Controls. SOC 2: CC4.1, CC7.2.

8 · Pipeline Hygiene & Change Tracking​

  • Every production deployment is traceable to a Git commit, a CI run, an approving reviewer, and a deploying actor.
  • Infrastructure-as-Code only — no click-ops in prod. Drift detection runs continuously.
  • Versioned, signed artifacts (container images signed with cosign / Notary; provenance via SLSA framework).
  • Reproducible builds where feasible.
  • SOC 2: CC8.1 (Change Management) — most-cited deficiency in early audits.

9 · Secrets Management​

  • No secrets in source. No secrets in environment variables on disk. Secrets in a managed vault (AWS Secrets Manager, HashiCorp Vault) with audited access and rotation.
  • Short-lived where possible — OIDC-issued tokens for CI, IAM-role assumption for services.
  • Rotation cadence documented and automated; emergency rotation runbook exists and has been rehearsed.

10 · Incident Response Readiness​

  • Runbook for each plausible incident class: ePHI breach, credential compromise, ransomware, third-party vendor breach, supply-chain compromise.
  • On-call rotation with primary + secondary, with a designated Incident Commander role.
  • Post-incident retro template that produces an artifact, not just a Slack thread.
  • Tabletop exercises run on a recurring tempo set by the Security Officer — frequently enough that the runbook is never first-time-run during a real incident.
  • HIPAA: 164.308(a)(6) Security Incident Procedures, Breach Notification Rule. SOC 2: CC7.3, CC7.4.

11 · Backup, Restore, and Disaster Recovery — Tested​

  • Automated backups with documented RPO (recovery point objective) and RTO (recovery time objective).
  • Restore drills run on a recurring tempo + on every schema change. A backup that's never been restored isn't a backup.
  • Cross-region replication for ePHI stores; DR plan exists and has been exercised end-to-end before we depend on it.
  • HIPAA: 164.308(a)(7) Contingency Plan. SOC 2: A1.2, A1.3, CC9.1.

12 · Vendor / Subprocessor Discipline​

  • Every vendor that could touch PHI has a signed BAA before they touch a byte of it.
  • Vendor inventory is a living document, reviewed on vendor onboarding, on contract renewal, and on a recurring tempo set by the Security Officer. Each entry: vendor name, what they process, where data flows, BAA status, last review date.
  • Vendor security posture (their own SOC 2 / HITRUST / pen test results) reviewed at onboarding and renewal.
  • HIPAA: 164.308(b), 164.314(a) BAA Requirements. SOC 2: CC9.2.

Practices that look optional but aren't​

These are the ones startups skip and regret:

PracticeWhy teams skip itWhy you can't
Document classification policyFeels bureaucratic on day oneWithout it, devs can't tell if a log statement is safe. Hours saved on day one cost weeks during a leak post-mortem.
Tabletop / DR drills"We're too busy shipping"Untested IR is theater. The first real incident is the worst time to discover the runbook is wrong.
Background checks for engineersAdds friction to hiringHIPAA workforce-clearance (164.308(a)(3)(ii)(B)) and SOC 2 CC1.4 both expect them.
Recurring security training"Engineers know this stuff"The audit asks for evidence by name, with completion dates. No exceptions.
Privacy / data subject request workflowLow volume early, easy to do manuallyManual processes drift. Build the Right of Access workflow as code from day one.
Crypto-shredding for offboarding"We'll just delete the row""Delete" in distributed systems is hard. Pre-design how to revoke key material so a deletion request is provably honored across backups.

The bigger frameworks (for context, not adoption today)​

We're not chasing these in v1, but every CISO conversation will reference them. Know what they are.

FrameworkWhat it isWhen it might matter for us
NIST Cybersecurity Framework (CSF) 2.0High-level cybersecurity outcomes (Govern, Identify, Protect, Detect, Respond, Recover). csrc.nist.gov · CSFA useful mental model and reporting language. Not an audit.
NIST SP 800-53 Rev. 5The detailed control catalog underneath FedRAMP. csrc.nist.gov/pubs/sp/800/53/r5/upd1/finalIf we ever sell to federal customers or a payer that requires FedRAMP-aligned controls.
HITRUST CSFA unified controls framework that bundles HIPAA + NIST + ISO + others. Industry-popular but paid certification. hitrustalliance.netOften required by larger payers / hospital systems for vendor onboarding. Likely Year-2+ for us.
ISO/IEC 27001International standard for ISMS (Information Security Management System).If we sell internationally, especially EU.
HIPAA-relevant FDA Software-as-a-Medical-Device guidanceWhen software diagnoses, treats, or monitors a medical condition, FDA SaMD rules may layer on top of HIPAA.If we ever ship clinical-decision-support that crosses the SaMD line. The triage tool described in future features sits near this line — design carefully.

What "good" looks like — engineering checklist​

A new engineer joining Starlight should be able to answer yes to all of these in their first week:

  • I know the difference between Covered Entity and Business Associate, and which we are.
  • I know which of our environments is allowed to hold real PHI (production), and which is forbidden (dev, staging — synthetic only).
  • I have read the data classification policy and can identify a phi-classified field at a glance.
  • I know how to request break-glass production access and that it auto-expires.
  • I know that no PR merges without review + green CI.
  • I know what to do in the first 30 minutes of a suspected ePHI incident.
  • I have completed the security + HIPAA training program before being granted any production access.
  • I know who the Security Officer is and how to reach them.

If any of these are "I don't know yet," the onboarding has failed.

Where to go next​