Risk Management

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

1. Purpose & scope

This policy establishes the scope, objectives, and procedures of Foundry’s information security risk-management process. The process is intended to support and protect the organization and its ability to fulfill its mission, supporting independent physician practices, while safeguarding PHI handled on their behalf as a HIPAA business associate.

The policy covers risks to Foundry’s information assets, including the Conductor platform (which mediates all access to Foundry’s FHIR service), the foundry-master-agent control plane (Atlas plus the tiered Forge Agents), workforce endpoints, identity and SaaS surface, the marketing and customer-site infrastructure, and the supply chain that supports all of these.

2. Policy statements

Foundry policy requires that:

(a) A thorough risk assessment is conducted to evaluate the potential threats and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI), and other confidential or proprietary electronic information, that Foundry stores, transmits, or processes on behalf of member practices.

(b) Risk assessments are performed with any major change to Foundry’s business or technical operations, with any change to supporting infrastructure that materially affects the ePHI risk envelope, and on no less than an annual cadence.

(c) Strategies are developed to mitigate or accept the risks identified during the risk-assessment process. Mitigation strategies are tracked to closure in the risk register.

(d) Documentation of all risk assessment, risk management, and risk-mitigation efforts is maintained for a minimum of seven years.

(e) AI-specific risks, bias, fairness, model drift, prompt injection, and risks unique to the multi-tier agent architecture, are incorporated into the same risk-management process and tracked in the same registry, with cross-references to the AI Governance policy.

(f) The PHI boundary is treated as a control that cannot be relaxed: any proposed change that could allow PHI to land outside Foundry’s FHIR service is identified as a high-risk change and undergoes risk assessment before implementation, with the Security Officer’s explicit approval. Such changes are not approved through routine change management.

3. Risk management process

Risk analysis and risk management are recognized components of Foundry’s compliance and information security program, in accordance with the Risk Analysis and Risk Management implementation specifications within the HIPAA Security Management Standard and the evaluation standards set out in 45 CFR § 164.308(a)(1)(ii)(A), § 164.308(a)(1)(ii)(B), § 164.308(a)(1)(i), and § 164.308(a)(8). The process is also informed by NIST SP 800-30 and NIST SP 800-39.

Risk assessments are conducted throughout the product lifecycle:

• Before the integration of new system technologies and before changes are made to Foundry’s physical and technical safeguards. Routine updates to existing systems, deployments of new instances built from previously assessed configurations, onboarding of additional member practices, and routine application releases do not, by themselves, trigger a fresh full risk assessment;
• When changes are made to Foundry’s facilities or to equipment hosting Foundry workloads that introduce new, untested configurations;
• In response to changes in the threat environment that materially affect the security of ePHI, for example, a notable new attack pattern against the clinical data plane, a new class of LLM threat, or an incident at a subprocessor.

Foundry performs periodic technical and non-technical assessments of the Security Rule requirements, as well as in response to environmental or operational changes affecting the security of ePHI.

Foundry implements security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to:

1. Ensure the confidentiality, integrity, and availability of all ePHI Foundry receives, maintains, processes, or transmits on behalf of member practices;
2. Protect against any reasonably anticipated threats or hazards to the security or integrity of practice ePHI;
3. Protect against any reasonably anticipated uses or disclosures of practice ePHI that are not permitted by the BAA or required by law; and
4. Ensure compliance by all workforce members.

In addition to the policy statements in §2, Foundry’s risk-management process requires that:

1. Any residual risk, risk remaining after risk controls have been applied, is signed off by senior management and the Security Officer.
2. All workforce members are expected to fully cooperate with persons performing risk-management work, including contractors and audit personnel. Workforce members who violate this expectation are subject to discipline as outlined in HR & Personnel Security.
3. Implementation, execution, and maintenance of the risk-analysis and risk-management process is the responsibility of the Security Officer (or other designated workforce member) and the identified Risk Management Team.
4. All risk-management efforts, including decisions on controls implemented and controls explicitly not implemented, are documented and the documentation is maintained for at least seven years.
5. The risk-management procedure is tracked in Linear in the risk register as follows:
   1. The Security Officer or Privacy Officer initiates a risk-management activity by creating an Issue in the Risk Register project.
   2. The Security Officer or Privacy Officer is assigned to carry out the risk-management procedure.
   3. All findings are documented and linked to the Issue.
   4. Once the assessment steps and corresponding documentation are complete, the Security Officer approves or rejects the Issue. Rejected Issues return for further review and documentation.
   5. Approved Issues are marked Done with any pertinent notes recorded.
6. The risk-management procedure is monitored on a quarterly basis using Linear reporting to assess compliance with this policy.

Third-party risk management, procurement, and systems acquisition are covered in Vendor & Third-Party Risk.

4. Risk management schedule

The two principal components of the risk-management process, assessment and mitigation, are executed on the following schedule to ensure the continued adequacy and continuous improvement of Foundry’s security program:

• Scheduled basis. An organization-wide risk assessment of Foundry’s information-system infrastructure is conducted annually. The assessment is completed in time for mitigation priorities to be reflected in the corporate budgeting cycle.
• Throughout the development lifecycle. From the time a need for a new, untested information system or application is identified through to its retirement, ongoing assessments of potential threats and vulnerabilities are undertaken as part of normal system maintenance and design.
• As needed. The Security Officer (or other designated workforce member) or the Risk Management Team may call for a full or partial risk assessment in response to changes in business strategy, technology, information sensitivity, threats, legal liabilities, or other significant factors affecting Foundry’s platform.

5. Risk assessment & analysis

The intent of a risk assessment is to identify potential threats and vulnerabilities and to estimate the likelihood and impact of their occurrence. The output helps identify appropriate controls for reducing or eliminating risk.

5.1 Step 1: System characterization

Define the scope. Identify where ePHI is received, maintained, processed, or transmitted. Identify the boundaries of the Foundry platform: the FHIR service environment, the Conductor services that mediate access, the agent control plane, the workforce identity surface, and the supporting CI/CD pipeline.

Output: a characterization of the system in scope, a clear picture of its environment, and a delineation of platform boundaries.

5.2 Step 2: Threat identification

Identify and document potential threat-sources, the potential for a threat-source to successfully exercise a specific vulnerability. Threat-sources are identified from historical incidents, industry intelligence (including Health-ISAC where Foundry is a member), government advisories, and Foundry’s own incident history.

Output: a threat list of threat-sources that could exploit platform vulnerabilities.

5.3 Step 3: Vulnerability identification

Develop a list of technical and non-technical platform vulnerabilities that could be exploited or triggered by potential threat-sources. Vulnerabilities range from incomplete or conflicting policies through insufficient safeguards on the facilities that house computer equipment to software, hardware, identity, or supply-chain weaknesses.

Output: a list of platform vulnerabilities that could be exercised by potential threat-sources.

5.4 Step 4: Control analysis

Document and assess the effectiveness of the technical and non-technical controls that have been or will be implemented by Foundry to minimize or eliminate the likelihood of a threat-source exploiting a platform vulnerability.

Output: a list of current or planned controls (policies, procedures, training, technical mechanisms, insurance, etc.) used to mitigate the likelihood of a vulnerability being exercised and to reduce the impact of such an adverse event.

5.5 Step 5: Likelihood determination

Determine the likelihood that a vulnerability could be exploited by a threat-source given existing or planned controls. Likelihood is rated low (0.1), medium (0.5), or high (1.0), per NIST SP 800-30 definitions.

5.6 Step 6: Impact analysis

Determine the adverse impact that would result from a threat successfully exploiting a vulnerability. Factors include importance to Foundry’s mission, sensitivity and criticality of the data and systems, and the loss of confidentiality, integrity, and availability. Impact is rated low (10), medium (50), or high (100). Impacts involving PHI are weighted toward the upper end of the scale by default.

5.7 Step 7: Risk determination

Multiply likelihood and impact to produce a risk level: low (1–10), medium (>10–50), or high (>50–100). The risk rating presents the actions senior management must take at each level.

5.8 Step 8: Control recommendations

Identify controls that could reduce or eliminate the identified risks at an acceptable level. Factors considered include effectiveness of the recommended options, regulatory requirements, organizational policy, operational impact, and safety and reliability. Control recommendations feed the mitigation process.

5.9 Step 9: Results documentation

Risk-assessment results are documented in an official report and provided to senior management to inform policy, procedure, budget, and platform operational and management decisions. The report describes threats and vulnerabilities, measures risk, and recommends controls.

6. Risk mitigation & monitoring

Risk mitigation involves prioritizing, evaluating, and implementing the risk-reducing controls recommended by the risk assessment to ensure the confidentiality, integrity, and availability of practice ePHI. Determination of appropriate controls depends on Foundry’s risk tolerance, which is conservative for any risk involving PHI.

6.1 Step 1: Prioritize actions

Sort threat/vulnerability pairs by risk level in descending order. Pairs at the top of the list receive immediate attention and priority in resource allocation.

6.2 Step 2: Evaluate recommended control options

Review the recommended controls and alternatives for reasonableness and appropriateness, assessing feasibility (compatibility, user acceptance) and effectiveness (degree of protection, level of risk mitigation). Select the most appropriate control option for each pair.

6.3 Step 3: Cost-benefit analysis

Determine the extent to which each control is cost-effective. Compare the benefit (risk reduction) of applying a control with its cost of implementation and operation. Cost considerations include direct expenditure, complexity introduced, ongoing operational burden, and the impact on the workforce experience.

6.4 Step 4: Select controls

Taking into account previous-step information, Foundry’s mission, and other important criteria, the Risk Management Team determines the best controls for reducing risks to the information systems and to the confidentiality, integrity, and availability of ePHI. Controls may consist of a mix of administrative, physical, and technical safeguards.

6.5 Step 5: Assign responsibility

Identify the workforce members with the skills necessary to implement each control and assign their responsibilities. Identify the equipment, training, and other resources needed for successful implementation.

6.6 Step 6: Safeguard implementation plan

Develop an implementation or action plan. The plan contains, for each risk pair:

• Risk level and ranked priority;
• Recommended feasible control(s);
• Resources required for implementation;
• The team member responsible for implementation;
• Start date for implementation;
• Target completion date;
• Ongoing maintenance requirements.

Status against the plan, along with key metrics and indicators, is reported to Foundry senior management at the regular cadence.

6.7 Step 7: Implement and monitor

As controls are implemented, monitor the affected systems to verify that the controls continue to meet expectations. Elimination of all risk is not practical; depending on the situation, implemented controls may lower a risk level but not completely eliminate the risk. Expectations are continually and consistently communicated to the Risk Management Team, senior management, and other key stakeholders. Additional monitoring is especially crucial during periods of major environmental, organizational, or facility change. If risk reduction expectations are not met, the relevant portion of the risk-management process is repeated.

Output: residual-risk documentation.

7. Risk register

The Security team maintains a registry of risks, captured and kept up to date in the Linear Risk Register project and/or in the security operations tool of record the security operations tool of record. The risk register includes all risks and threats identified during the annual risk assessment and all interim reviews. Each entry contains a unique identifier, a description, the affected assets, the threat and vulnerability pair, the likelihood and impact ratings, the resulting risk level, the chosen treatment (mitigate, transfer, accept, avoid), the owner, the target date, and the current status.

8. Cyber liability insurance

Foundry holds cyber liability insurance with coverage commensurate with the organization’s risk profile. Coverage is reviewed annually as part of the risk-management process and adjusted in line with the size of the workforce, the number of practices supported, and the volume of PHI handled.

9. Fraud risks

Foundry considers its fraud-related risk to be low given its transparent culture, small team, written separation of duties, controls spanning the organization, continuous monitoring and auditing, and external accounting relationship supporting financial controls.

Fraud risk is re-evaluated as part of the annual risk assessment. The assessment considers the classical fraud-triangle factors: pressures and incentives, opportunities, and rationalizations.

Financial-related fraud assessment is led by the operations/finance lead. IT-related fraud assessment is led by the Security Officer.

10. Anti-money laundering & antitrust

10.1 Anti-money laundering

It is the policy of Bioscope Foundry to prohibit and actively prevent money laundering and any activity that facilitates money laundering or the funding of terrorist or criminal activities.

• Foundry does not accept any customers or transactions involved with money laundering.
• Foundry encourages suspicious-activity reporting and implements applicable measures to detect such activity.
• Workforce members complete training that includes recognition and reporting of suspicious financial behavior.

10.2 Antitrust compliance

All workforce members must comply strictly and in good faith with the letter and spirit of all antitrust laws applicable in any jurisdiction in which Foundry transacts business. Antitrust laws protect and promote free and open competition, a posture Foundry believes is in the best interest of the company, its competitors, suppliers, member practices, and the patients those practices serve.

11. Review & revision

This policy is reviewed at least annually and after any material change to Foundry’s business or technical operations, regulatory environment, or risk posture. Material revisions are approved by the Security Officer in coordination with the Privacy Officer and the Policy Management process.

12. Related policies

• Security program overview
• Security architecture & operating model
• AI governance
• Vendor & third-party risk
• Vulnerability management
• Incident response
• Business continuity & disaster recovery