decision-required
Security Readiness
Move from secure-by-default synthetic evaluation into an evidence-backed enterprise security program before protected use.
Current posture
The application maintains synthetic-only boundaries, deny-by-default execution routes, reproducible builds, and baseline browser security headers. A formal security program and independent testing remain required.
Public commitments
- Operate public product surfaces without PHI.
- Keep live execution denied until identity, tenant, audit, runtime, and connector controls are approved.
- Publish security posture as readiness evidence, not certification.
Control register
Evidence, required actions, and launch gates stay linked.
decision-required
Security risk-management program
Security blockers, identity decisions, runtime safety, audit boundaries, and connector gates are visible in product readiness registers.
Approve risk assessment method, control owners, risk register, review cadence, and executive acceptance process.
- Owner: Security leader
- Launch gate: Required before protected enterprise pilots.
decision-required
Incident response and breach operations
Trust Safety Ops defines incident detection, triage, containment, fixing, and improvement loops; no final managed 24/7 SOC/MDR coverage is asserted.
Approve incident taxonomy, response roles, 24/7 on-call coverage, evidence preservation, notification analysis, communications, exercises, and post-incident review.
- Owner: Security, privacy, legal, and communications
- Launch gate: Tabletop-tested plan required before processing protected or confidential data.
external-review-required
Vulnerability management and independent testing
Dependency audit, CI, lint, typecheck, build checks, security headers, and Vercel deployment verification are active.
Implement vulnerability SLAs, dependency monitoring, secrets review, SAST/DAST as appropriate, penetration testing, and remediation evidence.
- Owner: Security and independent assessor
- Launch gate: Independent testing and remediation required before production healthcare use.
decision-required
Public intake abuse and availability controls
Pilot intake validates content type, payload size, fields, synthetic boundary, and webhook timeout.
Add rate limiting, bot protection, monitoring, abuse response, and protected CRM delivery before scaling public campaigns.
- Owner: Security and engineering
- Launch gate: Required before paid advertising or high-volume public intake.
Prohibited actions
These actions remain blocked.
- Requesting credentials, secrets, PHI, or patient records through public intake.
- Representing baseline headers or dependency audits as a complete security program.
- Opening production execution routes before approval gates pass.
Authoritative references