xBxBio Incident Response & Breach Management Policy
Effective Date: March 22, 2026
Last Updated: October 5, 2026
1. Purpose and Public Assurance
This policy establishes xBxBio's public-facing principles for identifying, assessing, containing, investigating, responding to, recovering from, documenting, and learning from security, privacy, data-integrity, clinical-safety, operational, and other reportable incidents. Its purpose is to provide patients, clinicians, caregivers, healthcare organizations, laboratories, research organizations, customers, partners, regulators, and other authorized parties with assurance that incident response and breach management are treated as governed lifecycle activities rather than ad hoc technical events.
2. Public Disclosure Boundary
This is a governance and assurance policy, not an incident-response playbook or engineering specification. Public disclosure is intentionally limited to functional, privacy, security, clinical-safety, quality, legal, regulatory, communication, and governance principles. Detailed response procedures, detection logic, security architecture, credentials, vulnerabilities, forensic methods, internal contacts, thresholds, configurations, and other security-sensitive or implementation-specific information are maintained separately under appropriate controls.
3. Scope
This policy applies, as appropriate, to current and future xBxBio services, applications, modules, interfaces, data stores, development and validation environments, production environments, customer-facing functions, research activities, AI-enabled functions, Virtual Heart functions, suppliers, subprocessors, contractors, and other authorized third parties used by or on behalf of xBxBio.
4. Technology-Neutral and Future-Capability Scope
The absence of a specific technology, vendor, model class, device, interface, infrastructure type, incident type, data category, jurisdiction, or deployment pattern from an illustrative list does not by itself exclude an event from this policy where the event falls within the defined scope.
5. Incident Response Objectives
xBxBio seeks to protect people, information, systems, services, evidence, operations, and trust by detecting material events promptly, assessing risk, limiting harm, preserving relevant evidence, coordinating accountable response, meeting applicable notification obligations, restoring affected capabilities safely, and learning from incidents.
6. Definitions and Interpretation
An incident is an event or series of events that may adversely affect confidentiality, integrity, availability, privacy, clinical safety, regulatory obligations, operations, or other protected interests. A breach is an incident that meets an applicable legal, regulatory, contractual, or policy definition requiring breach-specific assessment or action.
7. Governance
Incident response should operate under defined governance with assigned ownership, decision authority, escalation pathways, documentation, and appropriate participation by security, privacy, legal, quality, clinical, operational, technology, communications, and executive functions as warranted by the event.
8. Accountability
Accountability for incident decisions should be assigned to authorized roles. Technical responders may provide evidence and recommendations, while legal, privacy, clinical, quality, business, and executive decisions remain with the appropriate accountable functions.
9. Good-Faith Reporting
Personnel and authorized users should be encouraged to report suspected incidents, mistakes, suspicious activity, data exposures, safety concerns, and control failures promptly and in good faith. Reporting should not be delayed solely because the reporter is uncertain whether the event meets a formal incident definition.
10. Incident Categories
Events may include security incidents, privacy incidents, data-integrity incidents, clinical-safety incidents, availability incidents, supplier incidents, technology failures, misuse, loss or theft, unauthorized disclosure, malicious activity, or other conditions requiring coordinated response.
11. Security Incidents
Security incidents may include unauthorized access, credential compromise, malware, ransomware, phishing, exploitation, malicious code, denial-of-service activity, inappropriate privilege use, account takeover, suspicious network or application activity, or other events affecting information security.
12. Privacy Incidents
Privacy incidents may include unauthorized use, access, acquisition, disclosure, alteration, loss, destruction, transmission, or exposure of personal information, protected health information, research data, or other regulated or contractually protected information.
13. Data-Integrity Incidents
Data-integrity incidents may include unauthorized or unintended alteration, corruption, deletion, duplication, truncation, misassociation, wrong-patient association, semantic transformation errors, version errors, provenance loss, or other conditions that could change the meaning or reliability of information.
14. Clinical-Safety Incidents
Clinical-safety incidents may include events in which software behavior, data quality, workflow, alerting, interpretation, timing, identity, availability, or other system conditions could contribute to patient harm, inappropriate delay, misleading information, or unsafe reliance.
15. Operational Incidents
Operational incidents may include service outages, degraded performance, failed deployments, dependency failures, backup or restoration problems, cloud or infrastructure disruptions, capacity events, or other conditions affecting reliable operation.
16. Third-Party and Supplier Incidents
An event involving a supplier, subprocessor, contractor, customer-managed dependency, or other third party should be assessed for its potential effect on xBxBio information, systems, customers, patients, obligations, and operations, even when the event occurs outside infrastructure directly operated by xBxBio.
17. AI and Model-Related Incidents
Incidents involving AI-enabled functions may include unauthorized model access, inappropriate data exposure, materially incorrect or unsafe model behavior, provenance loss, unexpected output changes, misuse, or other conditions requiring investigation and risk assessment.
18. Virtual Heart Incident Scope
Incidents involving patient-specific or research-stage Virtual Heart functions should be assessed for potential effects on patient association, source evidence, model-derived outputs, provenance, data integrity, confidentiality, availability, and downstream interpretation without publicly disclosing confidential implementation details.
19. Event Detection
xBxBio should maintain risk-appropriate capabilities to identify suspected incidents through technical monitoring, user reports, customer reports, supplier notifications, operational observations, quality processes, privacy processes, clinical-safety review, or other appropriate sources.
20. Internal Reporting
Suspected incidents should be reported through authorized channels as soon as reasonably practicable so that triage can begin. Internal reporting processes should capture enough information to initiate assessment without requiring the reporter to perform a full investigation.
21. Customer and Partner Reporting
Customers, partners, suppliers, and other authorized parties should have appropriate channels for reporting suspected security, privacy, safety, availability, or data-integrity concerns that may affect xBxBio services or information.
22. Initial Triage
Initial triage should determine whether an event requires incident handling, identify immediately affected systems or information, assess potential urgency, identify known safety or privacy concerns, preserve relevant evidence, and determine whether escalation is needed.
23. Incident Classification
Incidents should be classified using risk-relevant factors such as affected information, affected services, potential patient impact, unauthorized access, scope, persistence, legal obligations, recoverability, business impact, and likelihood of ongoing harm.
24. Severity Assessment
Severity should be assessed using documented criteria appropriate to the nature of the incident. Severity may change as new evidence becomes available, and response actions should be adjusted accordingly.
25. Incident Declaration
Where appropriate, an authorized role should formally declare an incident, assign accountable coordination, establish an incident record, and activate the response functions appropriate to the event.
26. Incident Coordination
Material incidents should be coordinated so that technical, privacy, legal, quality, clinical, operational, communications, supplier, and customer-facing activities are aligned and important decisions are recorded.
27. Security Function
Security personnel should support detection, technical investigation, containment, evidence preservation, risk analysis, remediation, and recovery activities appropriate to the incident while protecting sensitive investigative information.
28. Privacy Function
Privacy personnel should assess affected information, individuals, processing context, applicable privacy obligations, breach criteria, notification requirements, and mitigation measures appropriate to the event.
29. Legal Function
Legal counsel should support interpretation of applicable legal, regulatory, contractual, litigation, law-enforcement, privilege, notification, preservation, and disclosure obligations as appropriate to the incident.
30. Quality Function
Quality personnel should support assessment of quality-system impact, regulated records, validation status, corrective and preventive action, change control, complaint handling, auditability, and other quality obligations where applicable.
31. Clinical and Medical Oversight
Where an incident may affect patient safety, clinical interpretation, clinical workflow, or medically relevant information, appropriate clinical or medical oversight should participate in risk assessment, mitigation, communications, and recovery decisions.
32. Operational and Business Leadership
Operational and business leadership should support prioritization, continuity, customer coordination, resource allocation, risk acceptance, executive escalation, and restoration decisions appropriate to the event.
33. Communications Function
Communications should be coordinated to promote accuracy, consistency, appropriate confidentiality, and timely delivery. Public or external statements should be approved by authorized functions and should not speculate beyond verified facts.
34. Evidence Preservation
Relevant evidence should be preserved in a manner appropriate to the incident, potential legal or regulatory obligations, and investigative needs. Preservation should seek to avoid unnecessary alteration or loss of material evidence.
35. Chain of Custody
Where evidentiary handling requires chain-of-custody controls, transfers, access, collection, storage, and disposition should be documented to support integrity and traceability.
36. Investigation Records
Incident records should document material facts, decisions, actions, approvals, timelines, affected assets or information, notifications, recovery steps, and lessons learned to the extent appropriate and lawful.
37. Fact Verification
Incident decisions and communications should distinguish confirmed facts, reasonable assessments, unresolved questions, and hypotheses. Unverified information should not be presented as established fact.
38. Containment
Containment actions should seek to limit ongoing harm while considering patient safety, evidence preservation, business continuity, data integrity, contractual obligations, and the possibility that abrupt technical action may create additional risk.
39. Eradication and Remediation
Remediation should address identified causes, affected accounts or components, malicious persistence, inappropriate access, configuration issues, data-integrity concerns, and other conditions necessary to support safe recovery.
40. Recovery
Recovery should restore affected capabilities in a controlled manner with appropriate validation, monitoring, reconciliation, security checks, data-integrity review, and confirmation that material risks have been reduced to an acceptable level.
41. Recovery Prioritization
Recovery priorities should consider patient safety, service criticality, affected customers, data integrity, legal obligations, dependencies, operational impact, and the risk of restoring a function before it is ready.
42. Backup and Restoration
Where recovery depends on backups or replicated data, restoration should consider backup integrity, timing, provenance, completeness, security, and the possibility that compromised or corrupted content could be reintroduced.
43. Post-Recovery Monitoring
Recovered services or workflows should be monitored for recurrence, residual compromise, data inconsistency, unexpected behavior, and other signs that further action may be required.
44. Ransomware and Extortion Events
Ransomware, extortion, or destructive malware events should receive coordinated security, legal, privacy, operational, and executive assessment. Decisions regarding containment, recovery, communications, law enforcement, and any prohibited or restricted transactions should follow applicable law and organizational governance.
45. Unauthorized Access
Unauthorized access events should be assessed for the identity and authority of the actor, systems and information accessed, actions taken, persistence, data exposure, integrity effects, and applicable legal or contractual obligations.
46. Data Exfiltration
Suspected or confirmed data exfiltration should be assessed for the data involved, individuals and organizations affected, sensitivity, encryption or other safeguards, destination, persistence, and potential misuse or harm.
47. Cloud and Infrastructure Incidents
Cloud, hosting, storage, compute, network, and infrastructure incidents should be assessed for security, privacy, availability, integrity, location, dependency, and customer impact, including the responsibilities of relevant service providers.
48. Medical Device and Interface Incidents
Incidents involving connected medical devices, interfaces, gateways, or clinical systems should consider device safety, data integrity, patient association, timing, provenance, vendor responsibilities, and any applicable medical-device or healthcare-organization obligations.
49. Protected Health Information
Where protected health information is involved, the incident should be evaluated under applicable HIPAA, HITECH, contractual, state, and other requirements, including whether the event constitutes a reportable breach and which parties hold notification responsibility.
50. Personally Identifiable Information
Where personally identifiable or personal data is involved, assessment should consider the nature and sensitivity of the information, affected individuals, safeguards, likelihood and severity of harm, applicable jurisdiction, and required notification or documentation.
51. De-Identification and Re-Identification Risk
An event involving de-identified, pseudonymized, coded, or otherwise transformed data should be assessed for the possibility of re-identification, linkage, unauthorized reversal, or exposure of associated keys or contextual information.
52. Research Data Incidents
Research-data incidents should consider participant confidentiality, consent or authorization, protocol requirements, institutional responsibilities, sponsor obligations, data integrity, publication concerns, and applicable research oversight.
53. Wrong-Patient and Identity Incidents
Events involving wrong-patient association, duplicate identities, record merges, mismatched identifiers, or other identity errors should be treated as potentially significant safety and data-integrity incidents and should support appropriate correction, reconciliation, and downstream review.
54. Temporal and Provenance Incidents
Events that alter or obscure timestamps, source identity, acquisition sequence, version history, or provenance should be assessed for their potential to change clinical, analytical, legal, or operational meaning.
55. AI Output Incidents
An incident involving materially incorrect, unsafe, misleading, unauthorized, or unexpectedly changed AI output should be assessed for affected users, patients, data, versions, workflows, downstream actions, and the need to limit or suspend use while evaluation occurs.
56. Model Drift and Performance Degradation
Material performance degradation, drift, or unexpected changes in AI-enabled behavior should be assessed under appropriate model and clinical-safety governance and may require limitation, rollback, revalidation, or other corrective action.
57. Alerting and Notification Failures
Failures in clinically or operationally important alerts, notifications, acknowledgements, routing, or escalation should be assessed for missed or delayed action, duplicate communication, user burden, and any patient or customer impact.
58. Breach Assessment
A suspected breach should be evaluated under applicable legal, regulatory, contractual, and policy criteria. The assessment should consider what information was involved, who accessed or received it, available safeguards, evidence of acquisition or viewing, mitigation, and reasonably foreseeable harm.
59. HIPAA and HITECH Considerations
Where HIPAA or HITECH applies, xBxBio should support the responsible covered entity or business associate in meeting applicable breach-assessment, documentation, notification, and cooperation obligations, including applicable timing requirements, without assuming a legal role not established by the relevant relationship.
60. GDPR Considerations
Where the EU General Data Protection Regulation applies, personal-data breaches should be assessed for risk to individuals' rights and freedoms, supervisory-authority notification, data-subject communication, documentation, controller-processor responsibilities, and applicable timing requirements.
61. UK Data Protection Considerations
Where UK data-protection law applies, personal-data breaches should be assessed for applicable reporting to the Information Commissioner's Office, communication to affected individuals when required, documentation, and controller-processor responsibilities under the law in effect at the time of the event.
62. United States State-Law Considerations
Where United States state privacy, breach-notification, consumer-protection, health-data, biometric, or other laws apply, notification and response should reflect the affected individuals, information types, residence, role of the parties, and requirements in effect for the relevant jurisdiction.
63. Canada Considerations
Where Canadian federal or provincial privacy law applies, incidents should be assessed for applicable breach, recordkeeping, regulator, individual-notification, contractual, and safeguarding obligations based on the relevant jurisdiction and organizational role.
64. Japan Considerations
Where Japanese privacy requirements apply, incidents should be assessed for applicable Personal Information Protection Commission reporting, individual notification, processor or service-provider responsibilities, and other requirements in effect for the relevant processing context.
65. Australia Considerations
Where Australian privacy law applies, incidents should be assessed for applicable Notifiable Data Breaches requirements, serious-harm considerations, regulator and individual notification, and other obligations appropriate to the organization and data involved.
66. Brazil Considerations
Where Brazil's data-protection requirements apply, incidents should be assessed for applicable controller and processor responsibilities, risk, security measures, data-subject impact, authority notification, and other obligations under law and regulatory guidance in effect at the time.
67. Other Jurisdictions
xBxBio should assess incident obligations under other applicable countries, territories, states, provinces, sectors, and customer arrangements without relying on a public policy to enumerate every potentially applicable requirement.
68. Contractual Notification
Customer, partner, supplier, insurer, sponsor, research, or other contracts may establish incident-notification, cooperation, preservation, remediation, or reporting duties in addition to legal requirements. Applicable contractual obligations should be identified and managed.
69. Regulatory Notification
Regulatory notification should be made by the authorized party within the time and manner required by applicable law. Notifications should be accurate, appropriately scoped, and updated when material facts change.
70. Notification to Affected Individuals
Where notification to affected individuals is required or otherwise appropriate, communications should explain material known facts, the information involved where appropriate, recommended protective actions, response measures, and contact channels without unnecessary technical detail or speculation.
71. Customer Notification
Customers should be informed of incidents affecting their information, services, responsibilities, or regulatory obligations when required by law, contract, or risk-based governance. Communications should identify known impacts, relevant actions, and any customer steps reasonably needed.
72. Supplier and Subprocessor Coordination
Suppliers and sub-processors should be required, as appropriate to the relationship, to notify xBxBio of relevant incidents, preserve evidence, cooperate with investigation, support notifications, remediate issues, and provide information needed for risk assessment.
73. Law Enforcement and Government Requests
Coordination with law enforcement or other government authorities should be handled by authorized personnel and legal counsel as appropriate. Any delay or limitation on notification requested by an authority should be documented and handled according to applicable law.
74. Public Communications
Public statements should be factual, coordinated, and proportionate to the incident. xBxBio should avoid premature attribution, unsupported conclusions, unnecessary disclosure of sensitive investigative information, or statements that could mislead affected parties.
75. Media Inquiries
Media inquiries concerning material incidents should be directed to authorized communications channels. Individuals involved in response should not provide unauthorized public statements or disclose confidential investigative details.
76. Confidentiality of Investigations
Incident investigations may involve sensitive security, privacy, legal, personnel, customer, patient, confidential, or law-enforcement information. Access should be limited to authorized persons with a legitimate need to know.
77. Personnel and Insider Events
Suspected insider misuse, inappropriate access, fraud, sabotage, or other personnel-related events should be investigated with appropriate security, privacy, legal, human-resources, and management participation while respecting due process and applicable law.
78. Patient-Safety Escalation
Any incident with a credible possibility of patient harm or clinically significant misinformation should be escalated promptly to appropriate clinical, quality, and operational leadership for assessment and mitigation.
79. Complaint and Adverse-Event Coordination
Where an incident overlaps with a product complaint, safety complaint, adverse event, medical-device reporting obligation, or other regulated quality process, the relevant processes should be coordinated so that required records and actions are not missed or duplicated inconsistently.
80. Corrective and Preventive Action
Material root causes, systemic control failures, recurring issues, or regulated quality findings should be evaluated for corrective and preventive action or equivalent improvement processes appropriate to the applicable quality system.
81. Root-Cause Analysis
Root-cause analysis should be proportionate to incident significance and should distinguish proximate technical causes from contributing process, governance, human, supplier, design, training, or organizational factors.
82. Lessons Learned
After material incidents, xBxBio should identify lessons that can reduce recurrence, improve detection, strengthen response, clarify responsibilities, improve recovery, and address gaps in policy, technology, training, contracts, or governance.
83. Post-Incident Review
A post-incident review should be performed for significant incidents and should assess material facts, response effectiveness, communications, decision quality, evidence, recovery, unresolved risks, corrective actions, and opportunities for improvement.
84. Action Tracking
Corrective actions arising from an incident should be assigned, prioritized, tracked, reviewed, and closed using governance appropriate to their risk and regulatory significance.
85. Change Management
Changes resulting from incident response should be implemented under appropriate change control when they can affect security, privacy, validated state, clinical behavior, availability, data integrity, customer obligations, or other controlled characteristics.
86. Training and Awareness
Personnel should receive incident-reporting, privacy, security, safety, and role-specific response training appropriate to their responsibilities. Training should reinforce prompt reporting and protection of sensitive investigative information.
87. Exercises and Simulations
Incident-response capabilities should be exercised periodically using risk-appropriate scenarios such as privacy incidents, ransomware, supplier compromise, service outages, data-integrity events, or clinical-safety concerns. Exercises should focus on coordination and decision-making without exposing sensitive operational details publicly.
88. Testing of Notification Processes
Organizations should periodically verify that incident escalation, contact, approval, customer-communication, regulator-notification, and other response processes remain usable and appropriately governed.
89. Metrics and Performance Review
Incident-response metrics may be used to evaluate timeliness, recurring causes, control effectiveness, response burden, remediation progress, notification performance, and other indicators useful for governance, provided metrics are interpreted in context.
90. Trend Analysis
Incident and near-miss information should be reviewed for recurring patterns, common causes, supplier trends, control weaknesses, human factors, technology risks, and opportunities for preventive improvement.
91. Near Misses
Events that could have caused material harm but did not should be considered for review when they reveal meaningful control weaknesses, unsafe conditions, or opportunities to prevent future incidents.
92. Record Retention
Incident records, evidence, notifications, assessments, approvals, corrective actions, and related documentation should be retained in accordance with applicable legal, regulatory, contractual, quality, litigation-hold, and organizational requirements.
93. Access to Incident Records
Access to incident records should be limited according to confidentiality, privacy, security, legal, clinical, quality, and business need. Sensitive incident records should not be broadly distributed merely because an event has concluded.
94. Auditability
Incident-response activities should be sufficiently documented to support appropriate internal review, customer assurance, regulatory inquiry, legal obligations, quality oversight, and continual improvement.
95. Framework Alignment
xBxBio may use recognized frameworks and standards, as applicable, to inform incident-response governance, including NIST Cybersecurity Framework 2.0, NIST SP 800-61 Rev. 3, ISO/IEC 27035 series, relevant privacy laws, healthcare obligations, and customer requirements. Alignment does not by itself constitute certification or regulatory approval.
96. Relationship to Business Continuity
Incident response and business continuity are related but distinct. Incident response focuses on controlling and investigating an event, while continuity and disaster recovery focus on maintaining or restoring essential operations. The activities should be coordinated when an incident disrupts services or recovery affects evidence or security.
97. Relationship to IT and Security Policy
This policy complements xBxBio's IT and Security Policy. Preventive safeguards do not eliminate incident risk, and incident response does not replace ongoing security governance, vulnerability management, access control, monitoring, or other preventive controls.
98. Relationship to Privacy Policy
This policy complements xBxBio's Privacy Policy by addressing the response and notification processes that may apply when personal information is improperly accessed, used, acquired, disclosed, altered, lost, or destroyed.
99. Relationship to Clinical Safety Policy
This policy complements xBxBio's Clinical Safety & Human Oversight Policy when an event may affect patient safety, clinical meaning, alerting, source evidence, patient identity, model-derived information, or other clinically relevant behavior.
100. Relationship to Quality Policy
This policy complements xBxBio's Quality Policy where incidents reveal nonconformities, product or service
complaints, validation concerns, corrective actions, regulated records, or other quality-system implications.
101. Relationship to Compliance and Regulatory Policy
Incident response should be coordinated with xBxBio's Compliance & Regulatory Policy so that applicable regulatory, contractual, jurisdictional, and recordkeeping obligations are identified and handled by accountable functions.
102. Public Information Boundary
This public policy is intended to explain governance principles without exposing security-sensitive or confidential implementation details. xBxBio does not publicly disclose incident playbooks, detection logic, vulnerability details, credentials, internal contact lists, forensic procedures, security architecture, monitoring configurations, or other information that could materially increase operational or cybersecurity risk.
103. Policy Review
This policy should be reviewed periodically and following significant incidents, material regulatory changes, new services, major technology changes, new jurisdictions, changes in data categories, or other developments that could materially affect incident response or breach-management obligations.
104. Important Incident Response & Breach Management Disclaimer
This policy describes xBxBio's general public-facing approach to incident response and breach management. It does not establish that every event is a breach, guarantee that every incident can be prevented, guarantee a particular investigation result, constitute legal advice, create clinical authority, replace customer or partner responsibilities, or represent certification, regulatory approval, or compliance with every law in every jurisdiction. Specific obligations depend on the facts, affected information, contractual relationships, organizational roles, jurisdiction, applicable law, and requirements in effect at the time of the event.
105. Global Protection Statement
No country, territory, customer configuration, deployment model, facility, technical environment, interface, vendor, cloud provider, model, or contractual arrangement is intended to eliminate xBxBio's fundamental requirements for patient protection, human accountability, authorized access, information integrity, provenance, privacy, security, quality, incident governance, and appropriate breach management. A country or territory does not need to be individually named in this public policy for the global baseline to apply where xBxBio lawfully conducts relevant activities.
END OF XBXBIO INCIDENT RESPONSE & BREACH MANAGEMENT POLICY