Skip to content
Pre-publication draft. This Trust Center is prepared for peer review before public launch.
Policies, Standards & Procedures
Policy Management

Policy Management

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

Bioscope Foundry maintains a versioned set of security and privacy policies as a HIPAA business associate. The Security Officer and Privacy Officer are accountable for keeping policies current, approved, communicated, and accessible to every workforce member. Previous versions are retained so that the state of any policy at any historical date is recoverable.

1. Purpose & scope

This policy governs how Foundry creates, approves, communicates, retains, and retires the policies in its security and privacy program. It applies to every Foundry policy document published in this Trust Center and to any internal procedure that implements one of them. It binds every workforce member who proposes, reviews, approves, or operates against a Foundry policy.

Foundry’s policies exist to maintain compliance, protect PHI handled on member practices’ behalf, and to make safe behavior the easy behavior for the workforce. This policy is the policy about policies.

2. Policy statements

Foundry policy requires that:

(a) Foundry policies are developed and maintained to meet all applicable compliance requirements, including HIPAA, and to adhere to recognized security best practices. Mapping of Foundry’s policies to non-HIPAA frameworks is maintained in the framework crosswalk.

(b) All policies are reviewed at least annually and whenever a material change to Foundry’s business, technology, regulatory environment, or risk posture makes a policy stale.

(c) All policy changes are approved by the Foundry Security Officer. In addition:

  • Major changes, changes that materially expand, contract, or alter Foundry’s commitments to member practices or workforce, require approval by the Foundry CEO or designee.
  • Changes to policies governing product development (Secure SDLC, Vulnerability Management, Configuration & Change Management, AI Governance) require approval by the engineering lead.
  • Changes to policies governing privacy and the use of PHI require concurrence from the Privacy Officer.

(d) All policy documents are maintained under version control. Previous versions are retained for a minimum of seven years from the date a version is superseded or retired.

(e) Policy exceptions are handled case by case (see §6). Each exception is documented with the business justification, the residual risk, the compensating controls, an expiration no later than one year from approval, and named approvers.

(f) Policies are accessible to every workforce member. Material changes are communicated to all workforce members through pre-established internal channels.

3. Document structure

Each Foundry policy is a standalone document covering a specific domain of concern. Documents share a consistent structure so that workforce members and external reviewers can find the same information in the same place across the library:

  • Header: eyebrow, title, owner, effective date, last reviewed date, next review date, and version number.
  • Summary callout: a one-paragraph plain-English statement of what the policy commits Foundry to.
  • Purpose & scope.
  • Policy statements: lettered (a), (b), (c)… commitments.
  • Controls & procedures: numbered, with H3 sub-headings where the source policy is long.
  • Roles & responsibilities.
  • Review & revision.
  • Related policies.

4. Versioning & numbering

4.1 Version numbers

Each Foundry policy carries a version number in the format YYYY.MM, the year and month of the most recent material publication (for example, 2026.06). The version is incremented with each material change. A material change is one that adds, removes, or alters a policy statement, a control, a role, or a retention commitment.

A policy may also carry an optional revision suffix, rev.N, to denote minor, non-material changes such as formatting, typo fixes, or link updates that do not change the substance of the policy.

4.2 Section numbering

Where sequencing numbers appear in policy headings, they are stable references. A policy or policy statement may be cited internally as, for example, policy-management §2(c). To maintain cross-reference integrity:

  • Existing sequence numbers are not reordered or renumbered between versions.
  • Additions are appended: new policy statements are added at the end of an existing list rather than inserted between existing items.
  • Retired statements are marked deprecated in place rather than deleted, so that historical citations remain resolvable.

5. Policy lifecycle

5.1 Storage and source of truth

Policies are stored as source-controlled artifacts in the Foundry Trust Center repository a version-controlled repository. Updates flow through pull requests in the same manner as application source code. The version of a policy published on the Trust Center website is the version on the main branch of that repository.

5.2 Initiating a policy change

Any workforce member may propose a policy change at any time. The process is:

  1. The proposer opens an Issue in the Foundry Security project in Linear the policy-change tracker describing the proposed change and the motivation. The Issue may include a draft pull request against the Trust Center repository.
  2. The Security Officer (or the Privacy Officer, where the change is privacy-led) is assigned to review the request.
  3. If the change touches a domain owned by another role (e.g., engineering for SDLC, BCDR for operations), that role is added as a reviewer.
  4. The reviewer either approves the change or returns it with feedback for further iteration.
  5. If the change requires technical changes to production systems, those follow the Configuration & Change Management process.

5.3 Drafts, archives, and merges

Material changes are prepared on a draft branch, not on main. Multiple authors collaborating on a change may use additional branches and stacked pull requests before consolidating into the draft branch.

Before a material change is merged to main:

  • The current version of the affected policy document is archived under its existing version number (for example, archive/policy-management/2026.06.html).
  • The Security Officer’s approval is recorded on the pull request. The Privacy Officer’s concurrence is recorded for privacy-impacting changes.
  • Engineering reviewers are included for product-development policies. PR approvals serve as records of awareness and training for development staff.

Minor revisions (rev.N) may be merged without archiving, since the substance of the policy has not changed.

5.4 Communication and training

Policy changes are communicated to the workforce through:

  • An automated notification to the Foundry Slack policy-changes channel a dedicated policy channel when a pull request affecting a policy is merged.
  • An email from the Security Officer to all workforce members for material changes, including a plain-language summary appropriate to the audience.
  • An item on the next company-wide meeting agenda when the change affects day-to-day workforce behavior.
  • Updates to the security-awareness curriculum when the change introduces new workforce expectations.

Policy update communication and training for non-engineering staff is conducted separately by the Security team when the engineering pull-request channel is not appropriate for the audience.

5.5 Publication

The current set of approved Foundry policies is published at the Foundry Trust Center. Every workforce member has access to the current set without needing to request it.

6. Exceptions

Where business need or technical constraint requires temporary deviation from a Foundry policy, the deviation is handled as an exception rather than as a policy change. Exceptions are managed by the Security Officer.

Each exception record contains:

  • The policy and specific statement(s) being excepted;
  • The business purpose and the reason the policy as written cannot be met;
  • The scope: which systems, accounts, environments, or workforce members are covered;
  • The residual risk and any compensating controls;
  • An expiration date no later than one year from the date of approval;
  • Named approvers: the Security Officer plus an additional approver appropriate to the domain (by default, the Engineering Lead).

Open exceptions are reviewed at each scheduled program review. An exception that has expired without renewal is closed and the underlying gap is either remediated or re-opened for a fresh exception, not silently extended.

Exceptions are never granted against:

  • The PHI boundary: PHI may not move outside Foundry’s FHIR service by exception.
  • The encryption-at-rest and in-transit requirements for PHI systems.
  • The phishing-resistant MFA requirement for workforce access to PHI systems.
  • HIPAA Breach Notification timelines.

7. Retention & backup

Foundry policies and their associated documentation are retained for a minimum of seven years from the date of creation or from the date the version was last in effect, whichever is later. The retention chain is:

  • Version history is maintained in Git in the Trust Center repository.
  • Archived prior versions live in archive/ under their version number.
  • Backup copies of the repository are held in an access-controlled document store for redundancy.
  • The HIPAA-relevant subset (any policy that touches PHI handling, BAA obligations, or breach response) is preserved for at least six years from the latest effective date, in line with 45 CFR § 164.530(j) as it applies to a business associate.

8. Review & revision

The Security Officer initiates a structured review of every Foundry policy at least annually, or after a significant change to Foundry’s organizational environment. The review process is:

  1. The Security Officer opens an Issue or pull request in the Trust Center repository covering the policies due for review.
  2. The Security and Privacy Officers, plus additional reviewers appropriate to the domain, are notified.
  3. Reviewers comment on the pull request or leave findings in the Issue. Where changes are needed, those follow the lifecycle in §5.
  4. Once review is complete, the Security Officer approves and closes the Issue, or merges the pull request, recording any pertinent notes.
  5. Review status is tracked using Linear or GitHub reporting to assess compliance with this policy.

9. Related policies

Security Program OverviewRoles, Responsibilities & Training