ISO/IEC 27001:2022 alignment
ISO/IEC 27001:2022 alignment
Frameworks · ISO/IEC 27001:2022 · v2026.06 · Alignment matrix between ISO/IEC 27001:2022 Annex A and Foundry’s policy library. Last refreshed June 2026.
ISO/IEC 27001:2022 organizes Annex A into four themes totalling 93 controls: Organizational (37), People (8), Physical (14), and Technological (34). This page rolls up each theme and the standard’s main-body clauses (4–10) to the Foundry policy that satisfies them, with a status pill per group. This mapping is provided for transparency; it does not assert third-party certification.
Status
Implemented the control is in place and operating
Partially implemented part of the control is operating; the remainder is planned
Inherited satisfied by an underlying provider's control under BAA or agreement
Main-body clauses (4–10)
| Clause | Topic | Foundry posture | Policy | Status |
|---|---|---|---|---|
| 4 | Context of the organization | Foundry’s context as an Indiana MSO supporting independent U.S. physician practices is documented in the security program overview. Interested parties (member practices, patients-via-practices, regulators, subprocessors) are enumerated. | Program overview | Implemented |
| 5 | Leadership & policy | Security Officer and Privacy Officer are named; the top-level policy statement is the security program overview. Leadership commitment is documented in the same policy. | Roles & training | Implemented |
| 6 | Planning (risk, opportunities, objectives) | Risk assessment and treatment runs quarterly per the risk-management policy. Security objectives are tracked alongside engineering OKRs. | Risk management | Implemented |
| 7 | Support (resources, competence, awareness, communication, documented information) | Workforce training and policy communication are owned by HR & personnel security; documented information is maintained in this Trust Center plus internal runbooks. | Roles & training, Policy management | Implemented |
| 8 | Operation | Operational planning & control is the day-to-day security program: change management, vulnerability management, incident response, vendor risk, and BCDR all run as documented processes. | CCM, Vuln mgmt, IR | Implemented |
| 9 | Performance evaluation | System-audit and monitoring policy defines metrics, monitoring cadence, and management review. | System audits, Compliance audits | Implemented |
| 10 | Improvement (nonconformity & corrective action, continual improvement) | Nonconformities are captured as findings in the risk register or via incident response; corrective action plans are tracked to closure. | Risk management, IR | Implemented |
Annex A controls: by theme
A.5 Organizational controls (37)
| Control area | Foundry posture | Policy | Status |
|---|---|---|---|
| A.5.1–5.5 Policies, roles, segregation of duties | Policy library owned by the Security Officer; reviewed annually or on material change. Privileged actions require a second approver. | Policy mgmt, Roles & training | Implemented |
| A.5.7 Threat intelligence | Threat intel inputs (CISA, vendor advisories, AI/LLM-specific advisories) feed the threat-management hunt practice. | Threat mgmt | Implemented |
| A.5.8 Information security in project management | Threat modeling is mandatory for new features; secure SDLC checks gate merge. | Secure SDLC | Implemented |
| A.5.9–5.14 Asset inventory, classification, labelling, handling, transfer | Hardware, SaaS, and data assets are inventoried; data is classified Public / Internal / Confidential / PHI with handling rules per class. | Asset mgmt, Data mgmt | Implemented |
| A.5.15–5.18 Access control (policy & lifecycle) | Joiner/mover/leaver workflow; quarterly access reviews; least-privilege RBAC enforced at the API layer before requests reach the FHIR store. | Access control | Implemented |
| A.5.19–5.23 Supplier relationships & cloud services | Vendor risk assessment before any subprocessor handles PHI; BAA required where PHI flows; SHA-pinned GitHub Actions and version-tag-pinned production container images bind the supply chain (content-digest pinning is a near-term roadmap item). | Vendor risk, Subprocessors | Implemented |
| A.5.24–5.28 Information security incident management | Incident response runbook with named roles, severity scale, evidence preservation, and post-incident review. | IR, Breach | Implemented |
| A.5.29–5.30 ICT readiness for business continuity | RTO/RPO targets for the clinical data plane, identity provider, and audit pipeline; AWS regional posture documented. | BCDR | Implemented |
| A.5.31–5.37 Legal, IP, records, privacy, documented procedures | Regulatory register tracks HIPAA, state breach laws, and applicable AI rules; records retention follows the data-management policy. | Data mgmt, Privacy | Implemented |
A.6 People controls (8)
| Control area | Foundry posture | Policy | Status |
|---|---|---|---|
| A.6.1 Screening | Background checks before access to PHI-touching systems. | HR & personnel | Implemented |
| A.6.2 Terms & conditions of employment | Confidentiality and acceptable-use obligations are part of standard employment / contractor agreements. | HR & personnel | Implemented |
| A.6.3 Awareness, education & training | Annual HIPAA security and privacy awareness training at onboarding and on a yearly refresh, tracked to completion; AI-specific awareness is covered within it; phishing simulations. Role-based training for specialist functions is planned. | Roles & training | Partially implemented |
| A.6.4 Disciplinary process | Sanction policy documented; consistent application by HR. | HR & personnel | Implemented |
| A.6.5 Responsibilities after termination | Confidentiality obligations survive termination; access revoked same day. | HR & personnel, Access | Implemented |
| A.6.6 Confidentiality / NDA | NDAs with workforce and third parties as appropriate. | HR & personnel | Implemented |
| A.6.7 Remote working | Remote-first workforce; baseline requires MDM-enrolled endpoints, FileVault, and no PHI on local disk. | Endpoint & MDM | Implemented |
| A.6.8 Information security event reporting | All workforce members can report events to security@bioscopefoundry.com; non-retaliation policy is part of HR. | IR | Implemented |
A.7 Physical controls (14)
| Control area | Foundry posture | Policy | Status |
|---|---|---|---|
| A.7.1–7.4 Physical security perimeter, entry, offices, monitoring | PHI lives in Amazon Web Services data centers (inherited safeguards); Carmel, IN office holds no PHI media. Office entry is keyed and logged. | Facility | Implemented |
| A.7.5–7.9 Protecting against physical & environmental threats | Inherited from AWS for PHI systems; office threats covered by the facility policy. | Facility | Implemented |
| A.7.10 Storage media | No removable PHI media; cloud-backed FHIR data only. | Asset mgmt | Implemented |
| A.7.11–7.13 Supporting utilities, cabling, equipment maintenance | Largely inherited from AWS for PHI workloads; not applicable to the Foundry office in any PHI-bearing capacity. | Facility | Inherited |
| A.7.14 Secure disposal or re-use | MDM remote-wipe on decommission; asset register updated. | Asset mgmt, MDM | Implemented |
A.8 Technological controls (34)
| Control area | Foundry posture | Policy | Status |
|---|---|---|---|
| A.8.1–8.5 User endpoint, privileged access, identity, authentication | Doctor onboarding uses email magic links with short-lived sessions; workforce access to each console enforces the strongest MFA factor it supports (phishing-resistant WebAuthn passkeys preferred; enforced today on the AWS root account); SMS one-time codes prohibited for workforce. | Access, NIST 800-63B | Implemented |
| A.8.6 Capacity management | Provider-native autoscaling and quotas; capacity reviewed during BCDR exercises. | BCDR | Implemented |
| A.8.7 Protection against malware | EDR baseline on endpoints; container image scanning; sandboxed (Tier-4) execution for untrusted workloads. | MDM, Threat | Implemented |
| A.8.8 Management of technical vulnerabilities | Dependency scanning; SHA-pinned GitHub Actions and version-tag-pinned containers (content-digest pinning is a near-term roadmap item); npm --min-age 7 cooldown; SLA-tracked patching. | Vuln mgmt | Implemented |
| A.8.9 Configuration management | Infrastructure as code (Terraform / Pulumi for AWS; Nix for host configuration); peer-reviewed change. | CCM | Implemented |
| A.8.10 Information deletion | Retention schedules per data class; deletion or de-identification on schedule; BAA-driven return / destruction on offboarding. | Data mgmt | Implemented |
| A.8.11 Data masking | The PHI redaction layer removes PHI before physician-facing sanitized surfaces are produced; agent worktrees and logs use machine-readable identifiers, not PHI content. | AI governance, Data protection | Implemented |
| A.8.12 Data leakage prevention | FHIR-only PHI boundary; egress controls on the healthcare network perimeter; outbound notification channels designed to avoid PHI payloads. | Data protection, Security arch | Implemented |
| A.8.13 Information backup | FHIR store backup and restore tested per BCDR; retention aligns with HIPAA’s six-year minimum for required documentation. | BCDR | Implemented |
| A.8.14 Redundancy of processing facilities | AWS regional posture provides redundancy; object-storage exports replicate across regions for resilience. | BCDR | Implemented |
| A.8.15 Logging | Centralized audit logging with six-year retention; logs designed to record identifiers, not PHI content. | System audits | Implemented |
| A.8.16 Monitoring activities | Detection rules cover authentication, privileged access, and FHIR access anomalies; SOC-style triage rotation. | Threat, System audits | Implemented |
| A.8.17 Clock synchronization | NTP via cloud provider; consistent timestamps across audit logs. | System audits | Implemented |
| A.8.18 Use of privileged utility programs | Privileged utilities require named, MFA-gated access and produce audit trails. | Access | Implemented |
| A.8.19 Installation of software on operational systems | Software baselines enforced through MDM and IaC; ad-hoc installation on operational hosts is not permitted. | MDM, CCM | Implemented |
| A.8.20–8.22 Network security, segregation, service security | Network perimeter controls around the healthcare account; tiered agent network (Tier-4 sandboxed workers cannot reach PHI); private connectivity for inter-service calls. | Security arch | Implemented |
| A.8.23 Web filtering | Endpoint web filtering through MDM. | MDM | Implemented |
| A.8.24 Use of cryptography | TLS 1.2+ in transit; AES-256 at rest under Foundry-managed AWS KMS keys; secrets in a managed broker; argon2id is the required hash where Foundry stores a password-bearing credential (Foundry is passwordless in practice). | Data protection | Implemented |
| A.8.25–8.29 Secure development lifecycle | Threat modeling; mandatory code review; OWASP Top 10 binding for web app code (see OWASP mapping); separated dev / test / prod environments; outsourced development under contract. | SDLC | Implemented |
| A.8.30 Outsourced development | Where applicable, third-party developers are bound by NDA and security requirements; code is reviewed before merge. | SDLC, Vendor | Implemented |
| A.8.31 Separation of dev / test / prod | Production isolated by AWS account, IAM scope, and network policy; test fixtures use placeholders, never real PHI. | Security arch, SDLC | Implemented |
| A.8.32 Change management | IaC-backed change with independent review; emergency-change procedure documented. | CCM | Implemented |
| A.8.33 Test information | No real PHI in non-production environments; synthetic or de-identified fixtures only. | SDLC, Data mgmt | Implemented |
| A.8.34 Protection of information systems during audit testing | Audit and penetration-testing activities are coordinated with platform owners; sensitive systems get read-only access where possible. | Compliance audits | Implemented |