Incident Response

Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30

1. Purpose & scope

This policy establishes how Bioscope Foundry detects, responds to, and reports information-security incidents to minimize loss and destruction, contain the blast radius, mitigate exploited weaknesses, and restore service. It applies to every Foundry workforce member, every system Foundry operates (the conductor platform in the cloud, the foundry-master-agent control plane, all Forge Agents and Tier-4 Moltworkers, Foundry-managed workstations, and Foundry-owned SaaS tenants), and to subprocessors handling PHI on Foundry’s behalf.

The process covers:

• Continuous monitoring through intrusion detection, audit log analysis, and anomaly alerts;
• A standing Security Incident Response Team (SIRT) and on-call rotation;
• Procedures for media inquiries and external communications;
• Clear procedures for identifying, responding to, assessing, analyzing, and following up on incidents;
• Workforce training, education, and awareness; and
• Communication with internal stakeholders, member practices (covered entities), and external authorities as required.

The procedural backbone is adapted from the HIPAA Collaborative of Wisconsin Security Networking Group and the SANS incident-handling lifecycle, then layered with controls specific to an MSO operating an agentic platform over FHIR-resident PHI.

2. Policy statements

Bioscope Foundry policy requires that:

(a) All computing environments and systems are monitored in accordance with Foundry’s Auditing, System Access, and Endpoint & MDM policies.

(b) All alerts are reviewed to identify security incidents. Investigation tickets are stored in the Linear Investigations team; finalized investigation reports are filed in an access-controlled internal repository.

(c) Incident response procedures are invoked upon discovery of a valid security incident.

(d) When an incident affects PHI we handle on a practice’s behalf, the Security Officer or designee notifies the affected practice (the covered entity) without unreasonable delay, in line with the Business Associate Agreement (BAA) and HIPAA’s Breach Notification Rule. See the Breach Notification policy.

(e) The incident response team and management comply with additional requests by law enforcement in the event of a criminal investigation or national-security matter, including warranted data requests, subpoenas, and breach notifications.

3. Security Incident Response Team (SIRT)

The Security Incident Response Team (SIRT) is responsible for:

• Reviewing, analyzing, and logging all received reports and tracking their statuses;
• Performing investigations, creating and executing action plans, and post-incident activities;
• Collaborating with law enforcement agencies as appropriate.

The SIRT operates under defined roles for each incident:

• Incident Commander (IC). Single decision-maker for the incident. Drives tempo, declares severity, makes containment calls, and approves communications. Rotates from the on-call schedule.
• Communications Lead. Owns internal updates, practice/customer notifications, and any external communications. Maintains the comms log.
• Investigator(s). Perform technical analysis, evidence collection, and root-cause work.
• Scribe. Maintains the running timeline in the Linear ticket so the investigation is reconstructable after the fact.

Standing SIRT membership:

• Security & Privacy Officer
• Engineering Lead
• Platform / SRE on-call
• Agent Platform on-call (covers foundry-master-agent, Atlas, Forge Agents, and Tier-4 workers)
• Legal counsel (engaged for breach analysis and BAA notifications)

4. Incident management process

Foundry’s incident response follows the SANS incident-handling lifecycle. The process distinguishes events from incidents and includes a separate workflow for confirmed PHI exposure.

Definitions

• Event. Any observable security-related occurrence in a system or network with a potential negative consequence. Examples: hardware failure causing an outage; software error causing an outage; general network or system instability; alerts from authentication, antivirus, or WAF systems; modified system files or unusual accesses; antivirus alerts; unusual network traffic to unexpected geographies.
• Incident with no impact. An event that resulted in degraded performance, SIRT activity, or follow-up tickets but did not affect customer-facing utility. Examples: brute-force attempts that resulted in extra authentication filters; missing endpoint protection agents that resulted in remediation; critical vulnerabilities requiring triage and patching; misconfigurations deployed to production that required redeploy.
• Incident with impact. A confirmed attack or indicator of compromise, often resulting in data loss or service degradation. Examples: a denial-of-service attack making a critical service unreachable; unauthorized changes resulting in production downtime or data loss; malicious software discovered on endpoints requiring eradication; compromised cloud credentials used outside intended scope and containment procedures.
• Breach. A confirmed event that resulted in PHI being exposed, altered, or destroyed in a manner not permitted under HIPAA. Examples: an exfiltration from Foundry’s FHIR service; an authorized export of FHIR data to an unauthorized destination; unauthorized change or destruction of PHI in the FHIR store; loss of a Foundry-managed workstation that, contrary to policy, contained PHI; an agent-runaway scenario where a Tier-3 clinical agent exposed PHI to a destination that was not its policy-allowed sink; Beacon Layer redaction failure resulting in raw PHI surfacing on a sanitized physician channel.

Foundry workforce members must report any unauthorized or suspicious activity seen on production systems or associated communication systems (such as Slack, email, or the agent control plane) as soon as it is discovered. “When in doubt, report” is the rule.

I: Identification and triage

1. Immediately upon observation, Foundry members report suspected and known events, precursors, indications, and incidents through one of:
   1. Direct report to management, the Security Officer, or the Privacy Officer;
   2. Email to security@bioscopefoundry.com;
   3. Phone call to the on-call rotation;
   4. Submission via the Foundry internal incident channel in Slack;
   5. Anonymous submission through the channel of the reporter’s choice.
2. The individual receiving the report facilitates collection of additional information and notifies the Security Officer if not already done.
3. The Security Officer determines whether the issue is an event, precursor, indication, or incident.
   1. If non-security or low-severity event: route to the appropriate resource for resolution. A ticket is filed in Linear and tracked to closure.
   2. If a security incident: activate the SIRT and notify senior leadership by email or Slack.
      1. If a non-technical incident, the SIRT completes the investigation, implements preventative measures, and resolves the incident. Proceed to Phase V.
      2. If a technical incident, proceed to Phase II (Containment). Each SIRT member and technical responder documents all measures taken, including start and end times.
      3. The Incident Commander opens an Incident ticket in the Linear Investigations team; the ticket summarizes events, efforts, and conclusions for each phase. Detail follows the SANS Security Incident Forms templates.
4. If PHI is or may be implicated, the Security Officer notifies the affected practice (covered entity) per the BAA and the Breach Notification policy. The notification to the practice happens without unreasonable delay and in no event later than thirty (30) calendar days from discovery, well within the HIPAA-mandated 60-calendar-day outer limit for BA-to-CE notification at 45 CFR § 164.410(b). Where a Practice’s negotiated BAA sets a shorter window, that BAA controls.
5. If a threat is identified, the Security Officer forms a team to investigate and engages any necessary external resources.

II: Containment (technical)

In the containment phase, Foundry engineering and security work to limit the blast radius. Detailed notes are taken throughout so evidence is usable in a subsequent investigation or, if applicable, prosecution.

1. Review any information collected so far by Security or other investigators.
2. Secure the blast radius (e.g., revoke credentials, isolate the affected service, restrict a VPC perimeter, freeze an agent worker, or place the platform into Read-Only Mode, see §7).
3. Perform documented forensic analysis, following the relevant playbook.
4. Document containment in the Incident ticket using a SANS IH Containment Form-style structure.
5. Continuously update senior management.
6. Continue notifying affected practices/customers with relevant updates as needed.

III: Eradication (technical)

The SIRT removes the cause and resulting security exposures.

1. Determine symptoms and cause for each affected system.
2. Strengthen defenses surrounding affected systems, including network perimeter, system monitoring, and remediation of the underlying defect (“fixing” misconfigurations, removing unused services, applying host hardening).
3. Conduct a detailed vulnerability assessment to confirm exploitable gaps are addressed; if additional issues are found, take appropriate preventative measures.
4. Update the Incident ticket with eradication details (SANS IH Eradication Form-style).
5. Update documentation with what was learned: cause, symptoms, and the fix.
6. Update senior management; continue updates to affected practices/customers.
7. Proceed to Phase IV.

IV: Recovery (technical)

The SIRT restores affected systems to operation.

1. Determine whether affected systems were changed.
   1. If changed, restore to last known good (intended functioning).
   2. Validate that the system functions as intended; involve owning teams where needed.
   3. If operation was interrupted (system taken offline, dropped from network), restart and monitor.
   4. If the system was not changed but was taken offline, restart and monitor.
   5. Update documentation with details from this phase.
   6. Update senior management; continue updates to affected practices/customers.
   7. Proceed to Phase V.

V: Post-incident analysis (technical and non-technical)

The follow-up phase reviews the incident for lessons learned and improvements. Incident reviews occur shortly after resolution; timelines may extend one to two weeks post-incident.

1. Responders (SIRT and technical resource) meet to review documentation collected during the incident.
2. A blameless post-mortem is produced and filed in an access-controlled internal repository, linked from the Linear ticket. Post-mortem authorship rests with the technical lead, with input from key personnel.
3. All incident-related information is recorded and retained per Foundry’s Auditing and Data Management standards.
4. The incident is closed.

Periodic evaluation

The incident response process is reviewed and evaluated for effectiveness at least annually and after each SEV-1/SEV-2 incident. Training for responders and for the broader workforce is updated based on lessons learned. The plan is tested annually via tabletop or simulation (see §8).

5. Severity levels & classification

An incident is assigned a category and a severity level as soon as enough information is available; both can change as the investigation progresses. The audit trail captures every change.

Categories

Categories are based on the ENISA Incident Taxonomy:

• Abusive Content: spam, harassment, illegal sexual or violent content.
• Malicious Code: virus, worm, trojan, spyware.
• Information Gathering: scanning, sniffing, social engineering.
• Intrusions and Intrusion Attempts: brute force, zero-day exploitation, account compromise.
• Availability Attack: DoS, DDoS, sabotage.
• Change Management: unauthorized changes to production, misconfiguration deployments.
• Vulnerable: reported vulnerabilities.
• Fraud: unauthorized use of resources, copyright, masquerade.
• Agent / AI: Forge Agent runaway, policy violation, Beacon Layer redaction failure, Moltworker boundary breach attempt.
• Other: anything that doesn’t fit the above.

Severity matrix

6. Special cases

6.1 PHI / ePHI

When an incident involves unsecured PHI:

• “Unsecured PHI” means PHI not rendered unusable, unreadable, or indecipherable to unauthorized persons through encryption or destruction per HHS guidance. PHI encrypted to NIST specification while at rest in the FHIR store and in transit over TLS 1.2+ is presumptively secured.
• The Security Officer activates the breach workflow in the Breach Notification policy.
• Foundry notifies the affected practice (covered entity) without unreasonable delay and in no event later than thirty (30) calendar days from discovery, well within the HIPAA 60-day outer limit at 45 CFR § 164.410(b). Where a Practice’s negotiated BAA sets a shorter window, that BAA controls. Discovery is the first day the breach is known or, with reasonable diligence, would have been known to any Foundry workforce member or partner (other than the person committing the breach).
• Foundry provides the practice with the information it needs to meet its own obligations: notification to affected individuals, HHS, and (for breaches of 500+ individuals in a single state or jurisdiction) prominent media outlets.
• Foundry does not notify individuals, HHS, or media directly on behalf of the practice unless the BAA delegates that obligation in writing.

6.2 Criminal activities

If an incident involves suspected criminal activity, the SIRT and management notify law enforcement. The Security Officer coordinates the law-enforcement engagement, including evidence preservation requirements and any delays to notification authorized under HIPAA §164.412.

6.3 Insider threat

The cross-discipline insider-threat response team includes:

• Security & Privacy Officer;
• The Operations Lead; and
• Engineering Lead, as appropriate.

Insider-threat investigations require dual-control review and explicit Security Officer authorization before any audit log lookups touch personally-identifiable activity.

6.4 Agent and AI runaway

Because Foundry runs an agentic platform (Atlas + Forge Agents), the IR plan covers AI-specific failure modes:

• Compromised Tier-4 worker (Moltworker). A Moltworker runs on a sandboxed_public host and, by design, cannot reach PHI, :private memory, or clinic-scoped data. A compromise is contained to that host. Response: freeze the worker, snapshot for forensics, rotate any credentials issued to that worker, audit the Atlas placement decisions that ran the worker.
• Tier-3 clinical agent policy violation. A clinic-scoped agent attempts (or appears to attempt) to send PHI to a sink outside its policy. Response: revoke the agent’s session, audit the decision chain in Atlas / foundry-policy, replay the policy evaluation against the recorded inputs, file a finding against the policy crate, and report to the affected practice if PHI left Foundry’s boundary.
• Beacon Layer redaction failure. Sanitized physician-facing output surfaced raw PHI or peer :private memory. Treat as a confirmed PHI exposure; activate §6.1 immediately.
• Atlas control-plane compromise. The Tier-0 orchestrator is compromised. Treat as SEV-1 by default; place the operating platform in Read-Only Mode (§7) and consider System Offline Mode if exfiltration is suspected.

Forensic artifacts for agent incidents include the relevant Atlas decision logs, Forge Agent audit codes, mount-watcher events, and any memory_events entries (which never contain raw PHI bodies, only machine-readable codes).

7. Emergency operations modes

If an incident constitutes an emergency, for example, an ongoing campaign exfiltrating data, Foundry can place the operating platform into one of two emergency operations modes. Activation requires approval by the Security Officer or a higher executive.

In emergency operations mode, temporary access may be granted to security and/or engineering personnel to access production environments for forensics, root-cause analysis, eradication, or recovery activities. All such access is logged to cloud audit logs and reviewed post-incident.

Read-Only Mode

Read-Only Mode pauses all write activity against the operating platform. Practices and patients can still read their data, but no further edits can be made. Implemented via deny-write IAM policies on the AWS account hosting the FHIR service and application-tier feature flags in conductor.

Example: a threat actor is writing continuous bursts of data at scale, driving cost and instability. We enter Read-Only Mode while we investigate and eradicate.

System Offline Mode

System Offline Mode completely isolates the production system from external networks via a combination of IAM and network perimeter controls policies. Practices and patients cannot access their data during this period.

Example: a threat actor has compromised production credentials and is exfiltrating large volumes of data.

8. Tabletop exercises

At least once per year, Foundry security and engineering jointly run a tabletop exercise or red-team drill that simulates one or more SEV-1 incidents. Depending on the type of exercise, duration ranges from a 2–4 hour tabletop to a multi-week red-team engagement.

Each exercise follows a cyberattack playbook. Exercises may be run entirely with internal resources or with an external security consulting firm. Senior leadership may participate in the drill or receive a readout. Goals:

• Confirm responders can execute the documented procedures in real conditions;
• Validate that the on-call rotation, paging, and comms paths work;
• Identify gaps ahead of a real event;
• For agent scenarios: validate that Atlas containment levers (Read-Only Mode, agent freeze, credential rotation) behave as designed.

Findings are tracked to closure as Linear tickets and reviewed at the annual policy review.

9. Incident tracking and records

A Linear ticket in the Investigations team is created for every reported incident. Each ticket captures:

• Summary;
• Description;
• Impact;
• Priority / urgency;
• Category and severity;
• Timeline (analysis notes and comments);
• Cause / determination;
• Outcome / resolution;
• Lessons learned.

Where a more detailed post-mortem is appropriate, Security or Engineering produces the write-up and files it in an access-controlled internal repository, linked from the Linear ticket. Incident records and supporting materials are retained for at least six years in line with HIPAA recordkeeping requirements.

10. Roles & responsibilities

• Security & Privacy Officer: owns this policy, declares incidents, authorizes emergency operations modes, and is the named contact for practice / regulator communications about Foundry security incidents.
• Incident Commander (per-incident role): single decision-maker during an active incident.
• Communications Lead (per-incident role): owns practice and customer notification.
• SIRT members: investigate, contain, eradicate, and recover.
• On-call engineers: first responders for platform and agent incidents.
• Workforce members: report suspected incidents promptly through any documented channel.
• Legal counsel: supports breach analysis, regulator interaction, and law-enforcement engagement.

11. Review & revision

This policy is reviewed at least annually and whenever a significant incident, regulatory change, or platform change makes it stale. The plan is also exercised annually (§8). Material revisions are approved by the Security Officer in coordination with the Policy Management process.

12. Related policies

• Breach Notification
• Business Continuity & Disaster Recovery
• System Audits & Monitoring
• Threat Management
• AI Governance
• Access Control
• HIPAA Notice & Business Associate Statement