TISAX Cloud Readiness Checklist
30 actionable controls for automotive suppliers preparing for TISAX Level 2 in cloud environments. Aligned with VDA ISA 6.0. Use this checklist to identify gaps before your assessment and prioritize remediation work.
How to Use This Checklist
Work through each domain before your TISAX assessment. Controls marked Critical are the most common source of "must-fix" findings in automotive cloud environments — address these first. The VDA ISA reference tells you which part of the assessment questionnaire each control maps to. Share this checklist with your cloud team and information security manager.
Identity & Access Management
VDA ISA 5.1 / 5.2
Multi-factor authentication (MFA) is enforced for all administrative access to cloud management consoles (AWS Console, Azure Portal, GCP Cloud Console).
Implementation Guidance
Conditional Access policies or IAM permission boundaries. Service accounts must not be used for interactive login.
Privileged access to cloud resources follows a just-in-time (JIT) or time-limited model — no standing admin permissions.
Implementation Guidance
Azure PIM, AWS IAM Identity Center with permission sets, or equivalent. Audit log of all JIT activations required.
A documented joiner/mover/leaver process covers cloud access provisioning and deprovisioning within defined SLAs.
Implementation Guidance
Deprovisioning SLA: ≤24 hours for leavers; ≤5 business days for role changes.
Service accounts and workload identities are inventoried, assigned owners, and reviewed quarterly.
Implementation Guidance
Orphaned service accounts (no owner, no recent use) are a common audit finding. Automate detection with cloud-native tooling.
Access reviews for OEM-data-handling systems are conducted at least every six months and results are documented.
Implementation Guidance
Results must be retained for the TISAX assessment period. Recertification by line manager is the minimum standard.
Data Classification & Encryption
VDA ISA 5.3 / 5.4
All storage containing OEM-classified data (confidential or above) has encryption at rest enabled with customer-managed keys (CMK).
Implementation Guidance
Cloud provider default encryption (SSE with provider-managed keys) does not satisfy TISAX requirements for confidential data. CMK with HSM-backed key storage required.
All data in transit between on-premises systems and cloud environments uses TLS 1.2 or above.
Implementation Guidance
TLS 1.0 and 1.1 must be explicitly disabled. Document cipher suites in your network security baseline.
A data classification policy exists and is applied to all cloud storage buckets, databases, and file shares.
Implementation Guidance
Classification labels: Public, Internal, Confidential, Strictly Confidential. OEM data is typically Confidential minimum.
Key management procedures document key rotation schedules, key custodians, and emergency key access procedures.
Implementation Guidance
Key rotation: at least annually. Emergency access: documented break-glass procedure with audit trail.
Network Security & Segmentation
VDA ISA 5.5
Cloud environments hosting OEM data are network-segmented from general corporate workloads using dedicated VPCs/VNets with restrictive security group rules.
Implementation Guidance
Default-deny ingress policy. Only required ports and protocols permitted. OEM data segments must not be directly reachable from internet-facing DMZ.
Cloud workload firewall rules are defined as code (Infrastructure as Code) and reviewed before deployment.
Implementation Guidance
Terraform or Bicep templates with automated policy checks (e.g., checkov, tfsec) before apply.
External-facing endpoints (APIs, file transfer portals) are protected by a Web Application Firewall.
Implementation Guidance
AWS WAF, Azure WAF, or equivalent. OWASP Top 10 rule set as baseline.
VPN or dedicated connectivity (ExpressRoute, Direct Connect) is used for on-premises to cloud traffic carrying OEM-classified data — not public internet.
Implementation Guidance
Public internet with TLS is not sufficient for confidential OEM data in transit. Dedicated or private network path required.
Vulnerability & Patch Management
VDA ISA 5.6
A documented patching SLA is defined and monitored: Critical ≤5 business days, High ≤30 days, Medium ≤90 days.
Implementation Guidance
Cloud-native tooling: AWS Systems Manager Patch Manager, Azure Update Manager. Dashboard visibility required for auditor evidence.
Container images used in cloud workloads are scanned for vulnerabilities at build time and before deployment to production.
Implementation Guidance
Trivy, Snyk, or equivalent. Critical CVEs block deployment. Results retained as evidence.
Cloud infrastructure is scanned using a cloud security posture management (CSPM) tool at least weekly.
Implementation Guidance
Microsoft Defender for Cloud, AWS Security Hub, or equivalent. Findings tracked to remediation.
Incident Detection & Response
VDA ISA 5.7
A documented information security incident response procedure exists, covers cloud-hosted systems, and has been tested within the last 12 months.
Implementation Guidance
Tabletop exercise minimum. Live drill preferred. Test must cover: detection → triage → OEM notification → post-incident review. Documentation of test results required.
Cloud audit logs (CloudTrail, Azure Monitor, GCP Audit Logs) are centrally collected, tamper-protected, and retained for a minimum of 12 months.
Implementation Guidance
Log forwarding to immutable storage (S3 with Object Lock, Azure Storage with immutability policy). Retention ≥12 months for TISAX; 24 months recommended.
Alerting is configured for high-risk events: impossible travel logins, mass download from OEM data repositories, privilege escalation attempts, and security group changes.
Implementation Guidance
SIEM integration or cloud-native alerting. Response runbooks for each alert type.
OEM customer notification obligations for security incidents are documented and the relevant OEM contacts are maintained in the incident response procedure.
Implementation Guidance
Most OEM supply agreements specify a notification window (commonly 24–72 hours). This must be reflected in your procedure.
Third-Party & Supply Chain Risk
VDA ISA 5.8
All sub-suppliers and partners with access to OEM-classified data have been formally assessed for information security compliance within the last 24 months.
Implementation Guidance
VDA ISA questionnaire or equivalent. Assessment method and results must be documented. For lower-risk sub-suppliers, a self-assessment questionnaire backed by contractual obligations is acceptable.
Contracts with sub-suppliers handling OEM-classified data include information security clauses that mirror the OEM's data protection requirements.
Implementation Guidance
Minimum clauses: data classification obligations, breach notification, right-to-audit, and data deletion on contract end.
Access of sub-suppliers to cloud systems hosting OEM data is provisioned with least-privilege principles and reviewed annually.
Implementation Guidance
External identities should use federated or time-limited credentials, not shared passwords.
Cloud Configuration Baseline
VDA ISA 5.5 / 5.6
A cloud security baseline is documented and enforced via policy-as-code (AWS Service Control Policies, Azure Policy, GCP Organization Policy).
Implementation Guidance
Baseline should cover: enabled regions, allowed VM sizes, required tags, mandatory encryption settings, prohibited public access configurations.
Public access to storage buckets, blob containers, and databases is blocked at the organization/management-group level.
Implementation Guidance
AWS S3 Block Public Access, Azure Storage Account public access disabled at policy level. No exceptions without documented risk acceptance.
Unused cloud resources (unattached disks, orphaned snapshots, idle VMs) are identified and decommissioned on a regular schedule.
Implementation Guidance
Monthly automated sweep. Orphaned resources are a security and cost risk.
Cloud resource configurations are auditable: changes tracked in version control and deployed via CI/CD pipeline, not manual console changes.
Implementation Guidance
GitOps model for infrastructure changes. Manual changes blocked via SCPs/Azure Policy in production environments.
Business Continuity & Recovery
VDA ISA 5.9
Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are defined for all cloud systems processing OEM-classified data.
Implementation Guidance
RTOs should be aligned with contractual obligations to OEM customers. Document the business impact of downtime.
Backups of OEM-data systems are tested (restore tested, not just backup-to-disk confirmed) at least annually.
Implementation Guidance
A backup that has never been restored is not a backup for TISAX purposes. Restore test results must be documented.
Backups are stored in a geographically separate region from the primary workload and are not accessible from the primary environment with the same credentials.
Implementation Guidance
Immutable backups (S3 Object Lock, Azure Backup with soft delete) protect against ransomware scenarios.
About This Checklist
This checklist was developed by the Apex Cloud Consulting security practice based on our experience supporting automotive suppliers through TISAX Level 1, 2, and 3 assessments. It reflects the most common cloud-specific findings we see in VDA ISA assessments for suppliers operating on AWS, Azure, and GCP.
This checklist is aligned with VDA ISA 6.0, the current version of the assessment questionnaire as of May 2026. TISAX assessments are conducted by ENX-accredited audit providers — this checklist is a preparation tool, not a substitute for a formal assessment.
Controls are not exhaustive. Depending on your scope (e.g., prototype protection, connected vehicle data), additional VDA ISA domains may apply. We recommend combining this checklist with a full VDA ISA gap analysis before your formal assessment.
Ready to Start Your TISAX Preparation?
Our TISAX specialists can run a gap assessment against this checklist and build you a prioritized remediation roadmap within two weeks.