1. Purpose

xBxBio recognizes that information security, cybersecurity, privacy, data integrity, operational resilience, and trustworthy technology are foundational to the responsible development and operation of healthcare and life-sciences technology.

This IT & Security Policy establishes xBxBio’s general framework for protecting information, information systems, software, infrastructure, development environments, applications, interfaces, artificial-intelligence systems, connected technologies, and other digital resources under xBxBio’s control.

The objectives of this policy are to support:

• Confidentiality of information;

• Integrity and authenticity of information;

• Availability and resilience of systems and services;

• Appropriate access and least privilege;

• Accountability and traceability;

• Secure software and system development;

• Protection of personal, health, clinical, scientific, business, and confidential information;

• Prevention, detection, response, containment, recovery, and learning from cybersecurity events;

• Regulatory and contractual security obligations;

• Secure integration with healthcare systems, devices, applications, and third-party services;

• Responsible use of artificial intelligence and machine learning;

• Business continuity and disaster recovery;

• Risk-based security decision-making; and

• Continuous improvement of xBxBio’s information-security posture.

2. Scope

This policy applies, as appropriate, to:

• xBxBio personnel;

• Officers;

• Directors;

• Employees;

• Contractors;

• Consultants;

• Temporary personnel;

• Authorized developers;

• Service providers;

• Vendors;

• Business partners;

• Technology partners;

• Subprocessors;

• Managed-service providers;

• Cloud-service providers;

• Systems administrators;

• Application administrators;

• Authorized users; and

• Any other individual or organization granted access to xBxBio-controlled information or systems.

This policy may apply to:

• Production systems;

• Development systems;

• Test systems;

• Validation environments;

• Demonstration environments;

• Research environments;

• Cloud environments;

• Local computing environments;

• Networks;

• Databases;

• APIs;

• Applications;

• Source-code repositories;

• Data stores;

• Backup systems;

• Collaboration platforms;

• Artificial-intelligence systems;

• Machine-learning systems;

• Clinical integrations;

• Connected medical technologies;

• Software interfaces;

• Virtual machines;

• Containers;

• Endpoints;

• Mobile devices;

• Remote-access systems; and

• Other technology used to support xBxBio activities.

3. Security Governance

xBxBio applies a risk-based information-security governance model.

Security responsibilities may include:

• Establishment of information-security policies and standards;

• Identification of security risks;

• Assignment of security responsibilities;

• Technical-security controls;

• Access governance;

• Risk assessment;

• Vulnerability management;

• Incident response;

• Vendor-security oversight;

• Business continuity;

• Disaster recovery;

• Training and awareness;

• Secure-development practices;

• System validation where applicable;

• Documentation;

• Auditability;

• Change management;

• Configuration management;

• Data protection;

• Periodic security review; and

• Management oversight.

Security controls are selected and maintained based on factors including:

• Nature of the system;

• Intended use;

• Data sensitivity;

• Data classification;

• Threat environment;

• System architecture;

• User population;

• Deployment model;

• Clinical relevance;

• Regulatory classification;

• Geographic jurisdiction;

• Customer obligations;

• Contractual requirements;

• Business impact;

• Technology maturity;

• Development stage; and

• Reasonably foreseeable cybersecurity risks.

4. Security Frameworks and Standards

Where relevant and appropriate, xBxBio may use recognized security standards, frameworks, control models, or guidance to inform its security program.

These may include:

• NIST Cybersecurity Framework 2.0;

• NIST Risk Management Framework;

• NIST SP 800-series guidance;

• NIST Privacy Framework;

• NIST Secure Software Development Framework;

• ISO/IEC 27001;

• ISO/IEC 27002;

• ISO/IEC 27017;

• ISO/IEC 27018;

• ISO/IEC 27701;

• ISO 22301;

• ISO 31000;

• ISO 14971 where medical-device risk management is applicable;

• IEC 62304 where medical-device software lifecycle requirements apply;

• IEC 81001-5-1 where health-software cybersecurity requirements apply;

• AAMI cybersecurity guidance where applicable;

• OWASP;

• OWASP Application Security Verification Standard;

• OWASP Software Assurance Maturity Model;

• CIS Critical Security Controls;

• CIS Benchmarks;

• SOC 2 Trust Services Criteria;

• HITRUST concepts where applicable;

• FDA medical-device cybersecurity guidance;

• U.S. Department of Health and Human Services cybersecurity guidance;

• Applicable governmental cybersecurity frameworks; and

• Other recognized standards relevant to a particular product, deployment, or jurisdiction.

Use of or reference to a framework does not by itself mean that xBxBio has obtained certification, attestation, accreditation, authorization, or independent validation under that framework unless expressly stated in writing.

NIST CSF 2.0 is designed to help organizations manage cybersecurity risk regardless of size or sector and includes governance and supply-chain considerations. NIST

5. Information Classification

Information may be classified according to sensitivity, risk, legal requirements, contractual obligations, and business value.

Classification categories may include:

Public

Information authorized for public disclosure.

Internal

Information intended primarily for authorized xBxBio personnel or approved collaborators.

Confidential

Information requiring protection from unauthorized disclosure.

Restricted / Highly Sensitive

Information requiring enhanced controls because unauthorized use or disclosure could create substantial legal, regulatory, clinical, operational, financial, intellectual-property, or privacy risk.

Restricted information may include, where applicable:

• Protected health information;

• Electronic protected health information;

• Personal data;

• Personally identifiable information;

• Sensitive personal data;

• Genetic information;

• Biometric information;

• Authentication credentials;

• Encryption keys;

• Security secrets;

• Source code;

• Proprietary algorithms;

• Customer confidential information;

• Security configurations;

• Vulnerability information;

• Incident information;

• Trade secrets;

• Intellectual property;

• Research data;

• Clinical data; and

• Regulated records.

6. Data Minimization

xBxBio seeks to limit collection, access, use, transmission, storage, and retention of information to what is reasonably necessary for authorized purposes.

Where feasible, security and privacy practices may include:

• Data minimization;

• Purpose limitation;

• De-identification;

• Pseudonymization;

• Tokenization;

• Aggregation;

• Masking;

• Redaction;

• Separation of identifiers;

• Restricted-access datasets;

• Synthetic data for development or testing; and

• Avoidance of production data in non-production environments unless specifically authorized and protected.

7. Identity and Access Management

Access to xBxBio systems should be based on legitimate business need and authorized roles.

Controls may include:

• Unique user identities;

• Role-based access control;

• Attribute-based access controls where appropriate;

• Least privilege;

• Need-to-know principles;

• Separation of duties;

• Privileged-access restrictions;

• Access approvals;

• Periodic access reviews;

• Account lifecycle management;

• Prompt account disablement when access is no longer required;

• Password controls;

• Multi-factor authentication;

• Conditional access;

• Session controls;

• Account lockout;

• Authentication monitoring;

• Administrative-account separation; and

• Privileged-access logging.

Shared credentials should be avoided except where technically necessary and appropriately controlled.

8. Multi-Factor Authentication

Multi-factor authentication should be used where appropriate for systems presenting elevated risk, including where technically feasible:

• Administrative access;

• Remote access;

• Cloud-management interfaces;

• Source-code repositories;

• Production systems;

• Security tools;

• Sensitive data environments;

• Privileged accounts;

• Identity-management platforms; and

• Other high-risk applications.

9. Password and Authentication Security

Authentication controls may include:

• Strong password requirements;

• Prevention of known compromised passwords;

• Password-manager use;

• Secure credential storage;

• Salted and appropriately hashed password storage;

• Protection against credential stuffing;

• Protection against brute-force attacks;

• Authentication rate limiting;

• Login monitoring;

• Detection of unusual authentication patterns; and

• Secure account-recovery procedures.

Passwords should not be stored in plaintext.

10. Privileged Access

Privileged accounts may receive enhanced controls, including:

• Separate administrative identities;

• Multi-factor authentication;

• Least privilege;

• Just-in-time access where appropriate;

• Restricted duration;

• Logging;

• Monitoring;

• Approval;

• Periodic review;

• Stronger authentication requirements; and

• Removal of unnecessary administrative privileges.

11. Encryption

xBxBio uses or seeks to use encryption appropriate to system risk, architecture, and applicable requirements.

Controls may include:

Data in Transit

Use of secure transport technologies such as:

• TLS;

• HTTPS;

• Secure APIs;

• Secure file-transfer mechanisms;

• VPN technologies;

• Encrypted administrative connections; and

• Other approved encrypted communication methods.

Data at Rest

Sensitive information may be encrypted when stored in:

• Databases;

• File systems;

• Object storage;

• Backups;

• Endpoints;

• Portable devices;

• Cloud storage; and

• Other storage environments.

Key Management

Encryption keys and secrets should be protected throughout their lifecycle, including:

• Generation;

• Storage;

• Distribution;

• Rotation;

• Revocation;

• Backup;

• Recovery; and

• Destruction.

Encryption requirements may be adjusted based on applicable law, customer requirements, deployment environment, and risk.

12. Cryptographic Standards

xBxBio seeks to use accepted cryptographic technologies and avoid obsolete algorithms where reasonable.

Cryptographic controls may consider:

• Current industry guidance;

• NIST recommendations;

• Regulatory expectations;

• Customer requirements;

• System compatibility;

• Data sensitivity; and

• Threat models.

Cryptographic algorithms, protocols, and key lengths may be updated as security standards evolve.

13. Network Security

Network-security practices may include:

• Network segmentation;

• Firewall controls;

• Access-control lists;

• Restricted administrative interfaces;

• Secure network configuration;

• Network monitoring;

• Intrusion detection;

• Intrusion prevention;

• Secure remote access;

• VPN controls;

• Zero-trust principles;

• Domain-name-system protections;

• Denial-of-service protections;

• Segregation of development and production environments;

• Restriction of unnecessary ports and services; and

• Logging of significant network activity.

14. Zero-Trust Principles

Where appropriate, xBxBio may apply zero-trust concepts including:

• Verify explicitly;

• Minimize implicit trust;

• Assume compromise is possible;

• Limit lateral movement;

• Continuously evaluate access;

• Apply least privilege;

• Segment resources;

• Authenticate users and devices;

• Monitor sensitive activities; and

• Use contextual access decisions.

15. Endpoint Security

Endpoints may be protected through:

• Secure configuration;

• Operating-system updates;

• Anti-malware controls;

• Endpoint-detection and response;

• Host firewalls;

• Encryption;

• Screen locking;

• Restricted administrative privileges;

• Application controls;

• Device inventory;

• Configuration monitoring;

• Secure disposal;

• Remote wipe where appropriate; and

• Patch management.

16. Mobile Device Security

Where mobile devices access xBxBio information, safeguards may include:

• Screen locks;

• Device encryption;

• Supported operating systems;

• Remote wipe;

• Mobile-device management;

• Restricted local storage;

• Authentication requirements;

• Separation of business and personal data;

• Prohibition of unauthorized applications; and

• Secure network use.

17. Remote Access

Remote access to sensitive systems should be controlled.

Controls may include:

• Authorized remote-access mechanisms;

• Multi-factor authentication;

• VPN or encrypted access;

• Device-security requirements;

• Restricted administrative access;

• Logging;

• Session termination;

• Monitoring; and

• Geographic or risk-based restrictions where appropriate.

18. Cloud Security

Cloud environments may be managed using security practices such as:

• Identity and access controls;

• Least privilege;

• Encryption;

• Secure configuration;

• Logging;

• Monitoring;

• Resource inventory;

• Network segmentation;

• Backup;

• Recovery;

• Configuration management;

• Vulnerability management;

• Cloud security posture review;

• Secrets management; and

• Vendor-risk assessment.

xBxBio recognizes the shared-responsibility model applicable to cloud computing.

19. Secure Software Development Lifecycle

Security is intended to be incorporated throughout the software-development lifecycle.

Activities may include:

• Security requirements;

• Architecture review;

• Threat modeling;

• Secure coding;

• Code review;

• Dependency management;

• Static analysis;

• Dynamic analysis;

• Software-composition analysis;

• Vulnerability scanning;

• Security testing;

• Penetration testing where appropriate;

• Configuration testing;

• Release controls;

• Change management;

• Defect tracking;

• Security acceptance criteria; and

• Post-release monitoring.

20. Secure Coding

Developers are expected to consider secure-coding practices designed to reduce risks including:

• Injection;

• Cross-site scripting;

• Cross-site request forgery;

• Broken authentication;

• Broken access control;

• Server-side request forgery;

• Insecure deserialization;

• Memory-safety vulnerabilities;

• Path traversal;

• Command injection;

• SQL injection;

• Improper input validation;

• Sensitive-data exposure;

• Insecure cryptography;

• Security misconfiguration;

• Race conditions;

• API abuse;

• Excessive permissions; and

• Other recognized software weaknesses.

21. Source-Code Security

Source-code repositories should be protected through controls such as:

• Authorized access;

• Role-based permissions;

• Multi-factor authentication;

• Branch protection;

• Review requirements;

• Commit history;

• Access logging;

• Secret scanning;

• Dependency monitoring;

• Repository backup where appropriate; and

• Prevention of unauthorized public disclosure.

Secrets, credentials, private keys, and sensitive production information should not intentionally be committed to source-code repositories.

22. Software Supply-Chain Security

xBxBio recognizes cybersecurity risks associated with third-party and open-source software.

Controls may include:

• Dependency inventories;

• Package verification;

• Source verification;

• Version control;

• Vulnerability monitoring;

• License review;

• Software-composition analysis;

• Patch review;

• Approved repositories;

• Integrity verification;

• Security assessment of critical dependencies; and

• Replacement or mitigation of unsafe dependencies.

23. Software Bill of Materials

Where appropriate or required, xBxBio may generate or maintain a Software Bill of Materials for applicable software components.

SBOM information may include:

• Component name;

• Component version;

• Supplier;

• Dependency relationships;

• Package identifiers;

• Licensing information; and

• Other information relevant to software transparency and vulnerability management.

FDA continues to emphasize cybersecurity and SBOM-related practices for connected medical technologies. U.S. Food and Drug Administration

24. API Security

APIs should be designed and operated with safeguards appropriate to risk.

Controls may include:

• Authentication;

• Authorization;

• Encryption;

• Input validation;

• Rate limiting;

• Schema validation;

• Token expiration;

• Scope limitations;

• Secret management;

• Logging;

• Monitoring;

• Abuse detection;

• Version management; and

• Secure error handling.

25. Database Security

Database safeguards may include:

• Restricted access;

• Encryption;

• Authentication;

• Authorization;

• Network restrictions;

• Audit logging;

• Query monitoring;

• Backup;

• Recovery;

• Secure configuration;

• Patch management;

• Data masking; and

• Separation of administrative and application accounts.

26. Container and Virtualization Security

Where containerization or virtualization is used, security controls may include:

• Approved images;

• Image scanning;

• Minimal base images;

• Signed artifacts where appropriate;

• Restricted privileges;

• Runtime monitoring;

• Network isolation;

• Secrets management;

• Configuration control;

• Patch management;

• Host security;

• Registry security; and

• Resource isolation.

27. Infrastructure as Code

Infrastructure-as-code practices may include:

• Version control;

• Peer review;

• Change traceability;

• Secret protection;

• Configuration scanning;

• Policy enforcement;

• Testing;

• Approval processes; and

• Controlled deployment.

28. Logging and Monitoring

Security-relevant activity may be logged based on system risk and applicable requirements.

Logs may include:

• Authentication events;

• Administrative actions;

• Access to sensitive information;

• Security events;

• Configuration changes;

• Application events;

• System errors;

• Network events;

• API activity;

• Data exports;

• Privilege changes; and

• Other significant actions.

Logging practices should consider:

• Integrity;

• Retention;

• Time synchronization;

• Access controls;

• Confidentiality;

• Availability;

• Centralization; and

• Monitoring.

29. Audit Trails

Where regulatory, clinical, quality, security, or contractual requirements apply, xBxBio may maintain audit trails designed to provide traceability of relevant activities.

Audit trails may record:

• User;

• Date;

• Time;

• Action;

• Record affected;

• Prior value;

• New value;

• Reason for change where required; and

• Relevant system context.

Audit-trail controls may be designed to support applicable requirements including 21 CFR Part 11 and regulated-record expectations where applicable.

30. Time Synchronization

Systems generating security, audit, or regulatory records should use appropriately synchronized time sources where feasible.

This supports:

• Incident investigation;

• Event correlation;

• Auditability;

• Record integrity;

• Authentication monitoring; and

• Forensic analysis.

31. Vulnerability Management

xBxBio may maintain a risk-based vulnerability-management process that includes:

• Identification;

• Scanning;

• Assessment;

• Prioritization;

• Remediation;

• Mitigation;

• Verification;

• Documentation; and

• Closure.

Prioritization may consider:

• Severity;

• Exploitability;

• Exposure;

• Asset criticality;

• Data sensitivity;

• Known exploitation;

• Clinical impact;

• Business impact; and

• Available mitigations.

32. Patch Management

Security patches and updates should be evaluated and deployed according to risk.

Factors may include:

• Vulnerability severity;

• Known exploitation;

• System criticality;

• Operational impact;

• Compatibility;

• Validation requirements;

• Clinical safety;

• Vendor guidance; and

• Availability of compensating controls.

33. Security Testing

Security testing may include:

• Vulnerability scanning;

• Static application-security testing;

• Dynamic application-security testing;

• Software-composition analysis;

• Configuration analysis;

• Dependency scanning;

• Container scanning;

• API testing;

• Authentication testing;

• Authorization testing;

• Penetration testing;

• Network testing;

• Threat modeling; and

• Manual security review.

Testing depth depends on system risk, development stage, intended use, customer obligations, and regulatory requirements.

34. Penetration Testing

Penetration testing may be performed for appropriate systems based on:

• Risk;

• Product maturity;

• Customer requirements;

• Major architectural changes;

• Regulatory expectations;

• Deployment environment; and

• Availability of appropriate testing resources.

Findings should be assessed and addressed using risk-based remediation.

35. Malware Protection

Systems may use safeguards designed to detect or prevent:

• Viruses;

• Trojans;

• Ransomware;

• Spyware;

• Rootkits;

• Malicious scripts;

• Credential theft;

• Unauthorized persistence; and

• Other malicious software.

36. Email and Messaging Security

Security measures may include:

• Anti-phishing protections;

• Spam filtering;

• Malware scanning;

• Link protection;

• Attachment controls;

• Domain-security controls;

• User awareness;

• Multi-factor authentication;

• Email authentication protocols; and

• Monitoring for suspicious activity.

37. Phishing and Social Engineering

Personnel should exercise caution regarding:

• Suspicious emails;

• Unexpected attachments;

• Credential requests;

• Financial requests;

• Urgent instructions;

• Impersonation attempts;

• SMS phishing;

• Voice phishing;

• Business-email compromise;

• QR-code phishing; and

• Social-media-based attacks.

Suspicious communications should be reported through designated channels.

38. Security Awareness and Training

Appropriate personnel may receive security education covering:

• Password security;

• Multi-factor authentication;

• Phishing;

• Social engineering;

• Privacy;

• Data handling;

• Incident reporting;

• Secure remote work;

• Device security;

• Secure software development;

• Regulatory responsibilities; and

• Role-specific security requirements.

39. Physical Security

Physical safeguards may include:

• Restricted facility access;

• Device protection;

• Visitor controls;

• Secure work areas;

• Screen privacy;

• Secure storage;

• Equipment inventories;

• Environmental safeguards;

• Secure destruction;

• Physical access monitoring; and

• Protection of portable media.

40. Removable Media

Use of removable media may be restricted based on risk.

Where permitted, controls may include:

• Authorization;

• Encryption;

• Malware scanning;

• Inventory;

• Secure handling;

• Controlled transfer; and

• Secure destruction.

41. Backup

xBxBio may maintain backups appropriate to business and system requirements.

Backup controls may include:

• Scheduled backups;

• Encryption;

• Restricted access;

• Geographic separation;

• Immutable or offline copies where appropriate;

• Integrity verification;

• Monitoring;

• Retention controls; and

• Restoration testing.

42. Disaster Recovery

Disaster-recovery planning may address:

• System restoration;

• Data restoration;

• Infrastructure recovery;

• Alternative infrastructure;

• Recovery priorities;

• Recovery dependencies;

• Communications;

• Testing;

• Documentation; and

• Lessons learned.

Recovery Time Objectives and Recovery Point Objectives may be established for applicable systems.

43. Business Continuity

xBxBio seeks to maintain continuity plans proportionate to operational risk.

Planning may consider:

• Cyber incidents;

• Technology failures;

• Cloud outages;

• Network outages;

• Utility failures;

• Natural disasters;

• Facility disruptions;

• Supply-chain disruptions;

• Workforce disruptions;

• Critical vendor failures; and

• Other significant events.

44. Incident Response

xBxBio maintains or intends to maintain an incident-response process appropriate to its operations.

Incident-response activities may include:

1. Preparation;

2. Detection;

3. Analysis;

4. Classification;

5. Containment;

6. Preservation of evidence;

7. Eradication;

8. Recovery;

9. Notification;

10. Documentation;

11. Root-cause analysis; and

12. Lessons learned.

45. Security Incident Reporting

Personnel should promptly report suspected:

• Unauthorized access;

• Data disclosure;

• Malware;

• Ransomware;

• Credential compromise;

• Lost devices;

• Suspicious authentication;

• Phishing;

• Security vulnerabilities;

• Data alteration;

• Service disruption;

• Insider misuse;

• Unauthorized software; and

• Other cybersecurity concerns.

46. Breach Assessment and Notification

Potential breaches involving personal, health, confidential, regulated, or customer information will be evaluated under applicable legal, regulatory, and contractual requirements.

Where required, xBxBio may provide notifications to:

• Affected individuals;

• Customers;

• Data controllers;

• Business partners;

• Regulators;

• Supervisory authorities;

• Government agencies;

• Law enforcement;

• Insurers; and

• Other required parties.

Notification timing and content depend on the applicable law and circumstances.

47. Security Incident Evidence Preservation

Incident investigations may preserve relevant information such as:

• Logs;

• System images;

• Network records;

• Authentication data;

• Configuration records;

• Audit trails;

• Emails;

• Files;

• Access records; and

• Other evidence.

Evidence should be handled in a manner designed to preserve integrity and traceability.

48. Ransomware Preparedness

Controls may include:

• Secure backups;

• Offline or immutable backups;

• Endpoint protection;

• Network segmentation;

• Multi-factor authentication;

• Least privilege;

• Patch management;

• User training;

• Monitoring;

• Incident-response planning; and

• Recovery testing.

49. Third-Party Security

Third parties may be subject to security review based on risk.

Assessment may consider:

• Data accessed;

• Services provided;

• System criticality;

• Security controls;

• Privacy practices;

• Regulatory requirements;

• Contractual terms;

• Incident history;

• Subprocessors;

• Business continuity;

• Data location;

• Audit rights;

• Cyber insurance where appropriate; and

• Security certifications where relevant.

50. Vendor Contracts

Security requirements may be incorporated into contracts where appropriate.

Terms may address:

• Confidentiality;

• Security requirements;

• Data protection;

• Access controls;

• Incident notification;

• Subprocessors;

• Audit rights;

• Data return;

• Data deletion;

• Business continuity;

• Regulatory cooperation;

• Security testing;

• Breach response; and

• Termination obligations.

51. Supply-Chain Cybersecurity

xBxBio considers cybersecurity risk across technology supply chains.

Risks may include:

• Compromised software;

• Malicious dependencies;

• Counterfeit components;

• Vulnerable libraries;

• Vendor compromise;

• Cloud-provider incidents;

• Dependency abandonment;

• Unauthorized updates;

• Build-system compromise; and

• Third-party access.

NIST CSF 2.0 places increased emphasis on cybersecurity governance and supply-chain risk. NIST

52. Healthcare Information Security

Where xBxBio processes health information, safeguards may be designed to protect:

• Confidentiality;

• Integrity;

• Availability;

• Authenticity;

• Traceability;

• Appropriate use; and

• Appropriate disclosure.

Healthcare security requirements may depend on xBxBio’s legal role, contractual relationship, product function, and jurisdiction.

53. HIPAA and HITECH

Where xBxBio acts as a HIPAA covered entity, business associate, or subcontractor subject to HIPAA, xBxBio will apply applicable requirements of:

• HIPAA;

• HITECH;

• HIPAA Privacy Rule;

• HIPAA Security Rule;

• HIPAA Breach Notification Rule; and

• Applicable implementing regulations.

The HIPAA Security Rule requires appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of ePHI. HHS.gov

References to HIPAA on this page do not mean that every xBxBio activity is subject to HIPAA.

54. Electronic Protected Health Information

Where applicable, safeguards for ePHI may include:

• Risk analysis;

• Risk management;

• Access controls;

• Unique user identification;

• Authentication;

• Audit controls;

• Integrity controls;

• Transmission security;

• Workforce security;

• Security awareness;

• Contingency planning;

• Incident procedures;

• Device controls;

• Facility safeguards; and

• Vendor or business-associate controls.

55. Medical-Device Cybersecurity

Where an xBxBio product is determined to be a regulated medical device or cyber device, cybersecurity activities may incorporate applicable medical-device requirements and guidance.

Considerations may include:

• Secure product architecture;

• Threat modeling;

• Cybersecurity risk assessment;

• Security requirements;

• Security testing;

• SBOM;

• Vulnerability management;

• Patchability;

• Secure updates;

• Coordinated vulnerability disclosure;

• Postmarket monitoring;

• Security labeling;

• Cybersecurity documentation; and

• Safety-risk integration.

FDA issued updated final guidance in February 2026 addressing cybersecurity design, quality-system considerations, premarket documentation, and section 524B requirements for cyber devices. U.S. Food and Drug Administration

56. Artificial Intelligence Security

AI and machine-learning systems may require additional safeguards.

Security considerations may include:

• Model access controls;

• Training-data security;

• Dataset provenance;

• Model integrity;

• Prompt-injection risk;

• Data leakage;

• Model extraction;

• Model inversion;

• Poisoning attacks;

• Adversarial inputs;

• Unauthorized fine-tuning;

• Sensitive-output controls;

• Model-version management;

• Logging;

• Human oversight;

• Monitoring;

• Dependency security; and

• Secure deployment.

57. Generative AI

Sensitive or regulated information should not be submitted to unapproved generative-AI services.

Use of generative AI may be subject to:

• Data-classification requirements;

• Privacy requirements;

• Customer restrictions;

• Contractual requirements;

• Intellectual-property considerations;

• Human review;

• Output validation;

• Security assessment; and

• Approved-use policies.

58. AI Model Integrity

Controls may be implemented to protect AI models against:

• Unauthorized modification;

• Corruption;

• Theft;

• Tampering;

• Malicious replacement;

• Poisoned training data;

• Compromised dependencies; and

• Unauthorized access.

59. Clinical AI Security

Where AI outputs may contribute to clinical workflows, security controls should support:

• Data integrity;

• Model integrity;

• Version traceability;

• Input provenance;

• Output traceability;

• Auditability;

• Role-based access;

• Change control;

• Appropriate human oversight; and

• Prevention of unauthorized manipulation.

60. Internet of Things and Connected Devices

Connected devices may introduce additional risks.

Security controls may include:

• Device authentication;

• Secure communications;

• Network segmentation;

• Firmware management;

• Patch management;

• Inventory;

• Configuration control;

• Monitoring;

• Certificate management; and

• Device lifecycle management.

61. Clinical-System Integration

Integrations with healthcare systems may require enhanced security.

Examples include:

• Electronic health records;

• Cardiovascular information systems;

• PACS;

• DICOM systems;

• DICOMweb;

• HL7;

• FHIR;

• Laboratory systems;

• Medical devices;

• Imaging systems;

• Telehealth systems; and

• Other clinical interfaces.

Security may include:

• Authentication;

• Authorization;

• Encryption;

• Interface validation;

• Data integrity;

• Message validation;

• Logging;

• Availability controls;

• Error handling; and

• Interface monitoring.

62. Data Integrity

xBxBio seeks to protect information against unauthorized or unintended alteration.

Controls may include:

• Access restrictions;

• Digital signatures where appropriate;

• Hashing;

• Audit trails;

• Versioning;

• Checksums;

• Change controls;

• Validation;

• Database controls;

• Backup;

• Reconciliation; and

• Provenance records.

63. ALCOA+ Principles

For regulated or quality-relevant records, xBxBio may apply data-integrity principles consistent with ALCOA+ concepts:

• Attributable;

• Legible;

• Contemporaneous;

• Original;

• Accurate;

• Complete;

• Consistent;

• Enduring; and

• Available.

64. 21 CFR Part 11

Where electronic records or electronic signatures are subject to 21 CFR Part 11, xBxBio may implement applicable controls relating to:

• System validation;

• Record protection;

• Access controls;

• Audit trails;

• Authority checks;

• Operational checks;

• Device checks;

• Training;

• Documentation;

• Electronic signatures; and

• Record retention.

Reference to Part 11 does not mean every xBxBio system is a Part 11 system.

65. GxP and GAMP

Where xBxBio technology is used in regulated GxP environments, security and lifecycle controls may be integrated with:

• Computerized-system validation;

• Risk-based validation;

• Change control;

• Configuration management;

• Access management;

• Audit trails;

• Data integrity;

• Supplier management;

• Backup;

• Recovery;

• Incident management; and

• GAMP 5 principles.

66. GDPR — European Union and European Economic Area

Where the EU GDPR applies, xBxBio considers requirements relating to:

• Confidentiality;

• Integrity;

• Availability;

• Resilience;

• Appropriate technical and organizational measures;

• Risk assessment;

• Privacy by design;

• Privacy by default;

• Data minimization;

• Access control;

• Encryption;

• Pseudonymization;

• Incident response;

• Personal-data breach notification;

• Processor security;

• International transfers; and

• Accountability.

67. United Kingdom

Where applicable, xBxBio considers requirements under:

• UK GDPR;

• Data Protection Act 2018;

• Data (Use and Access) Act;

• PECR where applicable; and

• Relevant ICO guidance.

The ICO states that organizations must use appropriate technical and organizational measures to protect personal information and that security is a core data-protection principle. ICO

68. Switzerland

Where applicable, xBxBio considers obligations under Switzerland’s Federal Act on Data Protection and related cybersecurity requirements.

69. Canada

Where applicable, xBxBio considers federal and provincial requirements including:

• PIPEDA where applicable;

• Provincial private-sector privacy laws;

• Health-information privacy laws;

• Quebec privacy requirements;

• Alberta requirements;

• British Columbia requirements; and

• Other applicable Canadian privacy and security requirements.

70. United States

Depending on xBxBio’s activities and jurisdiction, security requirements may arise under:

• HIPAA;

• HITECH;

• Federal Trade Commission Act;

• FTC Health Breach Notification Rule;

• State privacy laws;

• State breach-notification laws;

• State health-data laws;

• Consumer-protection laws;

• Medical-device requirements;

• Contract law;

• Cybersecurity requirements; and

• Sector-specific regulations.

71. U.S. State Privacy and Security Requirements

Where applicable, xBxBio will evaluate requirements in states that maintain privacy, cybersecurity, consumer-health-data, biometric, genetic, or breach-notification laws.

Applicable obligations may vary based on:

• Residency;

• Data type;

• Business thresholds;

• Product;

• Processing purpose;

• Exemptions;

• Legal role; and

• Effective dates.

72. California

Where applicable, xBxBio considers requirements arising from:

• California Consumer Privacy Act;

• California Privacy Rights Act;

• California breach-notification law;

• California medical-information requirements; and

• Other applicable California laws.

73. Washington State

Where applicable, xBxBio considers the Washington My Health My Data Act and other applicable privacy and security requirements.

74. Other U.S. Jurisdictions

xBxBio evaluates security obligations in other states and territories based on applicable law and deployment.

This may include cybersecurity or privacy requirements involving:

• Consumer data;

• Health data;

• Biometric data;

• Genetic data;

• Children’s data;

• Financial information;

• Breach notification; and

• Data-security practices.

75. Brazil

Where applicable, xBxBio considers requirements of Brazil’s Lei Geral de Proteção de Dados — LGPD — and applicable guidance of the Brazilian data-protection authority.

76. Mexico

Where applicable, xBxBio considers Mexican privacy and security requirements governing personal data held by private parties.

77. Argentina

Where applicable, xBxBio considers Argentina’s personal-data protection requirements and applicable security obligations.

78. Other Latin American Jurisdictions

Where applicable, xBxBio evaluates data-protection and security requirements in jurisdictions including:

• Colombia;

• Chile;

• Peru;

• Uruguay;

• Ecuador;

• Costa Rica;

• Panama;

• Dominican Republic; and

• Other Latin American jurisdictions.

79. Australia

Where applicable, xBxBio considers requirements under:

• Privacy Act 1988;

• Australian Privacy Principles;

• Notifiable Data Breaches scheme;

• Applicable health-record laws;

• State and territory requirements; and

• Cybersecurity guidance.

80. New Zealand

Where applicable, xBxBio considers requirements under the New Zealand Privacy Act and applicable health-information privacy requirements.

81. Singapore

Where applicable, xBxBio considers requirements under Singapore’s Personal Data Protection Act and associated security obligations.

82. Japan

Where applicable, xBxBio considers requirements under Japan’s Act on the Protection of Personal Information and relevant security guidance.

83. South Korea

Where applicable, xBxBio considers requirements under South Korea’s Personal Information Protection Act and other applicable cybersecurity requirements.

84. India

Where applicable, xBxBio evaluates requirements under India’s Digital Personal Data Protection framework and other applicable information-security and cybersecurity requirements.

85. China

Where applicable, xBxBio evaluates requirements under Chinese laws including:

• Personal Information Protection Law;

• Cybersecurity Law;

• Data Security Law;

• Cross-border data rules;

• Data-localization requirements; and

• Sector-specific requirements.

Deployment involving China requires jurisdiction-specific legal and security assessment before implementation.

86. Hong Kong

Where applicable, xBxBio considers the Personal Data (Privacy) Ordinance and relevant security guidance.

87. Taiwan

Where applicable, xBxBio evaluates Taiwan personal-data-protection and cybersecurity requirements.

88. Middle East

Where applicable, xBxBio evaluates privacy, cybersecurity, healthcare-data, and localization requirements within Middle Eastern jurisdictions.

89. United Arab Emirates

Where applicable, requirements may include:

• UAE federal data-protection law;

• Health-data requirements;

• Cybersecurity standards;

• DIFC requirements;

• ADGM requirements; and

• Sector-specific obligations.

90. Saudi Arabia

Where applicable, xBxBio evaluates requirements under Saudi Arabia’s Personal Data Protection Law and applicable cybersecurity frameworks and healthcare-data requirements.

91. Qatar

Where applicable, xBxBio evaluates Qatar privacy and cybersecurity requirements.

92. Bahrain

Where applicable, xBxBio evaluates Bahrain personal-data-protection requirements.

93. Israel

Where applicable, xBxBio evaluates Israeli privacy, data-security, and cybersecurity requirements.

94. Türkiye

Where applicable, xBxBio considers requirements under Türkiye’s Personal Data Protection Law and associated cybersecurity obligations.

95. South Africa

Where applicable, xBxBio considers requirements under the Protection of Personal Information Act and related security obligations.

96. Other African Jurisdictions

Where applicable, xBxBio evaluates data-protection and cybersecurity laws in jurisdictions including:

• Kenya;

• Nigeria;

• Ghana;

• Egypt;

• Morocco;

• Rwanda;

• Uganda;

• Mauritius; and

• Other countries in which xBxBio activities may occur.

97. Cross-Border Data Transfers

International data transfers may be subject to:

• Contractual safeguards;

• Data-processing agreements;

• Standard contractual clauses;

• Transfer-risk assessments;

• Adequacy decisions;

• Binding corporate rules where applicable;

• Consent where legally permitted;

• Localization requirements; and

• Other approved transfer mechanisms.

98. Data Localization

Some jurisdictions restrict where certain data may be stored or processed.

Before deployments involving localization-sensitive information, xBxBio may evaluate:

• Country requirements;

• Data type;

• Healthcare requirements;

• Government-access rules;

• Cloud-region availability;

• Cross-border restrictions; and

• Customer obligations.

99. Data Retention

Information should be retained only as long as reasonably necessary for:

• Authorized business purposes;

• Legal obligations;

• Regulatory requirements;

• Contractual requirements;

• Security;

• Audit;

• Clinical needs;

• Research requirements;

• Intellectual-property protection; and

• Litigation or legal holds.

100. Secure Disposal

Information and equipment should be disposed of securely.

Methods may include:

• Secure deletion;

• Cryptographic erasure;

• Media sanitization;

• Physical destruction;

• Vendor-certified destruction; and

• Documented disposal.

101. Security by Design

Security should be considered from the earliest stages of:

• Product design;

• System architecture;

• Software development;

• Integration design;

• AI development;

• Clinical-workflow design;

• Cloud deployment;

• Vendor selection; and

• Data processing.

102. Privacy by Design and Default

Where personal data is involved, xBxBio seeks to incorporate privacy and security protections by design and by default, including:

• Minimization;

• Purpose limitation;

• Restricted access;

• Secure defaults;

• Appropriate retention;

• Encryption;

• Pseudonymization where appropriate; and

• Risk assessment.

103. Security Risk Assessment

Security-risk assessments may identify:

• Threats;

• Vulnerabilities;

• Existing controls;

• Likelihood;

• Impact;

• Residual risk;

• Treatment actions;

• Owners; and

• Acceptance decisions.

104. Threat Modeling

Threat modeling may be used to evaluate:

• Assets;

• Trust boundaries;

• Attack surfaces;

• Adversaries;

• Abuse cases;

• Data flows;

• Entry points;

• Threat scenarios; and

• Mitigations.

105. Change Management

Changes to relevant systems may be subject to:

• Documentation;

• Risk assessment;

• Testing;

• Review;

• Approval;

• Traceability;

• Validation where applicable;

• Rollback planning; and

• Post-implementation review.

106. Configuration Management

Secure configurations may be documented and maintained for:

• Servers;

• Endpoints;

• Databases;

• Cloud resources;

• Network devices;

• Containers;

• Applications;

• Development tools; and

• Security systems.

107. Asset Management

xBxBio may maintain inventories of relevant:

• Hardware;

• Software;

• Cloud resources;

• Applications;

• Databases;

• Devices;

• Repositories;

• APIs;

• Dependencies;

• Certificates;

• Domains; and

• Other technology assets.

108. Certificate Management

Digital certificates may be managed throughout their lifecycle, including:

• Issuance;

• Installation;

• Monitoring;

• Renewal;

• Revocation; and

• Replacement.

109. Secrets Management

Secrets such as:

• API keys;

• Passwords;

• Tokens;

• Private keys;

• Database credentials; and

• Service credentials

should be stored and managed using appropriate security mechanisms rather than embedded in publicly accessible code or documentation.

110. Security Metrics

xBxBio may use metrics to evaluate security performance.

Metrics may include:

• Vulnerability aging;

• Patch status;

• Security incidents;

• Authentication events;

• Access-review completion;

• Training completion;

• Backup success;

• Recovery-test results;

• Security-test results;

• Third-party risk status; and

• Remediation status.

111. Security Exceptions

Exceptions to security requirements should be:

• Justified;

• Risk assessed;

• Approved;

• Documented;

• Time limited where appropriate; and

• Supported by compensating controls where necessary.

112. Insider Risk

xBxBio recognizes risks arising from intentional or accidental insider activity.

Controls may include:

• Least privilege;

• Separation of duties;

• Logging;

• Access review;

• Confidentiality obligations;

• Monitoring;

• Training;

• Termination procedures; and

• Investigation processes.

113. Personnel Security

Appropriate personnel safeguards may include:

• Confidentiality agreements;

• Background screening where lawful and appropriate;

• Security training;

• Role-based access;

• Onboarding controls;

• Transfer controls;

• Offboarding controls; and

• Prompt access revocation.

114. Offboarding

When access is no longer required, xBxBio should take appropriate measures such as:

• Disable accounts;

• Revoke credentials;

• Recover devices;

• Remove permissions;

• Rotate shared secrets when necessary;

• Preserve required records; and

• Confirm return of confidential information.

115. Security Research and Vulnerability Disclosure

xBxBio supports responsible identification and remediation of security vulnerabilities.

Where appropriate, xBxBio may establish a coordinated vulnerability-disclosure process for reporting suspected vulnerabilities.

Security researchers should not:

• Access data beyond what is necessary to demonstrate a vulnerability;

• Destroy data;

• Disrupt services;

• Conduct extortion;

• Use social engineering against personnel; or

• Publicly disclose vulnerabilities before reasonable remediation coordination.

116. Law Enforcement and Government Requests

Requests for information from governmental or law-enforcement authorities will be evaluated for:

• Legal authority;

• Scope;

• Jurisdiction;

• Validity;

• Data involved;

• Applicable privacy requirements;

• Contractual obligations; and

• Appropriate response.

117. Cyber Insurance

xBxBio may evaluate cybersecurity-insurance coverage based on organizational risk, commercial requirements, and business needs.

Insurance does not replace security controls.

118. Continuous Monitoring

Security controls and risks may be monitored on an ongoing basis based on:

• System criticality;

• Threat intelligence;

• Vulnerability information;

• Security events;

• Technology changes;

• Regulatory changes;

• Customer requirements; and

• Business changes.

119. Threat Intelligence

xBxBio may use information concerning:

• Known vulnerabilities;

• Threat actors;

• Exploited vulnerabilities;

• Malware;

• Ransomware;

• Attack techniques;

• Vendor advisories;

• Government alerts; and

• Industry intelligence

to inform security decisions.

120. Security Improvement

Security is an ongoing process.

xBxBio may continuously improve its security program based on:

• Risk assessments;

• Incidents;

• Testing;

• Audits;

• Regulatory developments;

• Customer feedback;

• Threat intelligence;

• Technology changes;

• Industry standards; and

• Lessons learned.

121. Compliance Monitoring

xBxBio may assess security controls through:

• Internal review;

• Automated monitoring;

• Security testing;

• Documentation review;

• Management review;

• External assessment where appropriate;

• Customer assessment where contractually required; and

• Independent audit where warranted.

122. Certifications and Attestations

Unless expressly stated in an official xBxBio communication, xBxBio does not represent that every product, service, environment, or system is certified under every referenced standard.

References to standards such as ISO 27001, SOC 2, HITRUST, NIST, or other frameworks describe security objectives or frameworks that may inform xBxBio practices.

Certification, accreditation, attestation, or independent verification will be stated separately where actually obtained.

123. Customer Security Responsibilities

Security is a shared responsibility.

Customers may be responsible for:

• User provisioning;

• Identity management;

• Password protection;

• Multi-factor authentication;

• Device security;

• Local network security;

• Role assignment;

• Access review;

• Secure integrations;

• Customer-controlled configurations;

• Data accuracy;

• Endpoint security; and

• Compliance with customer-specific obligations.

124. Customer Configuration

Security may depend on how a customer configures and uses an xBxBio product.

Customers should follow:

• Security documentation;

• Configuration guidance;

• Access-control recommendations;

• Integration requirements;

• Update requirements;

• Backup guidance; and

• Applicable regulatory obligations.

125. Research and Pre-Commercial Systems

Some xBxBio technologies may be:

• Research-stage;

• Development-stage;

• Prototype;

• Demonstration;

• Validation-stage;

• Pre-commercial; or

• Not yet approved or cleared for clinical use.

Security controls may evolve as products progress through development, validation, regulatory assessment, and commercialization.

126. No Absolute Security Guarantee

No information system, network, software platform, cloud service, encryption technology, or cybersecurity program can eliminate all risk.

xBxBio cannot guarantee that unauthorized access, cyberattack, service disruption, software defect, zero-day vulnerability, third-party compromise, or other security event will never occur.

xBxBio’s objective is to identify, reduce, manage, detect, respond to, and recover from cybersecurity risk using measures appropriate to the circumstances.

127. Regulatory Applicability

Security requirements are determined based on factors including:

• Intended use;

• Product functionality;

• Product claims;

• Regulatory classification;

• Data processed;

• Legal role;

• Customer relationship;

• Deployment model;

• Geographic market;

• Clinical role;

• System risk;

• Development stage; and

• Applicable law.

References to laws, standards, frameworks, agencies, or guidance do not mean that every requirement applies to every xBxBio system or activity.

128. International Applicability

xBxBio intends this policy to provide a global baseline.

Because cybersecurity, privacy, healthcare, artificial-intelligence, medical-device, and data-localization requirements differ among jurisdictions, xBxBio will evaluate applicable local requirements before regulated deployment.

Where local law imposes a higher requirement than this policy, the applicable legal requirement governs.

129. Conflicts of Law

Where requirements between jurisdictions conflict, xBxBio may seek legal, regulatory, privacy, cybersecurity, or other professional guidance to determine an appropriate and lawful approach.

130. Policy Review

This policy may be reviewed and updated in response to:

• Changes in law;

• New regulations;

• New regulatory guidance;

• Cybersecurity threats;

• Technology changes;

• Business changes;

• Product development;

• New markets;

• Security incidents;

• Audit findings;

• Customer requirements; and

• Changes in recognized security standards.

131. Reporting Security Concerns

Suspected security vulnerabilities, cybersecurity incidents, or security concerns involving xBxBio should be reported promptly through an authorized xBxBio contact channel.

For security-related communications, identify the subject as:

SECURITY / CYBERSECURITY INQUIRY

Sensitive vulnerability details should not be posted publicly.

132. Relationship to Other xBxBio Policies

This IT & Security Policy should be read together with applicable xBxBio policies and statements, including:

• Privacy Policy;

• Compliance & Regulatory Statement;

• Quality Statement;

• Terms or contractual agreements where applicable;

• Data-processing agreements;

• Business-associate agreements where applicable;

• Security addenda;

• Product-specific documentation; and

• Other applicable governance materials.

133. Important IT & Security Disclaimer

This policy describes xBxBio’s general approach to information technology, cybersecurity, information security, resilience, and related safeguards.

It is not a representation that every control described on this page has been deployed identically across every xBxBio environment, product, prototype, research system, customer deployment, development environment, or third-party service.

It does not constitute:

• Legal advice;

• Cybersecurity certification;

• Regulatory authorization;

• Medical-device clearance;

• Government approval;

• Independent security attestation;

• SOC 2 attestation;

• ISO certification;

• HITRUST certification;

• HIPAA certification; or

• A guarantee that cybersecurity incidents cannot occur.

Specific security requirements and controls may vary according to:

• Product;

• Intended use;

• Risk;

• Customer contract;

• Data type;

• System architecture;

• Deployment environment;

• Legal role;

• Regulatory classification;

• Development stage;

• Geographic jurisdiction; and

• Applicable law.

xBxBio will evaluate applicable security and regulatory requirements before commercial deployment or claims of certification, authorization, regulatory conformity, or independent attestation.

END OF IT & SECURITY POLICY