Data security controls for AI systems
The mapping
| Framework | Where this control sits |
|---|---|
| Joint Commission RUAIH | Focus area 2 — Effective data management |
| CHAI governance playbooks | Playbook 6 — Responsible data management and use |
| NIST AI RMF | GOVERN |
The artifact: Access control and audit log review record
Who signs it: The chief information security officer
What an assessor actually asks for
Encryption in transit and at rest, access controls, evidence that access logs were reviewed with a named reviewer, regular security assessments, and an incident response plan that has been exercised.
Why the mapping is not obvious
Nothing in this control is new to a security programme, which is exactly the risk: it gets marked complete by reference to the existing SOC 2 posture without anyone checking whether AI systems are inside that perimeter. Inference endpoints, prompt logs and vector stores frequently are not.
The most common failure
The incident response plan does not name AI-specific failure modes — degraded model output, an unavailable inference service, a silent vendor model update. A plan that cannot describe the failure cannot rehearse it.
Where this sits in the whole map
This is one control in the RUAIH ↔ CHAI ↔ NIST crosswalk. The artifact itself is specified at Access control and audit log review record.
Written and reviewed by Neel Chauhan, MD MBA, physician-executive and founder of the Healthcare AI Institute. Last reviewed 2026-07-30.
Generated from data/crosswalk.yaml, where the mapping and the commentary for each control are authored individually. Reviewed on each framework revision.
The Institute accepts no vendor sponsorship, holds no vendor equity and takes no referral fees.