What TISAX Actually Requires Before You Move Production Workloads to AWS, GCP, or Azure
TISAX does not certify clouds - it certifies you. Here is exactly what an automotive supplier must prove about assessment level, prototype protection, data location, and third-party control before production workloads run on AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster.
TISAX assesses the supplier, not the cloud. The ENX Association runs TISAX as an exchange of assessment results for your organization against the VDA ISA catalogue. AWS, Azure, and Google Cloud hold their own TISAX labels for their regions, but those labels describe the provider and never transfer to you.
A hyperscaler move changes where controls live, never whether you owe them. Data classification, IAM, key management, environment separation, logging, change management, backup and restore, and supplier due diligence all stay in your scope.
Your assessment objectives set the assessment level. "Strictly confidential", "Very high availability", "Proto parts", "Proto vehicles", and "Special data" require AL 3, which means an audit provider on site. "Confidential", "Test vehicles", "Proto events", and "Data" require AL 2 (ENX TISAX Participant Handbook).
The blockers are concrete: a documented region and processing location, encryption with controlled keys, least-privilege IAM with recorded access reviews, separation between prototype, production, and non-production, retained audit logs, a tested restore, and a GDPR Article 28 processor chain covering every tool in the path.
Keep the cloud account, data, keys, and logs in your own name. A BYOC platform such as Qovery runs on your own AWS, GCP, Azure, or Scaleway account, or on an existing Kubernetes cluster. Data location stays your decision. With a vendor's tenancy, it becomes theirs.
I keep having the same conversation with engineering leaders at automotive suppliers. They moved production to Frankfurt, Paris, or another EU region, pointed the auditor at the provider's compliance page, and expected the TISAX assessment to go smoothly. Then the audit provider asked for their access review records, their key custody documentation, and the list of everyone who could deploy to production. The provider's compliance page answered none of it.
TISAX assesses the supplier, not the cloud. There is no TISAX-certified AWS region that covers you, and moving to a hyperscaler changes where your controls are implemented, not whether you owe them. Here is what you actually have to prove, in the order I would tackle it in 2026.
Does TISAX certify the cloud, or does it certify you?
TISAX assesses your organization's information security against the VDA ISA catalogue, and the resulting label belongs to you alone. A cloud provider's own TISAX label, ISO/IEC 27001 certificate, or BSI C5 attestation covers the provider's side of the shared responsibility model and removes zero controls from your scope.
ENX describes TISAX as "a shared framework for assessments and recognition across the industry", based on the ISA catalogue "maintained by the ENX Association and published by the VDA" (ENX). Independent, ENX-approved audit providers perform the assessments. ENX does not.
Get the vocabulary right, because auditors and OEMs will: you receive TISAX labels matching your assessment objectives, at a given assessment level (AL). Results are not published as a public certificate. You share them with partners through the ENX portal, and "if you don't publish your assessment result or don't share it, no one can see your assessment result" (ENX Participant Handbook).
The hyperscalers do participate. AWS reports an AL3 assessment of 19 regions including Frankfurt, Ireland, Paris, and Milan (AWS TISAX). Microsoft lists Azure regions verified for AL3 with the data protection module (Microsoft Learn). Google Cloud holds "Strictly Confidential", "Very High Availability", and "Information with Very High Protection Needs" labels for its regions (Google Cloud TISAX).
Those labels tell your OEM the data center underneath you is sound. They say nothing about your IAM, your data classification, or your deployment process. When an OEM asks for TISAX, it looks up your label, objectives, and level in the ENX exchange.
ISO/IEC 27001 is a strong head start, since Microsoft notes the VDA ISA is based on ISO/IEC 27001 and 27002 adapted to the automotive industry (Microsoft Learn). It does not cover prototype protection or the automotive-specific objectives, so it never replaces the label.
Which TISAX assessment level and labels apply to production workloads in the cloud?
Your OEM's required assessment objectives decide the level: "Confidential", "High availability", "Test vehicles", "Proto events", and "Data" need AL 2, while "Strictly confidential", "Very high availability", "Proto parts", "Proto vehicles", and "Special data" need AL 3 (ENX Participant Handbook). Agree the objectives with the OEM before you design any architecture.
The objective names changed recently. "Info high" and "Info very high" could only be selected until 31 March 2024, and "Confidential" and "Strictly confidential" replaced them from 1 April 2024 (same source). If your procurement contract still says "Info very high", ask the OEM which current objective they expect.
Assessment level
How the audit provider verifies
Typical trigger
Evidence depth
What it means for a cloud setup
AL 1
Checks that a self-assessment exists, without assessing its content
Not used in TISAX, per the ENX handbook
None beyond the self-assessment
Irrelevant for OEM data
AL 2
Plausibility check of your self-assessment, interviews generally via web conference, on-site only at your request
Confidential, High availability, Test vehicles, Proto events, Data
Documents and samples for every location in scope
Exports and screenshots of IAM, encryption, logs, and change records must stand up remotely
AL 2 (full remote variant, "AL 2.5")
Full remote assessment instead of a plausibility check, formally still AL 2
Same objectives as AL 2, when you or partners want more assurance
Deeper than a plausibility check
Expect the auditor to walk live consoles with you
AL 3
Comprehensive verification of compliance, and the audit provider must come to your location(s)
Strictly confidential, Very high availability, Proto parts, Proto vehicles, Special data
Full verification with on-site inspection
Every control must be demonstrable live, including key custody, access reviews, and network separation
All rows are summarized from the ENX Participant Handbook, which also states that higher levels always include lower ones.
Prototype protection reshapes architecture more than anything else. Pre-series data needs demonstrable separation from series workloads, tightly restricted and reviewed access, and controlled handling of media and devices. In practice that means separate accounts or projects, separate clusters, and separate access groups.
Scope is the next trap. TISAX uses a predefined standard scope covering "all processes, procedures and resources under responsibility of the assessed organization" that are relevant to the protected objects, and other participants only accept results based on it (same source). Every cloud account, cluster, CI system, and SaaS tool touching OEM data falls inside.
A label is valid for three years. Renewal requires creating a new scope, even if it is identical to the current one (ENX Participant Handbook).
Check the catalogue version too. ENX lists ISA 6.0.3 as the current catalogue, and the VDA published ISA2027 in July 2026 as the basis for assessments ordered in 2027 (ENX downloads). Confirm which version applies to your assessment on enx.com before you write a single policy.
The order that works: assessment objectives, then scope, then architecture, then evidence plan.
What controls does VDA ISA actually ask you to evidence for a cloud environment?
For a cloud environment, VDA ISA comes down to a concrete evidence list: classified assets and data, least-privilege identity with recorded reviews, encryption with controlled keys, separated networks and environments, retained audit logs, tested backups, a documented change process, patched clusters, an incident process with OEM notification, and due diligence on every third party in the chain.
I am not going to quote control numbers here, because they shift between ISA 6 and ISA2027. Map against the catalogue version your assessment uses. The control areas below hold steady across both.
Control area
What the auditor asks to see
Where it lives in AWS / GCP / Azure / Scaleway / self-managed Kubernetes
Evidence artifact you hand over
Asset and information classification
Which repos, buckets, databases, clusters, and environments hold OEM or prototype data
Resource tags and labels, AWS Organizations / GCP folders / Azure management groups / Scaleway projects, Kubernetes namespaces
Asset inventory export plus your tagging convention
Identity and access
Least privilege, MFA, no shared admin accounts, joiner-mover-leaver records
AWS IAM Identity Center, Google Cloud IAM, Microsoft Entra ID, Scaleway IAM, Kubernetes RBAC
IAM policy export, MFA enforcement report, signed periodic access reviews
Cryptography and key management
Encryption at rest and in transit, key custody, rotation
The findings I hear about most often come from operations: change approval nobody documented, a backup job that was never restored, and clusters running a Kubernetes version past end of support. Each one is cheap to fix before the audit and painful to fix during it.
Who is responsible for what once production runs on a hyperscaler?
The provider is responsible for the physical facilities, hardware, network, and virtualization layer, and its attestations evidence that. Everything you configure on top, from data classification and IAM to keys, network design, node patching, logging, and the deployment workflow, is yours to implement and evidence, so for TISAX the split lands overwhelmingly on your side.
AWS draws the line as "Security of the Cloud" for AWS and "Security in the Cloud" for the customer (AWS Shared Responsibility Model). Microsoft is blunter: regardless of deployment type, "you're responsible for your data, including data classification, data protection, encryption decisions, and compliance with data governance requirements" (Microsoft Learn).
The same logic applies to C5. Microsoft states you "need to achieve your own C5 attestation for components outside or built on top of these services" (Microsoft C5). AWS and Google Cloud also publish C5 attestations (AWS C5, Google Cloud C5). Collect them, plus ISO/IEC 27001 certificates and SOC 2 reports, as supplier due diligence artifacts.
That due diligence is mandatory. The ENX handbook says you "still have to check for all of your suppliers whether using their services increases risks or introduces new risks", and TISAX labels are one way a supplier can prove it meets your bar (ENX Participant Handbook).
Managed Kubernetes is where auditors catch people. EKS, GKE, and AKS run the control plane, but node images, version upgrades, admission policy, network policy, and workload isolation stay with you. Upstream Kubernetes supports each minor release for roughly 14 months (kubernetes.io). EKS gives 14 months of standard support, then 12 months of extended support at an additional cost per cluster hour (Amazon EKS docs). Skip two upgrade cycles and you have an easy finding.
Data location needs paperwork. If OEM data includes personal data, GDPR Article 28 requires you to "use only processors providing sufficient guarantees to implement appropriate technical and organisational measures" (GDPR Art. 28). Article 32 names "the pseudonymisation and encryption of personal data" and regular testing of those measures (GDPR Art. 32). Data protection is one TISAX objective family among several, so GDPR answers only part of the assessment.
When the OEM pushes harder on location, each provider now has a lever:
AWS European Sovereign Cloud reached general availability on 15 January 2026 with a first region in Brandenburg, Germany, "operated exclusively by EU residents" (Amazon press release).
Microsoft EU Data Boundary was completed in February 2025 for Microsoft 365, Dynamics 365, Power Platform, and most Azure services (Microsoft).
Google Cloud offers Google Cloud Data Boundary for residency and access controls on its public cloud, plus partner-operated Google Cloud Dedicated, delivered in Europe with Thales (Google Cloud sovereign cloud).
Scaleway is a European provider headquartered in France, which some OEMs prefer when they ask about jurisdiction (Scaleway).
My rule for all of this: if you cannot show the auditor a screenshot or an export proving a control, you do not have that control.
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster. Start deploying in under 10 minutes.
Why does the internal developer platform choice decide half of your TISAX evidence?
Most of what an auditor checks, such as who can deploy to production, where secrets live, whether prototype data can reach a preview environment, and how long deployment logs are kept, is decided by the platform layer on top of the cloud. Picking a SaaS PaaS, a BYOC platform, or a DIY stack decides which of those controls you implement and evidence by hand.
With a SaaS PaaS, your code and often your data run in the vendor's tenancy. The vendor becomes a processor inside your scope, data location becomes their decision, and their logs are the only audit trail you can offer.
With BYOC, the cloud account, VPC, keys, data, and logs stay in your name, inside infrastructure you already declared in scope. The platform orchestrates instead of hosting.
DIY Kubernetes with Terraform and Backstage is a legitimate, fully TISAX-compatible route with maximum control. It works well for teams with a platform function. It struggles for teams without one, because someone has to evidence cluster patching, upgrade history, RBAC hygiene, and on-call every single year of the label.
Model
Who holds the cloud account
Where data and keys live
Who patches the cluster
Who owns the audit log
Data-residency control
Team needed to run it
TISAX scope impact
SaaS PaaS (Heroku, Vercel, Render, Platform.sh)
The vendor
The vendor's infrastructure, in regions they offer
The vendor
The vendor, exposed through their UI or API
Limited to the vendor's region list
Small
Vendor becomes an in-scope processor you must assess
You, in your account, plus the platform's deployment history
Full: you pick the region and provider
Small to medium
Platform control plane is a supplier to assess; workloads and data stay in your own scope
DIY Kubernetes with Terraform and Backstage
You
Your account, your KMS
Your platform team
You
Full
Dedicated platform team
No extra vendor, but every operational control is yours to evidence
No platform grants a label. A good one reduces how many controls you implement manually and keeps the evidence inside your own account.
What does a TISAX-ready cloud setup look like for a supplier with no dedicated DevOps team?
The pattern that works is one cloud account or project per environment in your own name, the region pinned to the jurisdiction your OEM requires, customer-managed keys, Kubernetes under the hood with upgrades handled for you, strict per-environment RBAC, a full deployment history, and no production or prototype data anywhere near preview environments.
Build it in this order:
Assessment objectives and scope, agreed with the OEM
Account and project structure, separating prototype, production, and non-production
Network separation and private endpoints
IAM and RBAC model per environment
Secrets and customer-managed key management
Log retention covering the assessment period
Backup policy plus a dated restore test
Documented change and release process with production approval
Supplier due diligence file
This is where Qovery fits. Qovery installs into your own AWS, GCP, Azure, or Scaleway account, or onto an existing Kubernetes cluster. The cloud contract, region, data, keys, and logs stay yours, and developers get git-push deployments without anyone on the team becoming a Kubernetes operator.
The capabilities map directly to control areas:
Per-environment RBAC supports access control and separation of duties.
Deployment history gives you a change-management and auditability record.
Managed cluster upgrades support patch and vulnerability management evidence.
Ephemeral preview environments per pull request, plus auto-stop keep non-production isolated and short-lived.
Databases backed by managed cloud services inherit your provider's backup and resilience features, in your account.
Keep previews out of the prototype conversation by seeding non-production with anonymised or synthetic data. Never use production dumps. That one rule keeps staging and preview environments from dragging the prototype protection objectives into places they do not belong.
What stays yours on any platform: writing the policies, classifying the data, running and recording access reviews, collecting provider attestations, and passing the assessment.
To be explicit: Qovery is not TISAX certified and does not make anyone TISAX compliant. The supplier earns the label.
How do I set this up from Claude Code or Cursor?
Install the Qovery Agent Skills once and a coding agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI) can scaffold deployments into your own cloud account. Pair them with the Qovery MCP Server, which is read-only by default, so every change in an assessment-scoped environment needs your explicit approval.
Add the MCP Server to Claude Code (OAuth, read-only by default, the right default for an audited environment):
BASH
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
Enable write access only when you want the agent to change things. This also requires enabling write access in the Qovery Console:
BASH
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242
The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) set things up. The MCP Server operates what already exists. Then ask in plain language, for example "deploy this service to our EU AWS account with a separate staging environment", and keep read-only MCP plus human approval for anything in assessment scope.
A cloud provider can hold its own TISAX labels, and AWS, Microsoft Azure, and Google Cloud all do for specific regions. Those labels cover the provider's infrastructure and do not transfer to your organization. Your OEM still needs your own label, at your own assessment level, shared through the ENX portal.
What is the difference between TISAX AL2 and AL3, and which one do I need for cloud workloads?
At AL 2, the audit provider runs a plausibility check of your self-assessment with interviews generally held by web conference. At AL 3, it comprehensively verifies compliance and must visit your location(s). Your assessment objectives decide the level: "Strictly confidential", "Proto parts", "Proto vehicles", "Very high availability", and "Special data" require AL 3 (ENX Participant Handbook).
Does TISAX require my data to stay in the EU?
TISAX itself does not mandate an EU region, but you must document where data is stored and processed and show that the risks are controlled. Many OEMs add EU residency requirements in their contracts, and GDPR adds transfer rules for personal data. Pin the region your OEM requires and record it in your scope documentation.
Is ISO 27001 enough, or do I still need TISAX for automotive customers?
ISO/IEC 27001 is not enough when an automotive OEM asks for TISAX, because the OEM checks for a TISAX label in the ENX exchange. A working ISO 27001 ISMS is a strong head start, since the VDA ISA builds on ISO/IEC 27001 and 27002. Prototype protection and other automotive-specific objectives still need a TISAX assessment.
Do preview, staging, and CI/CD environments fall inside the TISAX assessment scope?
They fall inside the scope whenever they are relevant to the security of protected data, because the TISAX standard scope covers all processes, procedures, and resources under your responsibility that touch it. CI/CD systems that deploy to production are almost always in scope. Seeding previews and staging with synthetic or anonymised data keeps them out of the prototype protection discussion.
How long does a TISAX label stay valid, and what happens if I change cloud architecture mid-cycle?
A TISAX label is valid for three years, and renewal requires a new scope (ENX Participant Handbook). If you change cloud architecture mid-cycle, your controls must keep working, and the new setup must keep meeting the catalogue requirements. Document the change, update your asset inventory and supplier file, and ask your audit provider or ENX whether it affects your current result.
Morgan co-founded Qovery and leads engineering. He writes about Kubernetes architecture, DevOps best practices, and building resilient infrastructure at scale.
Next step
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure, or Scaleway account - or your existing Kubernetes cluster. Start deploying in under 10 minutes.
