System Audits, Monitoring and Assessments

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

1. Purpose & scope

This policy governs how Bioscope Foundry audits, monitors, and assesses the access and activity of systems and applications that process or store production data and protected health information (PHI). It applies to every Foundry-operated system in scope of the HIPAA Security Rule, including the conductor operating platform, Foundry’s FHIR service (R4) data store, the foundry-master-agent control plane, the Forge Agent fleet (including Tier-4 Moltworkers), Foundry-managed workstations, the workforce identity provider, source control (GitHub), and continuous-integration systems.

HIPAA Security Rule reference: this policy supports § 164.308(a)(1)(ii)(D) (information system activity review) and § 164.312(b) (audit controls). The HIPAA Security Rule requires that healthcare organizations and their business associates implement reasonable hardware, software, and procedural mechanisms that record and examine activity in systems that contain or use PHI. Foundry makes good-faith efforts to safeguard the privacy and security of information through an auditing approach consistent with available resources.

It is Foundry’s policy to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, Foundry audits access and activity to detect, report, and guard against:

• Network vulnerabilities and intrusions;
• Breaches of confidentiality and security of PHI;
• Performance problems and flaws in applications;
• Improper alteration or destruction of PHI;
• Out-of-date software and software known to have vulnerabilities;
• Policy violations by Forge Agents or workforce members.

2. Policy statements

Bioscope Foundry policy requires that:

(a) All critical computing systems and software, both virtual and physical, enable audit logging.

(b) Audit logs include sufficient information to identify who did what, when, where, and with what outcome.

(c) Audit logs covering PHI access and security-relevant events are retained for at least six years.

(d) An annual audit of Foundry security controls is conducted, either by a designated internal audit team or a qualified external audit firm.

(e) Access reviews are performed quarterly for general access and monthly for privileged access; unused or invalid access is removed as a result of each review.

(f) Audit logs never contain PHI bodies. Logs record machine-readable identifiers and event codes; PHI content does not appear in log lines, including in agent memory_events.

3. Types of system audits

Foundry’s auditing processes fall into three categories.

3.1 Configuration and activity monitoring

Logging, monitoring, scanning, and alerting on a system, account, or environment. This is performed continuously as part of Foundry operations. Examples include:

• User. User and account-level audit trails monitor commands directly initiated by the user, identification and authentication attempts, and data and services accessed.
• Application. Application-level audit trails monitor user activities, including data accessed and modified and specific actions performed.
• System. System-level audit trails monitor user activity, applications accessed, file integrity, and other system-defined actions.
• Network. Network-level scans or audit trails monitor what is operating, identify vulnerabilities, and run penetration probes.
• Traffic. Inbound and outbound traffic to production and restricted environments, for example, firewall logs and AWS VPC Flow Logs around the account that hosts Foundry’s FHIR service.
• Data. All successful and failed attempts at production data access and editing, including FHIR resource reads, writes, and exports through Foundry’s FHIR service. Audit events are routed to AWS CloudTrail (management and data events).
• Agent. Forge Agent decisions, policy evaluations, mount events, and Beacon Layer redaction outcomes, recorded as machine-readable audit codes in memory_events, never raw PHI content.

Each event records, at minimum: origin, destination, action performed, timestamp, and any other relevant detail available.

3.2 Access reviews

Review of all user and service accounts and permissions across Foundry operational environments, including AWS accounts, the identity provider, GitHub, and Linear.

• Foundry uses a Cloud Security Posture Management (CSPM) tool to automatically pull configurations from cloud environments, including:
  • AWS IAM policies and roles;
  • AWS VPC, security group, and network configuration;
  • Foundry’s FHIR service access bindings;
  • the identity provider users, groups, and application access;
  • Network access via VPC Flow Logs.
• Data is collected on demand, on a scheduled cadence, or in response to environment changes detected by the CSPM.
• The CSPM aggregates and analyzes user and application access.
• Access to systems not covered by the CSPM is reviewed manually via the SIEM (see §10).
• Foundry Security completes access reviews monthly for privileged access and quarterly for general access, including workforce accounts. Privileged access includes any role that can read, write, export, or change permissions on the PHI store; any AWS account administrator or organization owner; any GitHub Org Owner; and any the identity provider Super Admin.
• Unused or invalid access is removed as a result of each review.

3.3 Compliance and controls audit

An audit performed against the technical, administrative, and physical controls defined in Foundry policies and procedures, to measure adoption and effectiveness. Performed by a designated internal audit team or an external audit firm at defined intervals or triggered by a specific event.

Potential trigger events include:

• Scheduled compliance audit or assessment (e.g., annual HIPAA assessment, ISO surveillance audit when in scope);
• High-risk or problem-prone incidents or post-incident review;
• Practice or partner complaints, including BAA-related complaints;
• Identification of significant security vulnerabilities;
• Atypical patterns of activity;
• Failed authentication attempts above the alerting threshold;
• Remote access patterns or activity post termination;
• Random audits.

4. Security event analysis

Security logs, events, and audit trails are reviewed by the Security team with the assistance of automated systems and processes.

• Audit logs are automatically analyzed and correlated by the monitoring solutions and a centralized SIEM / log platform (see §10).
• Rules and policies identify suspicious activity, vulnerabilities, and misconfigurations.
• Alerts are triggered upon identification of an issue and routed to responsible staff via email, Slack, or the monitoring dashboard.
• Analysis is prioritized by alert severity. High-severity alerts are reviewed within 24 hours; SEV-1/SEV-2 alerts page the on-call rotation immediately per Incident Response.
• The incident-response process is followed as needed.
• Patches and updates are applied in a timely manner per Vulnerability Management.

5. Internal and manual auditing

Additional manual reviews, for example, user account and access auditing, may be necessary from time to time. These can be triggered by the events listed in §3.3.

Responsibility for audit activity is assigned to Foundry’s Security Officer. The Security Officer:

• Assigns the task of generating reports for audit activities to the workforce member responsible for the application, system, or network;
• Assigns the task of reviewing audit reports to the responsible workforce member, the Privacy Officer, or another individual deemed appropriate;
• Organizes and oversees a team structure for audit compliance activities (parameters, frequency, sample sizes, report formats, evaluation, follow-up);
• Reviews all connections to Foundry-controlled networks for appropriate restrictions to services, ports, and destinations. Exceptions are reviewed annually.

The manual review process defines and includes:

• A description of the activity and a rationale for performing the audit;
• Identification of personnel to perform the review (workforce members do not review audit logs that pertain to their own system activity);
• Frequency of the audit;
• Determination of significant events requiring further review and follow-up;
• Identification of appropriate reporting channels for audit results and required follow-up.

Manual audits and review activities are tracked in Linear. Audits may be carried out internally or by an external third-party vendor. Where possible, the external auditing vendor does not also provide Foundry’s IT services, to maintain separation of duties.

6. Audit requests

1. An audit for a specific cause may be requested by, among others, the Privacy Officer, Security Officer, a practice (covered entity), a partner, or an application owner.
2. A request must include time frame, frequency, and nature of the request.
3. A request must be reviewed and approved by the Privacy Officer and/or Security Officer before proceeding. Under no circumstances is detailed audit information shared with parties without proper permissions and access.
   • If the audit discloses that a workforce member has accessed PHI inappropriately, the minimum-necessary information is shared with the Security Officer to determine appropriate sanctions or corrective action.
   • Only de-identified information is shared with practices or partners regarding the results of an investigative audit, communicated by the Privacy Officer or designee. Prior to communicating with practices or partners, Foundry consults legal counsel and risk management as appropriate.

7. Review and reporting of audit findings

1. Audit information that is routinely gathered is reviewed in a timely manner, at least monthly, by the responsible workforce members. Additional reviews are performed as needed to confirm proper data is being captured and retained.
2. The reporting process supports meaningful communication of audit findings to relevant workforce members, practices, or partners.
   • Significant findings are reported immediately in writing. The Foundry incident-response form may be used to report a single event.
   • Routine findings are reported to the sponsoring leadership structure in a written report format.
3. Audit results are limited to internal use on a minimum-necessary, need-to-know basis. Audit results are not disclosed externally without administrative or legal counsel approval.
4. Security audits are a confidential, internal monitoring practice that may be included in Foundry’s performance-improvement activities. Audit results are disclosed only to administrative-level oversight structures, and information that may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports; individually identifiable information is not.
5. Where evaluation and reporting indicate that corrective action is required, the action is undertaken, documented, and shared with the responsible workforce members, practices, or partners.

8. Remediation of control deficiencies

Most controls are continuously monitored and reported via automation. Control deficiencies identified by an internal or external system audit are documented and reviewed with management. Security works with the corresponding control owner to prioritize and mitigate the deficiency, including corrective actions, additional controls, or adjustments to existing controls. Remediations are tracked to closure in Linear and reflected in the next control-audit cycle.

9. Audit trails and application security events logging standard

Foundry logging standards require application and system logs to contain sufficient information to determine who did what, when, where and record security and audit events and generate evidence for unauthorized activity.

All systems and software built at Foundry have the following security-event logging enabled in addition to standard application logging.

1. All security log events have the following attributes at minimum:
   • Timestamp of the event (synchronized to an approved time source);
   • Identifier of the principal performing the action (such as user ID or service account);
   • Location, including both origin (such as hostname or IP) and target (such as host, service, or resource);
   • Activity or action (such as log in, log out, create, read, update, delete of a resource). The action may be logged as and determined by the HTTP request method and the API endpoint;
   • Event description and additional details may be logged depending on the system or application.
2. The following types of security events are logged at minimum:
   • User and group administration activities (user or group added, updated, deleted; access granted or revoked);
   • All login attempts, successful and unsuccessful, including the source IP address;
   • All interactive logoffs;
   • Privileged actions (configuration changes, application shutdown or restart, software update);
   • Major application events (application failure, start and restart, shutdown);
   • Any and all actions performed on critical resources, including reads, writes, and exports against Foundry’s FHIR service FHIR store;
   • Forge Agent decisions and policy evaluations, recorded as audit codes in memory_events.
3. All application and system logs do not include (removed or masked):
   • Any sensitive information, PHI, or personally identifiable information (PII);
     • except for IP addresses;
     • usernames and logins may be logged as part of authentication logging;
     • for user-action auditing, opaque IDs are used in place of usernames or logins wherever possible.
   • Authentication and session tokens, user credentials.
4. Security events and audit logs are:
   • Always accessible to the monitoring system and team;
   • Protected from any changes (append-only where supported);
   • Monitored with alerting in place, including alerts when expected log events stop arriving for a defined period.
5. All Foundry IT infrastructure has system clocks synchronized.

Examples of recommended application events for logging and their auditing purpose:

Logging configuration is documented in:

• AWS CloudTrail and service logs (management and data events) on the accounts hosting conductor and the FHIR service;
• GitHub organization audit log (code, CI, branch protection, access events);
• the identity provider audit log (identity, admin, drive, login events);
• Linear (issue, comment, and admin events).

10. Audit trail integrity, retention, and SIEM

1. Audit logs are protected from unauthorized access or modification; their content is made available only when needed to evaluate a security incident or for routine audit activities outlined in this policy.
2. All audit logs are encrypted in transit and at rest.
3. Where possible, audit logs are stored on a system separate from the audited application to minimize the impact of auditing on the audited system and to apply separation of duties, protecting audit trails from system administrators of the audited system.
   • Logs from AWS CloudTrail, GitHub, and the identity provider are aggregated into the centralized log platform for analysis and long-term retention.
4. Reports summarizing audit activities are retained for at least six years, consistent with HIPAA recordkeeping requirements at 45 CFR § 164.530(j).
5. Raw event data is retained locally in the source environment for a defined window (typically 30 days), then encrypted and moved to long-term storage and retained for at least the HIPAA-required period for PHI-related logs. Other security-relevant logs are retained for a minimum of one year unless a longer retention is required by a specific use case (litigation hold, incident investigation).
6. Raw event data may be summarized into aggregated audit reports after the initial retention window, provided the aggregated reports retain the detail required to satisfy HIPAA audit-control obligations.

11. Access reviews

Access reviews are a specific subset of activity monitoring focused on identity:

• Quarterly: general workforce access reviewed across the identity provider, GitHub organizations, Linear, the AWS organization, and Foundry-owned SaaS. Inactive accounts are removed; group memberships are validated against current role.
• Monthly: privileged access reviewed (AWS account admin / organization owner; Foundry’s FHIR service admin/editor roles; GitHub Org Owner; the identity provider Super Admin; Atlas / control-plane admins; any role with break-glass capability). Each privileged grant is justified or revoked.
• On change: access reviewed at workforce role change, internal transfer, or contract change.
• On departure: all access removed within the timeframe set by the HR & personnel security policy. Departures of privileged users are audited end-to-end within 24 hours.

Each access review produces a record retained in line with §10.

12. Auditing practice and partner activity

1. Periodic monitoring of practice (covered entity) and partner activity is performed to ensure access and activity are appropriate for the privileges granted and necessary to the arrangement between Foundry and the third party. Foundry takes care that practices and partners do not gain access to data outside their own environments.
2. If a practice or partner has exceeded the scope of access privileges, Foundry management and security remediate the problem immediately and notify the practice.
3. If a practice or partner has violated the terms of the BAA or any HIPAA requirement, Foundry takes immediate action to remediate the situation. Continued violations may result in suspension or termination of the engagement.

13. Auditing and assessment tools

Foundry’s Security Officer is authorized to select and use assessment tools designed to detect vulnerabilities and intrusions. Use of such tools against Foundry systems and environments by others, including practices and partners, is prohibited without the explicit authorization of the Security Officer. Tools may include:

• Scanning tools and devices;
• Password-cracking utilities;
• Network sniffers;
• Security agents installed locally on servers and endpoints (and on workstations via MDM);
• Passive and active intrusion-detection systems;
• Penetration testing tools.

Vulnerability testing software is used to probe the network to identify what is running, whether publicly known vulnerabilities have been corrected, and whether the system can withstand attacks aimed at circumventing security controls. Penetration testing of Foundry production systems is authorized only in writing by the Security Officer; agreements with third-party testers include a written rules-of-engagement document.

14. Training, education, awareness

Foundry workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and patient data. Foundry’s commitment to auditing access and activity is communicated through onboarding, ongoing training opportunities, and the applicable policies in this Trust Center. Workforce members are made aware of their responsibilities with respect to privacy and security, and of the sanctions that follow if auditing detects a workforce member’s failure to comply with organizational policies.

Foundry’s member practices are provided with the necessary information to understand Foundry’s auditing capabilities. Practices remain responsible for logging, auditing, and retention of any application hosted outside Foundry environments, even if that application integrates with the Foundry platform.

15. Roles & responsibilities

• Security Officer: owns this policy; selects and authorizes assessment tools; reviews and approves audit requests; ensures access reviews are completed on cadence.
• Privacy Officer: co-approves audit requests touching PHI access; reviews audit results before any external disclosure.
• Security Engineering: operates the SIEM, CSPM, and detection rules; investigates alerts.
• Platform Engineering: ensures all systems and services emit the required audit events.
• Workforce members: refrain from reviewing audit logs that pertain to their own activity; cooperate with audits; report suspected misuse.
• External auditors: perform the annual control audit under written engagement, with separation of duties from Foundry IT service provision.

16. Review & revision

This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the Policy Management process.

17. Related policies

• Incident Response
• Breach Notification
• Business Continuity & Disaster Recovery
• Access Control
• Vulnerability Management
• HR & Personnel Security
• Vendor & Third-Party Risk
• HIPAA Notice & Business Associate Statement