Hook

Your company is SOC 2 Type II certified. Your auditors have verified that you have controls over security, availability, and confidentiality. So when you deploy a new AI system, your compliance team asks: "Is it covered by SOC 2?" Your IT director says, "Probably? The system runs on our infrastructure, which is SOC 2 certified." Your security team says, "But it processes customer data differently than traditional systems. It learns from it, uses it to train models, retains it longer. I'm not sure our existing security controls apply." Your data protection officer says, "And it's making decisions that might affect customer rights. That's probably a GDPR issue, which overlaps with ISO 27001 if you have that certification too." Two weeks of meetings later, you realize: your existing compliance frameworks cover parts of AI system compliance, but not all. You need to understand which controls are sufficient and which need to be extended.

Purpose

SOC 2 and ISO 27001 are not AI-specific frameworks. But AI systems process data and make decisions in ways that existing controls need to account for. A traditional application stores customer data and makes decisions based on that data. An AI system stores customer data, uses it to train models, retains it longer, shares it with third parties (to the model can learn), and makes decisions in ways that aren't easily explainable. Your existing controls for data security, access control, and availability still apply. But they're not sufficient. You need to extend them.

This lesson maps the Trust Service Criteria (SOC 2) and ISO 27001 controls to AI system requirements, identifies gaps, and shows how to close them. It's not about adopting a new framework. It's about adapting your existing frameworks to cover AI.

Why This Matters

For Your Auditors: They'll ask how SOC 2 and ISO 27001 controls apply to your AI systems. If you say "we'll figure it out," you'll get a finding. If you say "here's how we've adapted our controls," you're compliant. The difference is documentation and intentional design.

For Your Customers: SOC 2 and ISO 27001 certificates are trust signals. Customers rely on them. If you deploy AI systems that aren't covered by your certificates, you're reducing the trust signal. You're telling customers your compliance coverage is unclear.

For Your Insurance and Risk Management: Your cyber insurance and compliance insurance coverage depends on whether you maintain SOC 2 and ISO 27001 certifications. If you deploy systems that violate these frameworks, you could lose coverage.

For Your Audit Timeline and Cost: Audits can uncover AI system control gaps. If gaps are found, you'll need to remediate and potentially re-audit. Planning for AI compliance from the start prevents audit surprises.

Core Concepts

Key Insight 1: SOC 2 Trust Service Criteria and AI

SOC 2 defines five Trust Service Criteria:

Criterion 1: Security (CC = Common Criteria)

SOC 2 requires controls over access to systems and data. AI systems require extended controls:

Traditional Control
Extension for AI
Why

CC6.1: User Access Policy exists
Applied to model versioning and feature stores
AI systems need to control who can modify models, training data, features

CC6.2: Access granted based on need-to-know
Applied to training data access
Data scientists should access training data needed for their work; not all team members need access to all data

CC6.3: Authentication and authorization
Extended to model changes
Deploying a new model version is as sensitive as deploying code; who can trigger a deployment? Who must approve?

CC6.4: Privileged access restricted
Extended to hyperparameter tuning and feature engineering
Changing model hyperparameters or features changes system behavior; this is privileged access

CC7: Access controls are monitored
Extended to model decision logging
Every model decision should be logged with who requested it (for audit)

Criterion 2: Availability (A = Availability)

SOC 2 requires systems to be available per service levels. AI systems add availability risks:

Traditional Control
Extension for AI
Why

A1: System availability objectives are defined
Updated for AI systems
If your demand forecasting model is unavailable, supply chain planning has no forecasts. Define SLA.

A1.2: Availability of systems is monitored
Extended to model availability and accuracy
Availability isn't just "is the model returning predictions?" It's "are the predictions good quality?"

A2: Preventive controls over availability
Extended to model versioning and rollback
If a new model degrades accuracy, you need fast rollback to previous version. Build this as operational control.

Criterion 3: Processing Integrity (PI)

SOC 2 requires systems to process transactions accurately and completely. AI systems introduce new integrity risks:

Traditional Control
Extension for AI
Why

PI1: System objectives are defined
Updated for AI
Define accuracy targets, fairness targets, explainability requirements

PI2.1: Data input is complete and accurate
Extended to training data validation
Garbage in, garbage out. Validate training data quality.

PI2.2: Data input is authorized
Extended to training data authorization
Who authorized this data to be used for training? Is it licensed? Is it privacy-compliant?

PI3: Information processing is accurate
Extended to model predictions
Are model predictions accurate? How do you measure accuracy in production?

PI4: System changes are managed
Extended to model changes
Every model update is a system change. Use change management.

Criterion 4: Confidentiality (C)

SOC 2 requires controls over confidential information. AI systems amplify confidentiality risks:

Traditional Control
Extension for AI
Why

C1: Confidential data is protected
Extended to training data
Training data contains customer data. It's confidential. Protect it like you'd protect backups.

C2: Access to confidential data is restricted
Extended to model access
If the model can be queried, it can potentially leak training data (membership inference attacks). Restrict who can query the model.

C3: Confidential data is not disclosed in error
Extended to model explanations
Explanations of model decisions should not leak training data. If an explanation says "we made this decision because customer X had characteristic Y," that's a data breach.

Criterion 5: Privacy (P)

SOC 2 requires respect for privacy obligations (particularly GDPR and CCPA). AI systems introduce privacy complexities:

Traditional Control
Extension for AI
Why

P1: The entity obtains customer consent
Extended to model training use
Customers consent to their data being used for service delivery. Do they consent to their data being used for model training?

P2: Data is retained per retention policies
Extended to training data retention
How long is training data kept? GDPR requires data to be deleted when no longer needed. If you keep training data indefinitely for model improvement, that violates retention policy.

P3: The entity provides transparency
Extended to model decisions
Customers need to know they're subject to AI decision-making and how to challenge it.

P4: The entity manages personal data securely
Extended to model-generated data
Models generate predictions, inference scores, confidence values. These are personal data too. Protect them.

P5: Customer data requests are honored
Extended to model training data
If a customer requests deletion (right to be forgotten), you need to delete their data from training data, retrain the model, and ensure the old model doesn't persist. This is operationally complex.

Key Insight 2: ISO 27001 Controls and AI

ISO 27001 defines 14 control categories (A1-A14). The ones most relevant to AI:

A5: Access Control

• A5.1: User registration and access rights management
  - Extended to AI: Who can access the model? Who can modify hyperparameters? Who can change training data?
  - A5.2: User access provisioning and de-provisioning
  - Extended to AI: When someone leaves the team, do you revoke access to training data, model code, and deployment systems?
  - A5.3: Access right review
  - Extended to AI: Periodically audit who has access to AI systems and verify access is still needed.

A6: Cryptography

• A6.1: Encryption of data at rest and in transit
  - Extended to AI: Training data should be encrypted. Model parameters (especially for proprietary models) should be encrypted. Predictions should be encrypted in transit if they contain sensitive information.
  - A6.2: Cryptographic key management
  - Extended to AI: If you're using encrypted training data, you need key management. Who controls keys? How are they rotated?

A8: Physical and Environmental Security

• A8.1: Physical security perimeter
  - Extended to AI: Where is training data stored? Is it on secure storage? If it's in the cloud, what are the cloud provider's physical security controls?

A9: Operations and Communications

• A9.1: Operational change management
  - Extended to AI: Model changes are operational changes. Use formal change management.
  - A9.2: Capacity planning
  - Extended to AI: Do you have capacity to train models on time? To score all predictions within SLA?
  - A9.3: Separation of development, test, and production
  - Extended to AI: Do you have separate environments for training model, testing model, deploying to production? Or are you training in production (risky)?
  - A9.4: Segregation of duties
  - Extended to AI: Can one person train, test, and deploy a model? No. Use segregation of duties (data scientist trains, engineer tests, ops deploys).

A10: Communications Security

• A10.1: Network security
  - Extended to AI: How do requests to the model travel? Are they encrypted? Can someone intercept a request and extract training data?

A12: Information Security Incident Management

• A12.1: Event logging and monitoring
  - Extended to AI: Log model decisions, model changes, model performance degradation. Use monitoring to detect anomalies.
  - A12.2: Incident handling
  - Extended to AI: AI incidents require specialized response (model degradation, bias detection, data exposure). Include in incident response plan.

A13: Business Continuity and Disaster Recovery

• A13.1: Business continuity management
  - Extended to AI: If a model fails, what's the fallback? Can you continue operations? Do you have a backup model?
  - A13.2: Information recovery
  - Extended to AI: If training data is corrupted, can you recover? Do you have backups of training data?

A14: Compliance

• A14.1: Identification of applicable regulations
  - Extended to AI: What regulations apply to your AI systems? (GDPR, CCPA, EU AI Act, sector-specific rules)
  - A14.2: Compliance with regulations
  - Extended to AI: Are your AI systems actually compliant? Do you have evidence?
  - A14.3: Information security review
  - Extended to AI: During your annual ISO review, include AI systems. Are they improving in security posture?

Key Insight 3: The Gap, What Existing Frameworks Miss for AI

SOC 2 and ISO 27001 cover security, availability, and operational practices. They assume data goes into a system and comes out again, transactions are processed, outputs are generated. But AI systems have additional risks that traditional frameworks don't address:

Gap 1: Model Risk

Traditional frameworks: "Is the system accurate?"

AI: "Is the model accurate? Is it degrading? Is it biased? Is it vulnerable to adversarial inputs?"

Gap 2: Data Retention and Reuse

Traditional frameworks: "Data is encrypted and retained per policy."

AI: "Data is stored indefinitely as training data, used to train models that learn from it, and used to improve models for all customers."

This is a different data lifecycle than traditional systems. It requires different controls.

Gap 3: Model Explainability

Traditional frameworks: "The system produces accurate outputs."

AI: "The system produces accurate outputs, but can you explain why? Can the user understand the decision?"

Explainability is both a compliance requirement (for regulations like the EU AI Act) and an operational requirement (for user trust).

Gap 4: Fairness and Bias

Traditional frameworks: Don't address bias or fairness. (Why would they? A traditional system doesn't discriminate based on protected characteristics.)

AI: "Is the model biased? Are you monitoring for bias? What's your remediation process?"

Gap 5: Third-Party AI Services

Traditional frameworks: "Evaluate vendors for security and compliance."

AI: "Evaluate vendors, but also understand what they do with your data (for model training), how you can audit models, whether you can switch vendors, whether they comply with regulations like GDPR."

Existing frameworks cover vendor evaluation but not AI-specific vendor risks (lock-in, data exposure, continuity).

Key Insight 4: Closing the Gaps, What to Add to Your Control Framework

For each gap, add a control:

Gap
New Control
Verification

Model Risk
Weekly accuracy monitoring and alerts; monthly model performance audit; annual model risk assessment
Dashboard: accuracy trends, alert history

Data Retention
Update data retention policies to explicitly address training data; define how long training data is kept; implement deletion when retention period expires
Audit: verify training data is deleted after retention period

Explainability
Design systems to provide explainable predictions; test explainability with non-technical users; document explanation methodology
Audit: sample predictions and verify explanations are provided and understandable

Fairness and Bias
Implement automated bias testing (weekly); alert if metrics diverge >threshold; document bias testing results; remediate if bias is found
Audit: bias testing reports for past 12 months; remediation records

AI Vendor Risk
Evaluate vendors using extended criteria (data use, audit rights, lock-in, continuity); negotiate contractual protections; monitor vendors continuously
Audit: vendor risk assessments, contracts, evidence of monitoring

Key Insight 5: Audit Preparation for AI Systems

When your SOC 2 or ISO 27001 auditor asks about AI systems, be prepared to answer:

Security Controls:

• "How do you control access to training data?" (Answer: Access list, approved requesters, role-based access)
• "How do you monitor access?" (Answer: Audit logs, quarterly access review, automated alerts for unusual access patterns)
• "How do you protect training data in transit?" (Answer: TLS encryption, VPN for secure transfer)
• "How do you protect training data at rest?" (Answer: Encryption at rest, key management, restricted access)

Availability Controls:

• "What's the SLA for model availability?" (Answer: 99.5% uptime, <5 minute recovery if model fails)
• "How do you monitor model availability?" (Answer: Automated health checks every 5 minutes, alert if unavailable)
• "What happens if the model fails?" (Answer: Automatic failover to previous model version or fallback process)

Processing Integrity:

• "How do you ensure model accuracy?" (Answer: Monthly validation against holdout test set, alert if accuracy drops >5%)
• "How do you manage model changes?" (Answer: Formal change management process, testing before deployment, rollback if accuracy degrades)
• "How do you prevent training data corruption?" (Answer: Data validation on ingestion, audit trail of data changes, backups)

Confidentiality and Privacy:

• "How do you ensure customer data in training data is protected?" (Answer: Access restrictions, encryption, retention policies, deletion on request)
• "How do you prevent data leakage through model explanations?" (Answer: Review explanations to ensure no PII is disclosed)
• "What's your retention policy for training data?" (Answer: [specific period]; deletion is automated)
• "Can you honor customer data deletion requests?" (Answer: Customer data is deleted from training data, model is retrained to remove influence of deleted data)

Incident Management:

• "Have you had any AI-related incidents?" (Answer: Yes, [describe]. Detected in [timeframe], contained in [timeframe], root cause [cause], remediation [action])
• "Do you have an incident response plan for AI systems?" (Answer: Yes, [reference plan]. Includes detection, investigation, containment, recovery, communication)

Compliance:

• "What regulations apply to your AI systems?" (Answer: GDPR, CCPA, EU AI Act [if applicable], [sector-specific rules])
• "How do you ensure compliance?" (Answer: Risk assessments, bias testing, human oversight, documentation, audits)

Auditors will expect documentation to back up each answer. Don't say "we monitor access" without an audit log. Don't say "we test for accuracy" without a testing report.

Key Insight 6: Control Maturity Levels

As you extend SOC 2 and ISO controls to cover AI, assess your maturity:

Level 1: Ad Hoc

• AI systems are deployed but controls are informal
• No documented policies for AI data retention, access control, accuracy monitoring
• Incident response to AI issues is reactive
• Auditors find findings

Level 2: Defined

• Policies exist for AI systems
• Controls are documented but not consistently applied
• Some monitoring, some gaps
• Auditors find minor findings; remediation is feasible

Level 3: Repeatable

• Policies are documented and applied to all AI systems
• Monitoring is automated and consistent
• Incident response includes AI-specific procedures
• Auditors may find one or two minor gaps
• You're ready for expanded audit scope

Level 4: Managed

• Policies are mature and regularly reviewed
• Monitoring is automated with alerting thresholds
• Metrics tracked and trended
• Incident response is tested regularly
• Auditors find minimal gaps
• You're optimizing control effectiveness

Level 5: Optimized

• Policies are continuously improved based on lessons learned
• Monitoring is predictive (alerting before problems occur)
• Metrics are benchmarked against industry standards
• Incident response is tested quarterly and improved
• Auditors may find no findings

Most organizations are between Level 1 and Level 2 for AI systems. Your goal should be Level 3 (defined, documented, repeatable) within 12 months, Level 4 within 24 months.

Practical Use Cases

Use Case 1: Extending SOC 2 Type II for a Demand Forecasting System

The Scenario: Your company is SOC 2 Type II certified. You've deployed a demand forecasting AI system. Your auditors are asking whether the system is covered by your SOC 2 scope. If not, you'll get a finding. If yes, you need to prove controls are equivalent.

Approach:

• 
  Inclusion in Scope: Explicitly state the AI system is in scope for SOC 2.
• 
  Mapping Controls to Trust Service Criteria:

Criterion
Control Name
Traditional Implementation
AI System Extension

Security (CC)
Access to systems and data is controlled
Role-based access to applications; audit logging
Role-based access to training data, model code, deployment systems; audit logging includes who accessed training data, who trained/deployed models

Security (CC)
Privileged access is restricted and monitored
DBAs have restricted access to production databases
Data scientists have restricted access to training data; only approved data scientists can train models; privileged access requires approval

Availability (A)
System availability is monitored
Uptime monitoring; alerts if availability < 99.5%
Model availability monitoring; alerts if model is unavailable or accuracy degrades; SLA: 99.5% uptime, monthly accuracy review

Processing Integrity (PI)
Changes are managed
Change control process for code deployments
Change control process for model deployments; testing before deployment; rollback if accuracy degrades

Confidentiality (C)
Confidential data is protected
Encryption at rest and in transit
Training data is encrypted at rest and in transit; access is restricted; deletion is automated per retention policy

Privacy (P)
Customer data is protected per privacy policy
Data is retained per retention policy; deletion is honored
Training data is deleted per policy; customer deletion requests trigger model retraining to remove customer influence

• Control Testing: For the SOC 2 audit, auditors will test controls. For AI system controls:
  - Request access to training data → auditors verify access is restricted and audit logging captures the request
  - Review model change history → auditors verify changes were approved, tested, and deployed via change control
  - Query accuracy monitoring → auditors verify accuracy is monitored monthly and thresholds trigger investigation
  -
  Request sample of audit logs → auditors verify logs include who accessed training data and when
• 
  Remediation: Any gaps discovered must be remediated before the audit is finalized.

Example remediation: "Auditors discovered that access to training data is not logged in a centralized audit system; logs are scattered in application logs. Remediation: Implement centralized audit logging for all training data access; include in quarterly audit review."

Use Case 2: Extending ISO 27001 for an Anomaly Detection System Used in Incident Response

The Scenario: You've deployed an anomaly detection system that identifies unusual patterns in infrastructure logs. The system is used by your NOC and security team for incident detection. It's a critical system. You want to extend ISO 27001 to cover it.

Mapping ISO Controls:

ISO 27001 Control
Extension for AI System

A5.1: User registration and access rights
Who can access the model? Who can update features? Who can retrain the model? Create access roles: (a) Data analysts can query the model for investigation (read-only), (b) Engineers can update features (change approval required), (c) ML engineers can retrain model (change control required).

A6.1: Encryption of data at rest and in transit
Training data (infrastructure logs) is sensitive. Encrypt at rest using AES-256. Encrypt in transit using TLS 1.2+.

A9.1: Change management
Model changes (new features, retraining, version upgrades) are treated as changes. Use formal change control: description, risk assessment, testing, approval, deployment, rollback plan.

A9.3: Separation of duties
One person should not have ability to train, test, and deploy a model. Separate roles: Data Engineer (prepares data), ML Engineer (trains model), SRE (deploys to production). Each role requires different access.

A9.4: Segregation of environments
Separate development, staging, and production models. Training happens in development. Testing happens in staging. Only after successful testing does the model move to production.

A12.1: Event logging and monitoring
Log all model decisions (anomaly detected or not). Log for every decision: timestamp, input (log summary), output (anomaly score), confidence. Retention: 90 days (to allow incident investigation).

A12.2: Incident response
Include AI-specific response procedures: if the model is generating false positives (too many alerts), disable auto-remediation and require manual review while investigating. If the model is generating false negatives (missing real incidents), increase alerting sensitivity and escalate to security team.

A13.1: Business continuity
If the anomaly detection model fails, the fallback is rule-based alerting on predefined thresholds. Document the fallback and ensure it's tested.

Use Case 3: Audit Scope Definition, Which AI Systems Are in Scope?

The Scenario: You have 15 AI systems across your organization. Your auditor asks: which are in scope for SOC 2 / ISO 27001? If you're unsure, the auditor will want to see a documented scope definition.

Scope Definition Framework:

An AI system is in-scope if:

1. It processes customer data, employee data, or confidential business information, AND
2. It affects a Trust Service Criterion (security, availability, processing integrity, confidentiality, privacy), OR
3. It affects an ISO 27001 control category

Example:

System
Data Type
Risk
In Scope?
Why

Demand Forecasting
Historical sales data (non-PII)
Uses proprietary data for training
YES
Confidential business information; affects confidentiality (C) and privacy (P)

Chatbot (customer support)
Conversation transcripts
May contain customer PII
YES
Customer data; affects confidentiality (C) and privacy (P); limited-risk under EU AI Act

Anomaly Detection (infrastructure)
System logs (non-PII)
Critical for incident detection
YES
Affects availability (A) and security (CC); critical system

Spam Filter (email)
Email content
May contain confidential business information
YES
Affects confidentiality (C); business communication

Recommendation Engine (internal)
Employee usage patterns
Non-critical, internal
MAYBE
Depends on whether employee data is considered confidential; probably YES (affects privacy)

Image Classification (internal tool)
Internal images
Non-sensitive
NO
Does not process customer or confidential data; not critical

Prototype ML Model (research)
Public datasets
Experimental, not deployed
NO
Not in production; not affecting users or business

Scope Documentation (provided to auditors):

"Our SOC 2 scope includes the following AI systems: [list]. These systems process customer data, confidential business information, or are critical to our operations. Systems not in scope: [list]. These systems process non-confidential data or are experimental/research projects not deployed to production."

Examples

Example 1: Control Mapping Template for AI Systems

| # | Trust Service Criterion / ISO Control | Description | Traditional Implementation | AI System Extension | Evidence |

|---|---|---|---|---|

| 1 | CC6.2 / A5.3 Access restrictions | Access to systems is restricted based on need-to-know | LDAP groups; role-based access; quarterly access review | Access to training data is restricted to approved data scientists; model retraining is approved by team lead; audit log reviewed monthly | Audit log showing access to training data store; approval emails for model training jobs; access review spreadsheet (monthly) |

| 2 | A6.1 Encryption | Data is encrypted at rest | AES-256 encryption for database | Training data is encrypted with AES-256; encryption keys are managed by central security team | AWS KMS key configuration; encryption audit trail |

| 3 | A9.1 Change management | System changes are formally managed | Change review board; testing; approval | Model changes (retraining, feature changes) use change control: description, risk assessment, testing, approval | Change request tickets; test results; approval logs |

| 4 | A12.1 Monitoring | System behavior is monitored and logged | Application logging; centralized log aggregation | Model decisions are logged: timestamp, inputs, output, confidence; logs aggregated to central system | Logging code in model service; sample of logs from Splunk/ELK; retention policy |

| 5 | P2 Data retention | Data is retained per retention policy | Automated deletion after retention period | Training data is deleted after [X months]; deletion is automated; retained data is inventoried | Deletion logs; data inventory (quarterly) |

Example 2: Bias Testing Report (SOC 2 / ISO Compliant)

Document Title: Anomaly Detection Model Fairness Audit - Q4 2025

Purpose: Ensure anomaly detection system performance is consistent across system types and does not discriminate.

Methodology:

• Monthly testing on production model
• Dimensions tested: System type (web server / database / network), Application criticality (critical / important / non-critical), Environment (production / staging)
• Metric: False positive rate (alerts on normal behavior)
• Threshold: If any dimension shows false positive rate divergence >5%, investigate

Test Date: 2025-12-15

Results:

• Web servers: 2.1% false positive rate
• Database servers: 2.3% false positive rate
• Network systems: 2.0% false positive rate
• Divergence: 0.3% (within threshold)
• Critical systems: 2.1% false positive rate
  - Important systems: 2.2% false positive rate
  - Non-critical systems: 2.0% false positive rate
  - Divergence: 0.2% (within threshold)

Finding: No bias detected. Model performance is consistent across dimensions.

Remediation: None required.

Approval:

• Model Owner: Jane Smith (Data Engineer) - Signature - Date
• Compliance Officer: John Doe (Chief Information Security Officer) - Signature - Date

Example 3: Access Control Policy for AI Systems

Policy Title: Access Control for AI Systems and Training Data

Scope: All AI systems and associated training data in production and development environments.

Access Levels:

Role
Access
Approval

Data Scientist
Read training data; run model training in development environment; propose model changes
Team Lead approval

ML Engineer
Read training data; deploy models to staging and production; change model configuration
Manager + Security team approval

Data Analyst
Query trained model in production (read-only); view model predictions
Team Lead approval

SRE
Monitor model health; restart model if it fails; view logs
On-call approval (no additional approval needed)

Security team
Audit access logs; investigate access anomalies
Standard incident response (no approval needed)

Access Review: Quarterly review of who has access to what. Any access not currently needed is revoked.

Audit Logging: All access to training data is logged with timestamp, user, action (read, write, delete), and outcome. Logs are retained for 2 years and reviewed monthly by compliance team.

Approval Process for New Access:

1. Requestor submits access request (reason, duration, system)
2. Requestor's manager approves
3. Data security team approves (confirms reason is legitimate)
4. Access is granted; approval recorded
5. Quarterly review: confirm access is still needed; revoke if not

Anti-Patterns

Anti-Pattern 1: "SOC 2 Doesn't Apply to AI Systems; It's Only for Traditional IT"

Why This Fails: SOC 2 covers all systems that affect your trust service criteria. If an AI system processes customer data, it affects Confidentiality and Privacy. If it affects business continuity, it affects Availability. If it makes decisions, it affects Processing Integrity. SOC 2 applies.

What to Do Instead: Explicitly include AI systems in your SOC 2 scope. Map controls to your AI systems. Document how each control is implemented for AI. Auditors will ask about this, and you should have clear answers.

Anti-Pattern 2: "We'll Use the Same Controls for AI as We Use for Traditional Systems"

Why This Fails: Some controls transfer directly (encryption, access control, change management). But AI systems have unique characteristics (model training, fairness, explainability) that require extended controls.

What to Do Instead: Use traditional controls as a starting point. Then identify gaps specific to AI and add controls. Bias testing, model accuracy monitoring, and explainability validation don't exist in traditional control frameworks. You need to add them.

Anti-Pattern 3: "Auditors Won't Ask About AI Systems, So We Don't Need to Document Controls"

Why This Fails: Auditors are increasingly sophisticated about AI. They will ask about AI systems. If you don't have documented controls, you'll get findings. If you have controls but haven't documented them, you'll still get findings (documentation is required).

What to Do Instead: Assume auditors will ask. Document controls proactively. Show evidence (logs, test results, approval records). The more documentation you have, the faster the audit goes.

Anti-Pattern 4: "Privacy Controls Are Compliance Team's Problem; We Don't Need to Implement Them in IT"

Why This Fails: Privacy controls (data retention, deletion, audit trails) are not compliance overhead. They're operational requirements. If you can't delete training data when a customer requests deletion, you're in violation. If you can't audit who accessed customer data, you're in violation. These are IT implementation problems, not compliance checklist items.

What to Do Instead: Partner between compliance team (defines requirements) and IT team (implements controls). Requirements like "training data must be automatically deleted after X months" require IT infrastructure (scheduled deletion jobs, audit logging). Both teams own the problem.

Anti-Pattern 5: "Our Audit Is Next Month; We Can't Remediate Control Gaps in Time"

Why This Fails: True, you probably can't remediate everything in a month. But you can document what you're working on. Auditors look for "management's plan to remediate gaps," not for immediate perfection. A clear roadmap with timelines and progress is better than claiming everything is fine when it isn't.

What to Do Instead: When you discover control gaps, document them immediately. Create a remediation plan with timelines. Share the plan with your auditor before the audit if possible. During the audit, show progress. "We discovered this gap 3 months ago; we're implementing control X with target completion of [date]" is a reasonable response.

Human Judgment Checkpoints

Checkpoint 1: Scope Definition, Which Systems Are In Scope?

Not every AI system needs to be in your SOC 2 or ISO 27001 scope. But the decision should be explicit, not accidental. Consider: Does the system process sensitive data? Is it critical to operations? Does it affect customer rights? If yes to any, it's in scope.

Checkpoint 2: Control Effectiveness vs. Operational Burden

Some controls create operational burden. Audit logging creates disk space usage. Access reviews create administrative overhead. Encryption creates CPU overhead. You need controls, but design them to be efficient. Don't over-control.

Checkpoint 3: Audit Timing, When to Expand Your Audit Scope

You might be SOC 2 Type II certified without including AI systems. Should you expand scope to include AI? It depends on: (1) how mature are your AI controls? (2) are there customer/regulatory expectations that they're covered? (3) are you losing business because customers see AI systems as out-of-scope?

If your AI controls are solid, expanding scope is straightforward, auditors verify controls exist and work. If your controls are immature, expanding scope first may result in findings. Consider expanding scope when you're confident controls will pass.

Checkpoint 4: Documentation Depth, How Much Is Enough?

Documentation requirements can be overwhelming. You don't need to document every decision. But you need to document evidence of controls. The question: if an auditor asks "how do you control access to training data?", can you show them evidence (access logs, approval records, quarterly reviews)? If yes, you have enough documentation.

Key Takeaways

• 
  Extend SOC 2 and ISO 27001 to AI systems explicitly: Don't assume traditional controls are sufficient. Map each control to your AI systems and identify extensions needed. Document gaps and remediation plans.
• 
  Add AI-specific controls: Traditional frameworks don't address model accuracy, bias, or explainability. For each AI system, add controls for accuracy monitoring, bias testing, and explainability validation.
• 
  Map controls to evidence: For each control, identify how you'll prove it's working. Evidence includes: logs (access, decisions, changes), test results (accuracy, bias), approvals (change control), and reviews (quarterly audits).
• 
  Include AI systems in audit scope intentionally: Decide whether each AI system is in scope for SOC 2 / ISO 27001 based on risk. Document your scope definition. Auditors will ask.
• 
  Design controls for efficiency: Controls create overhead (logging, access reviews, testing). Design controls to be automated where possible (scheduled jobs, alerting) to minimize operational burden.
• 
  Separate roles and responsibilities for AI systems: Data scientists train models, engineers test models, ops deploys models. No one person should have all three capabilities (segregation of duties).
• 
  Monitor and trend control effectiveness: Track metrics: accuracy, bias test results, incident response time, audit findings. Improve controls over time based on trends.
• 
  Integrate compliance into development workflow: Don't treat compliance as a one-time gate before audit. Make compliance continuous. Every model update requires documentation update and control validation.
• 
  Prepare for extended audits: As regulators and customers increasingly care about AI governance, audit scope will expand. Build controls now so expanded scope doesn't shock you later.