The CISO Checklist for Deploying AI in a Regulated Environment

The pressure to deploy AI is real. The pressure to satisfy auditors is also real. In a regulated environment, both pressures land on the CISO’s desk simultaneously.

The organizations that navigate this well are not the ones that deployed AI fastest and scrambled to document it afterward. They are the ones that answered the compliance questions before the first model touched production data.

This is a working checklist — not a framework document or a vendor pitch. These are the questions an auditor will ask, translated into the architectural decisions you need to make before they ask them.

Before You Deploy: What You Need to Know

1. What data will the model access, and what is its classification?

This sounds obvious. In practice, it is the question most organizations cannot answer cleanly at the point of deployment. Models are connected to data sources through integrations built for functionality, not governance. The model accesses what the integration permits. What the integration permits is often determined by convenience, not policy.

Before deployment, you need a data map: which data sources, what classification, what regulatory regime governs each source, and what the model is authorized to do with it. If the answer is “it depends on the prompt,” you are not ready to deploy in a regulated environment.

2. Where is the model running, and who controls the execution environment?

For SOC 2, HIPAA, and PCI-DSS, your compliance posture extends to the infrastructure your AI workloads run on. If the model runs in a shared cloud environment, your BAA, DSA, or other agreements need to cover that environment. If the model runs on-premise, your existing control framework needs to extend to cover AI inference workloads.

The answer “it runs in the cloud” is not sufficient. The answer needs to specify: which cloud, which region, under which agreement, with what isolation guarantees, subject to which incident response obligations.

Compliance is not a layer you add to AI. It is an architecture decision you make before the first model goes live.

3. What does your inference audit log look like?

The auditor will ask three questions: what data did the model access, who authorized that access, and where is your log?

The auditor will ask three questions: what data did the model access, who authorized that access, and where is your log?

If you cannot produce an inference log that answers these questions, you have a compliance gap that no policy document will close. The log needs to capture: session identifier, user or service that initiated the session, data sources accessed, timestamp, and a hash or reference to the prompt and response.

This is not optional for SOC 2 Type II, HIPAA, or DORA. It is the baseline.

4. How is access to the model controlled and logged?

Zero-trust access controls should extend to AI model endpoints. Multi-factor authentication and network access policy can enforce MFA and device posture for users accessing AI applications. Service accounts invoking models should have certificate-based identity, not shared API keys. Every access event should be in the access log.

If your AI application is accessible with a shared credential or without MFA, you have an access control finding waiting to happen.

Framework-Specific Considerations

SOC 2 (Trust Services Criteria)

SOC 2 auditors will look at logical access controls, monitoring, and availability. For AI deployments, the relevant controls are: access control for model endpoints (CC6.1, CC6.3), monitoring of AI system activity (CC7.2), and incident response procedures that cover AI-specific scenarios (CC7.3, CC7.4).

The evidence package needs to demonstrate that access to the model is controlled, that activity is monitored, and that you can detect and respond to anomalies. Inference logging is the primary evidence source.

HIPAA

HIPAA’s Security Rule requires administrative, physical, and technical safeguards for electronic protected health information. If your AI model accesses ePHI — even in a de-identified form that might be re-identified — your safeguards need to extend to the model.

The specific questions: Is the model covered under your existing BAA with the infrastructure provider? Are access controls to ePHI as strong for the model as for human users? Can you produce an audit log of every ePHI access by the model?

Minimum necessary is a core HIPAA principle. The model should access only the ePHI it needs for the specific task it is performing. This is an adapter layer problem — the data access scope needs to be enforced at the infrastructure level, not the application level.

PCI-DSS v4.0

PCI-DSS v4.0 introduces explicit requirements around the security of systems that access cardholder data. AI systems accessing cardholder data are in scope for PCI-DSS. The relevant controls: network segmentation between AI systems and the cardholder data environment, access controls on AI system credentials, and logging of all access to cardholder data.

Requirement 10 (log and monitor) applies fully to AI systems. Every access to cardholder data by a model must be logged, reviewed, and retained according to your PCI log requirements.

GDPR and DORA

GDPR requires that processing of personal data be lawful, purposeful, and subject to data subject rights. AI systems that process personal data for purposes not covered by the original legal basis, or that make automated decisions with significant effects on data subjects, require specific legal and technical safeguards.

DORA (Digital Operational Resilience Act) adds operational resilience requirements for financial entities, including requirements for ICT risk management that extend to AI systems. AI workloads need to be in scope for your DORA ICT risk assessment.

The Architecture Decisions That Determine Compliance

Three architecture decisions determine most of your compliance posture:

Where models run. On-premise with your existing control framework, or cloud with appropriate agreements and isolation. The choice determines which controls you inherit and which you need to implement.

How data access is controlled. Application-layer controls that a model can bypass through prompt manipulation, or infrastructure-layer adapter controls that enforce scope regardless of prompt content. The choice determines whether your data access governance is auditable.

What you log. Access logs without inference logs leave a gap that auditors will find. The logging architecture needs to cover both.

Building the Evidence Package

Before your next audit, you should be able to produce:

• A data map showing what data sources each AI system accesses and the classification of each
• Access control documentation showing how model endpoints are protected
• An inference log demonstrating that AI activity is captured and retained
• Network segmentation documentation showing the AI plane is isolated from sensitive data sources
• An incident response procedure that covers AI-specific scenarios including prompt injection and model manipulation

If any of these is missing, you have work to do before the auditor arrives. The work is architecture work, not documentation work — no amount of policy writing compensates for logging that doesn’t exist or access controls that aren’t enforced.

Acclivity helps regulated organizations build the architecture that satisfies auditors before the audit. If your AI deployment is ahead of your compliance posture, start with a posture review.