Why ISO 27001 Matters for ML Platforms
ISO 27001 is the international standard for Information Security Management Systems (ISMS). For organizations that build and deploy ML models—especially those processing personal data, financial records, or healthcare information—ISO 27001 certification is increasingly required by enterprise customers, regulators, and insurance providers. But ML platforms introduce security controls that the standard wasn't designed for: model artifacts that encode training data, experiment tracking systems that log sensitive metrics, GPU clusters with broad network access, and inference APIs that can be exploited for model extraction.
This guide maps ISO 27001:2022 Annex A controls to ML-specific implementations, providing practical guidance for certifying your MLOps platform.
Phase 1: ISMS Scope Definition
Defining the MLOps ISMS Boundary
# isms/scope_definition.md — ISMS scope for MLOps platform
## Scope Statement
The Information Security Management System covers the following MLOps
infrastructure and processes:
### In-Scope Systems
1. **Experiment Tracking**: MLflow tracking server, artifact storage (S3)
2. **Model Registry**: MLflow model registry, model versioning
3. **Training Infrastructure**: Kubernetes GPU clusters (EKS/GKE), SageMaker
4. **Data Pipelines**: Airflow DAGs, feature store (Feast), data lakes (S3/GCS)
5. **Model Serving**: Triton Inference Server, KServe, API Gateway
6. **CI/CD Pipelines**: GitHub Actions, ArgoCD, container registries
7. **Monitoring**: Prometheus, Grafana, model drift detection
### In-Scope Data
- Training datasets (may contain PII)
- Model artifacts (weights, configurations)
- Experiment metadata (metrics, parameters, logs)
- Inference request/response logs
- Feature store data
### Out-of-Scope
- Corporate email and productivity tools
- Customer-facing web application (separately certified)
- Physical office security (covered by corporate ISMS)
### Interested Parties
- Enterprise customers (require SOC2/ISO27001 evidence)
- Data Protection Officer (GDPR compliance)
- ML Engineering teams (platform users)
- Security team (ISMS owners)Phase 2: Annex A Controls for MLOps
A.5 Organizational Controls
# A.5.1 — Information Security Policies
# MLOps-specific policies required:
1. ML Data Handling Policy
- Classification of training data (public, internal, confidential, restricted)
- Requirements for PII in training datasets (anonymization, consent)
- Data retention and deletion schedules for model artifacts
2. Model Lifecycle Security Policy
- Access control requirements for model registry (who can promote to production)
- Model signing and integrity verification requirements
- Decommissioning procedures for retired models
3. Experiment Tracking Security Policy
- Authentication requirements for MLflow (SSO, MFA)
- Logging and audit trail requirements
- Secret management (no credentials in experiment logs)
# A.5.15 — Access Control
# MLOps-specific access control model:
Role-Based Access for ML Platform:
┌────────────────────┬──────────┬───────────┬──────────┬───────────┐
│ Role │ Experiments│ Registry │ Training │ Serving │
├────────────────────┼──────────┼───────────┼──────────┼───────────┤
│ Data Scientist │ R/W │ Read │ Submit │ None │
│ ML Engineer │ R/W │ R/W │ R/W │ Deploy │
│ Platform Admin │ R/W │ R/W │ R/W │ R/W │
│ Auditor │ Read │ Read │ Read │ Read │
│ CI/CD Service Acct │ None │ Write │ Write │ Deploy │
└────────────────────┴──────────┴───────────┴──────────┴───────────┘A.8 Technological Controls
# A.8.1 — User Endpoint Devices
# MLOps-specific: GPU instances and Jupyter environments
Controls for Jupyter/Notebook environments:
- Ephemeral environments (auto-terminate after 8 hours idle)
- No persistent local storage (all data in managed storage)
- Network isolation (no direct internet access from notebooks)
- Pre-approved package list (prevent supply chain attacks)
- Automatic credential injection (no hardcoded secrets)
# A.8.3 — Information Access Restriction
# MLOps-specific: Model artifact access control
Model artifact access controls:
- S3 bucket policies restricting model access by IAM role
- Signed URLs with expiration for model downloads
- Encryption at rest with customer-managed KMS keys
- Access logging via CloudTrail for all model reads
# A.8.5 — Secure Authentication
# MLOps-specific: MLflow and serving endpoint authentication
Authentication controls:
- MLflow: OIDC integration with Okta/Azure AD (no local accounts)
- Model serving: mTLS between services, API keys for external access
- Training clusters: Kubernetes RBAC + pod security policies
- Container registry: Image signing with Cosign/Notary
# A.8.9 — Configuration Management
# MLOps-specific: Infrastructure-as-code for ML platform
Configuration management:
- All infrastructure defined in Terraform (no manual changes)
- Git-controlled Kubernetes manifests (ArgoCD for GitOps)
- Immutable container images (no runtime modifications)
- Drift detection (alert on manual infrastructure changes)
# A.8.12 — Data Leakage Prevention
# MLOps-specific: Prevent training data and model leakage
DLP controls for ML:
- VPC endpoints for S3 (no data traverses public internet)
- Network policies preventing cross-namespace data access
- Egress filtering on GPU instances (whitelist allowed domains)
- Model output scanning for PII before API response
- Training data watermarking for forensic tracing
# A.8.15 — Logging
# MLOps-specific: Comprehensive ML audit logging
Audit log requirements:
- All MLflow API calls (experiment creation, model registration, stage transitions)
- All model serving requests (input hash, output, latency, model version)
- All training job submissions (submitter, data source, hyperparameters)
- All infrastructure changes (Terraform apply, Kubernetes deployments)
- Retention: 2 years for compliance, 90 days hot storage for investigationsA.8.24 — Use of Cryptography
# Cryptographic controls for ML platform
# Model integrity verification
- Sign all model artifacts with Cosign before registry upload
- Verify signatures before deployment
- Hash chain: training data hash → model hash → deployment hash
# Encryption requirements
- At rest: AES-256 for all model artifacts, training data, experiment logs
- In transit: TLS 1.3 for all API communications
- Key management: AWS KMS / GCP KMS with automatic rotation
# Implementation example: Model signing
# cosign sign --key awskms:///alias/ml-signing-key \
# registry.company.com/models/churn-predictor:v42
# Verification before deployment:
# cosign verify --key awskms:///alias/ml-signing-key \
# registry.company.com/models/churn-predictor:v42Phase 3: Risk Assessment
ML-Specific Risk Register
# isms/risk_register.yaml — ML-specific information security risks
risks:
- id: ML-R001
name: Training Data Exfiltration
description: >
Unauthorized access to training datasets containing PII
via compromised Jupyter notebook or misconfigured S3 bucket.
likelihood: Medium
impact: High
risk_score: 15
controls:
- S3 bucket policies with least-privilege access
- VPC endpoints (no public internet access to data)
- Data classification and encryption at rest
- Access logging and anomaly detection
- id: ML-R002
name: Model Poisoning
description: >
Adversary injects malicious data into training pipeline,
causing model to make incorrect predictions in production.
likelihood: Low
impact: Critical
risk_score: 12
controls:
- Data validation in pipeline (schema, distribution checks)
- Training data provenance tracking
- Model evaluation gates before production deployment
- Anomaly detection on training data distributions
- id: ML-R003
name: Model Extraction Attack
description: >
Adversary systematically queries inference API to reconstruct
model weights or decision boundary.
likelihood: Medium
impact: Medium
risk_score: 10
controls:
- Rate limiting on inference API
- API authentication and authorization
- Output perturbation (differential privacy)
- Monitoring for systematic querying patterns
- id: ML-R004
name: Credential Exposure in Experiment Logs
description: >
Data scientist accidentally logs API keys, database passwords,
or cloud credentials to MLflow experiment tracking.
likelihood: High
impact: High
risk_score: 20
controls:
- Secret scanning in experiment logs
- Environment variable injection (no secrets in code)
- Vault integration for credential management
- Automated credential rotation
- id: ML-R005
name: Unauthorized Model Deployment
description: >
Model promoted to production without proper review,
introducing bias, security vulnerability, or accuracy regression.
likelihood: Medium
impact: High
risk_score: 15
controls:
- Model registry stage transitions require approval
- Automated evaluation gates (accuracy, fairness, security scans)
- Deployment approval workflow
- Rollback capability within 5 minutesPhase 4: Implementation Checklist
Pre-Audit Readiness
# isms/audit_checklist.md — Pre-audit checklist for MLOps ISO 27001
## Access Control
- [ ] All ML platform access via SSO (no local accounts)
- [ ] MFA enabled for all platform users
- [ ] RBAC implemented for MLflow (viewer, editor, admin)
- [ ] Service accounts have minimum required permissions
- [ ] Access reviews conducted quarterly
- [ ] Departed employees' access revoked within 24 hours
## Data Security
- [ ] Training data classified (public, internal, confidential, restricted)
- [ ] PII identified and documented in all training datasets
- [ ] Encryption at rest for all model artifacts and training data
- [ ] Encryption in transit (TLS 1.3) for all API communications
- [ ] Data retention policy defined and enforced
- [ ] Backup and recovery tested quarterly
## Network Security
- [ ] GPU clusters in private subnets (no public IP)
- [ ] VPC endpoints for S3, ECR, CloudWatch
- [ ] Network policies preventing cross-namespace access
- [ ] Egress filtering on all ML workloads
- [ ] WAF on inference API endpoints
## Monitoring and Logging
- [ ] All MLflow API calls logged
- [ ] All model serving requests logged
- [ ] All training jobs logged with data provenance
- [ ] Log retention: 2 years minimum
- [ ] Alerting on anomalous access patterns
- [ ] SIEM integration for security event correlation
## Incident Response
- [ ] ML-specific incident response runbooks documented
- [ ] Runbooks tested quarterly via tabletop exercises
- [ ] On-call rotation defined for ML platform security incidents
- [ ] Communication plan for data breach involving training data
## Supply Chain Security
- [ ] Container images scanned for vulnerabilities (Trivy)
- [ ] Python dependencies scanned (pip-audit, safety)
- [ ] Base images from trusted registries only
- [ ] Image signing with Cosign
- [ ] SBOM generated for all deployed containersConclusion
ISO 27001 certification for MLOps platforms requires mapping the standard's Annex A controls to ML-specific implementations. The key differences from traditional software ISMS are: model artifacts as sensitive data (they encode training data), experiment tracking as an audit target, GPU clusters as high-value compute resources requiring network isolation, and inference APIs as attack surfaces for model extraction. The risk register must include ML-specific threats: data poisoning, model extraction, training data exfiltration, and credential exposure in experiment logs. Teams that approach ISO 27001 as an architecture exercise—building controls into the platform rather than bolting them on—achieve certification faster and maintain compliance with less ongoing effort.
