Asset Management

Policy · v2026.06 · Owner: IT Lead & Security Officer (joint) · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30

Foundry cannot protect what it cannot see. This policy requires an accurate, up-to-date inventory of every physical workforce device and every digital asset (cloud resource, repository, service, identity, integration). Each asset has a designated owner and a data-classification tag. The inventory feeds access reviews, vulnerability management, vendor risk, and incident response. Data-lifecycle and classification details live in Data Management.

1. Purpose & scope

This policy governs the inventory, ownership, classification, and lifecycle of every asset Bioscope Foundry uses to operate as a HIPAA business associate. Assets include:

Physical computing devices issued to workforce members (laptops, mobile phones, security keys, peripherals);
Cloud resources in AWS accounts (the clinical workflow database, the FHIR service, S3 buckets, queues, functions, VPCs);
Source-code repositories and CI/CD configurations;
SaaS applications and their administrative roles;
Human and service identities;
Third-party integrations and webhooks; and
Foundry-issued domain names, certificates, and other naming/cryptographic material.

The policy supports HIPAA Security Rule expectations around device and media controls (45 CFR § 164.310(d)).

HIPAA Security Rule, Privacy Rule, and Breach Notification Rule govern this policy. Mapping to other frameworks (CCPA, ISO/IEC 27001, SOC 2) is maintained in the framework crosswalk.

2. Policy statements

Foundry policy requires that:

IT and Security jointly maintain an inventory of all critical company assets, physical and digital, with sufficient detail to identify, locate, and assess the risk attached to each asset.
Every asset has a named owner and a risk / data-classification tag derived from the categories in Data Management.
Every physical asset issued to a workforce member is labeled with a Foundry property identifier and is tracked through the IT asset system.
Asset inventories do not duplicate other authoritative inventories unnecessarily; where two systems hold an inventory, the source of truth is named in this policy and reconciliations run automatically.
Inventory data is refreshed continuously by automation; the Security team treats stale inventory as a finding.
Assets that fall out of inventory (untagged hardware, untagged cloud resources, unowned repositories) are escalated to the Security Officer and remediated promptly.

3. Controls & procedures

3.1 Sources of truth

Foundry distinguishes between the source of truth for an asset class and the consolidated inventory views built on top of it. Sources of truth, by asset class:

Workforce devices: the MDM is authoritative for fleet membership and configuration state; the HRIS holds the assignment to a workforce member; the IT asset register reconciles both.
Cloud resources (AWS): Terraform state plus the live AWS APIs. AWS Config and resource inventory produce the canonical real-time view.
Repositories & CI/CD: GitHub organization membership and repository metadata.
SaaS applications: the Foundry application register, maintained by Security, reconciled monthly against the IdP’s SSO catalog.
Identities: the identity provider for humans, AWS IAM for service principals.
Domains and certificates: the domain registrar’s portal and the certificate-management system used by the platform.

3.2 Classification & ownership

Every asset record carries at minimum:

Owner: a named workforce member (or role) accountable for the asset.
Classification: derived from Data Management. Assets that can reach PHI are tagged PHI-bearing and are subject to stricter controls (encryption, audit logging, restricted access, accelerated patching).
Lifecycle stage: provisioned, in-service, retired.
Linkages: the workforce member, vendor, or workload the asset is tied to.

Ownership transfers (a workforce member changing role, a service being handed between teams) are recorded as transactions in the asset record, not silently overwritten.

4. Physical asset inventory

4.1 Scope

Foundry’s physical assets are predominantly workforce computing devices. The Carmel office contains no on-premises production servers and no PHI-bearing hardware. Physical assets include:

Workforce laptops (Apple Silicon MacBooks; Linux workstations by engineering exception).
Workforce mobile phones (where Foundry-issued).
Phishing-resistant MFA hardware (WebAuthn / FIDO2 security keys such as YubiKeys), as dedicated keys are rolled out to workforce members responsible for privileged or PHI-adjacent surfaces.
Peripherals: external displays, keyboards, mice, docks, printers held at the Carmel office.
Networking equipment at the Carmel office, where Foundry-owned.

4.2 IT asset register

The IT Lead maintains an inventory in the MDM and reconciles it against the HRIS-driven assignment register. Each record includes:

Manufacturer, model, serial number, and Foundry property tag;
The workforce member or location it is assigned to;
Provisioning date, last MDM check-in, and configuration state (FileVault on, EDR present, OS version);
Classification tag (PHI-bearing by default for workforce laptops that reach the platform);
Any transfers and the date of each transfer;
Lifecycle stage and, when retired, the disposition path (re-issue, return, destruction).

The IT Lead ensures every Foundry-issued device is tagged with a Foundry property identifier (label or asset sticker) and that the MDM record matches the physical device. Devices that fail to check into MDM for more than 14 days are flagged for follow-up.

4.3 Security keys

Phishing-resistant WebAuthn passkeys are enforced today on privileged surfaces, starting with the AWS root account per its setup runbook. Foundry is rolling out dedicated WebAuthn / FIDO2 hardware security keys as sealed break-glass authenticators, extending as additional consoles adopt WebAuthn or as Foundry’s workforce identity provider is wired per ADR-011. Any issued hardware keys are inventoried with serial numbers in the IT asset register; two keys per holder are registered to prevent lockout. Lost keys are reported to Security immediately, deregistered from every surface they were enrolled on, and replaced.

5. Digital asset inventory

5.1 Continuous discovery

The Security team uses automated tooling to query AWS continuously and produce a unified view of the digital fleet. The query surface includes (non-exhaustive):

AWS accounts, including the dedicated PHI environment that hosts the clinical workflow database and Foundry’s FHIR service;
PHI-environment resources: the clinical workflow database (Amazon RDS for PostgreSQL), the Foundry-operated HAPI FHIR service (Amazon ECS), encrypted S3 buckets, SQS queues, and serverless functions;
AWS resources more broadly: accounts, IAM principals and roles, S3 buckets, Lambda functions, EC2 instances (where present), DynamoDB tables, KMS keys;
GitHub organizations, repositories, deploy keys, GitHub App installations;
SaaS applications connected to federated SSO;
Vendor and partner integrations, including any third-party that has been issued an API key or OAuth grant.

5.2 Tagging

Every digital asset carries owner, project, and classification tags. Resources that may handle PHI are tagged data-class=phi and are deployed only inside the PHI environment; cross-account access is mediated by IAM and network perimeter controls (see Security Architecture). Untagged or mis-tagged resources are escalated to the resource owner and remediated.

5.3 Repositories

Source-code repositories under the bioscope-foundry GitHub organization are inventoried and tagged. Each repository identifies:

Owner team and CODEOWNERS;
Data class the repository’s runtime touches (e.g. PHI-bearing platform service versus marketing site, no PHI);
Branch protection state;
Required-status checks and dependency-scanning configuration;
Whether deployment targets the PHI environment, the platform account, or non-production.

5.4 Identities & integrations

Human and service identities are inventoried in the IdP and in IAM, and a consolidated view is reviewed quarterly per Access Control. Every third-party integration (OAuth grant, API key, webhook) has a designated owner, a documented purpose, and a contract or BAA where required by data class.

6. Paper records

Foundry does not use paper records for PHI or for any sensitive operational data. Where paper exists (executed contracts, occasional signed forms, audit binders), it is collected at the Carmel office in a locked drawer or safe and the executed digital copy is held in the e-signature system (DocuSeal, self-hosted) and a managed corporate document store. Production of paper PHI by a workforce member is a policy violation and follows the policy-violation process (see HR & Personnel Security).

7. Lifecycle, transfer, & disposal

7.1 Provisioning

Assets are provisioned through the workflows in Access Control (for digital identities) and the onboarding workflow in HR & Personnel Security (for physical devices). Provisioning creates the asset record and stamps the initial owner and classification.

7.2 Transfer

When a device or repository changes owner (workforce member role change, team handoff), the transfer is logged in the asset record. For physical devices, IT wipes and re-enrolls the device before reassignment.

7.3 Decommissioning & destruction

Workforce devices. On separation or refresh, the device is wiped through MDM, and the disk is cryptographically erased (FileVault key destruction). The MDM record is moved to “retired” and the property tag is retained for inventory history.
Cloud resources. Resources retired from production are removed via Terraform, with destruction events captured in audit logs.
Storage media. Foundry does not use removable media for PHI. Where storage media holding non-PHI confidential data is decommissioned, destruction follows the methods in Endpoint & MDM: cryptographic erasure where the media is encrypted, physical destruction otherwise.
Vendor termination. Where a subprocessor is retired, Foundry confirms in writing that the vendor has returned or destroyed Foundry data, per the contract or BAA in place. Where return or destruction is infeasible, the contract limits ongoing use of the data.

7.4 Loss or theft

Lost or stolen devices are reported to Security and IT immediately. The device is remotely locked and wiped through MDM; the workforce member’s credentials are rotated; an incident ticket is opened under Incident Response; the matter is escalated to Breach Notification only if the device could plausibly have held PHI (which, given the PHI boundary, is not the expected case).

8. Roles & responsibilities

IT Lead: owns the physical asset register, the MDM-driven device baseline, and the labeling program.
Security Officer: owns the digital-asset inventory, the classification taxonomy, the asset-review cadence, and exceptions.
Engineering Leads: own their team’s cloud resources and repositories; ensure owner and classification tags are present at creation.
Workforce members: take care of devices entrusted to them; report loss, theft, or unexpected behavior immediately.

9. Review & revision

This policy is reviewed at least annually and whenever new asset classes (e.g. new cloud platforms, new vendor SaaS) come into scope. Material revisions are approved by the Security Officer in coordination with the Policy Management process.

10. Related policies

HR & Personnel Security Endpoint & Mobile Device Management