TISAX Cloud Requirements for Automotive Providers

Automotive cloud workloads often hold information competitors, criminals and supply-chain partners want most. Vehicle designs, prototypes, manufacturing data, customer information and other intellectual property all need robust protection.

Understanding TISAX cloud requirements is essential when an OEM or supplier expects formal evidence of information security and customer compliance requirements. Although often described as TISAX certification, TISAX is not a certification issued by ENX.

The starting point is a clear scope, documented ownership of controls, defined information security objectives and evidence that security measures operate in practice.

What TISAX Means for Automotive Cloud Providers

TISAX, or Trusted Information Security Assessment Exchange, is an automotive information security assessment and exchange framework for the automotive industry. It was developed in connection with the VDA and is governed by the ENX Association. The official TISAX overview confirms that it is an assessment and exchange mechanism, not a TISAX certification or certificate issued by ENX.

TISAX is built for supply-chain assurance

Automotive organisations often work with many suppliers, engineering partners and service providers. Repeating detailed security audits for every relationship is expensive and difficult to manage.

TISAX allows an assessed organisation to share results with several approved partners through the ENX Portal. This reduces duplicated due diligence, but customers must still evaluate the provider’s relevant security posture against their own compliance requirements.

VDA ISA and ISO/IEC 27001 provide the foundation

The VDA Information Security Assessment catalogue, known as VDA ISA, forms the basis of every assessment. It draws on established information security management principles, including ISO/IEC 27001, while applying them to automotive risks.

The VDA ISA assessment catalogue addresses governance, risk management, access control, operational security and supplier relationships. An ISO/IEC 27001-aligned information security management system (ISMS) provides a strong foundation, but certification to that standard or the system itself does not automatically satisfy every TISAX expectation. VDA ISA objectives, scope, protection needs and automotive supplier relationships still require assessment.

Shared Responsibility for Automotive Cloud Services

TISAX cloud requirements apply to the services and locations included within the defined assessment. Automotive customers remain responsible for how they configure, manage and use those services.

Define the assessed scope before selecting controls

Before a TISAX assessment, define the assessment scope clearly. It should name the legal entity, offices, data centres, service operations, systems and processes involved. It should also identify where automotive information is stored, processed, transmitted or administered.

For example, a managed provider may include its UK service desk, infrastructure operations team, privileged access platform and selected hosting environment. It may exclude development systems containing no automotive data. A provider using Google Cloud must also distinguish the platform's responsibilities and documentation from its own managed service and the customer's workload.

  A provider's TISAX result only supports the exact scope assessed. It cannot be treated as proof that every cloud service, region or subcontractor has been assessed.  

Split responsibilities in practical terms

The division of responsibilities depends on the service model, contract and customer compliance requirements. It should be documented rather than assumed, with information security objectives aligned to the customer's data and contractual needs.

The provider may operate physical site security, core infrastructure, identity services, patching and monitoring. The automotive customer may manage tenant configuration, workload access, encryption keys, data classification and application security. Managed arrangements often sit between these positions.

Both parties need evidence that their own controls are defined, implemented and reviewed. Clear boundaries help each side understand its obligations and support consistent assurance.

Protection Levels and When Assessment Level 3 Is Needed

Assessment objectives and protection requirements determine the required level under TISAX. Automotive customers usually specify these expectations through contracts, procurement requirements or project compliance requirements. The relevant information security objectives also influence the assessment scope.

AL2 and AL3 are not interchangeable

Assessment Level 2, or AL2, applies to objectives such as high information protection, confidential information and high availability. It includes self-assessment and plausibility checks by an approved audit provider.

Assessment level 3, or AL3, involves more comprehensive verification. The audit provider uses the self-assessment and evidence for preparation, then verifies applicable controls through detailed interviews and site inspection. The TISAX Participant Handbook sets out how scope, assessment and sharing activities are managed.

High-risk automotive information may require AL3

AL3 may be required for highly sensitive information, strictly confidential information, special data or very high availability. It may also apply where heightened prototype protection is needed, including for prototype parts, vehicles, test vehicles or prototype events.

AL3 isn't triggered by a data label alone. The customer, contractual requirements and actual processing activities determine its relevance. A system supporting confidential engineering files may need a different assessment objective from a tenant handling special-category personal data.

Core Security Controls for Cloud Service Providers

The controls expected under TISAX extend well beyond firewall settings or a security policy. They require an operating model that protects information throughout its lifecycle.

Identity, access and technical protection

Security measures should cover privileged access, role-based permissions, multi-factor authentication, joiner and leaver controls, access reviews and secure administration methods.

Technical evidence may include configuration standards, vulnerability management records, logging, monitoring alerts, back-up restoration tests and change approvals. Encryption should cover data in transit and at rest where appropriate, supported by clear key and secret management processes. Evidence from Google Cloud or another hyperscaler may support infrastructure assurance, but it doesn't prove that the provider configured or operated every control for its own service. Records should distinguish inherited platform controls from those operated by the provider.

Incident response, continuity and physical security

An incident response plan must identify roles, escalation routes, investigation records, containment steps and customer notification procedures. Teams should test the plan, including responses to data breaches, and record lessons from exercises or real incidents.

Business continuity arrangements need to reflect the services in scope. Recovery objectives, restoration tests, supplier dependencies and communications plans all matter. For data centre operations, evidence may include physical access controls, visitor management, environmental protections and security monitoring.

Data protection also requires attention. The assessment supports strong information security practices, but it doesn't by itself demonstrate GDPR compliance. Cloud providers should assess data processing responsibilities, customer obligations and contractual compliance requirements separately.

Managing Third Parties and Subcontractors

Automotive customers will ask difficult questions about the organisations behind the service. Hosting partners, support providers, software vendors and specialist contractors must be governed through effective supply chain management, as each can affect the assessed scope.

Build supplier security into procurement and oversight

A cloud provider needs due diligence before onboarding a supplier that can access systems or sensitive information. Contracts should reflect contractual and customer compliance requirements, including security obligations, confidentiality terms, incident reporting expectations, audit rights and subcontractor controls.

Ongoing oversight is equally important. Review certifications, assurance reports, third party audits, performance, security incidents and material changes to subcontracted services. These factors can affect the provider’s overall security posture. This supplier information security guidance can help organisations ask more structured questions when evaluating third parties.

Keep subcontractor evidence current

A contract alone isn’t enough. During a TISAX assessment, auditors may expect records showing which suppliers are critical, what information they handle and how risks are assessed.

Maintain a critical-supplier register that links key subcontractors to services, data types and owners. Keep data and service mappings, due-diligence records, review dates, security findings, risk treatment decisions and management approvals up to date. If Google Cloud or a specialist platform sits outside the provider’s direct control, its documentation may support evidence for the infrastructure it covers, but doesn’t automatically prove compliance for the provider’s managed service, subcontractors or customer tenant. Document outsourced infrastructure as a dependency, including the assurance evidence available and any known customer-facing limitations.

Preparing for a TISAX Assessment

Preparation works best when treated as an improvement programme, not a last-minute document exercise. Start with an honest gap analysis against the relevant VDA ISA catalogue objectives.

Turn the self-assessment into usable evidence

The self-assessment should reflect what the organisation does today. Unsupported maturity claims create problems later, particularly at AL3.

Begin by confirming the assessment scope, including entities, locations, remote working, cloud dependencies and third parties. Identify the applicable information security objectives and protection levels.

Map each objective to an owner and evidence item, including customer and project compliance requirements. Useful evidence includes risk assessments, information classification rules, training records, internal audit findings, management review minutes and corrective action records.

Cloud-specific evidence may include tenant configuration records, responsibility matrices, privileged-access reviews, provider assurance documents, service-location records, monitoring outputs and restoration tests. Test the relevant controls before the assessment.

Policies matter, but auditors also need proof that staff follow them. A periodic access review or restored back-up test is stronger evidence than a policy statement alone.

Work constructively with the approved audit provider

An approved TISAX audit provider assesses the defined scope and relevant objectives. Engage the audit provider early to confirm the scope, locations, remote working arrangements, cloud dependencies and third parties.

Internal audit and management review should take place before the external assessment. Any non-conformities need ownership, dated corrective actions and evidence of completion. Organisations needing structured support can use TISAX audit preparation specialists to assess readiness and organise evidence.

ENX has also announced changes around ISA6. Its TISAX downloads and transition information states that initial assessments under ISA6 must be opened by March 2027. Providers planning assessments should confirm the applicable catalogue and timing with their audit provider.

Using the ENX Portal to Share Results

A successful assessment has value when the right partner can verify it quickly. The ENX Portal provides controlled infrastructure for sharing assessment results with authorised participants.

Before sharing, check that the TISAX scope status is active and covers the specific cloud services your customer will use. A result from a different country, legal entity or data centre may not satisfy service-specific compliance requirements.

The assessment results guidance explains the controlled sharing process. Don’t circulate audit reports widely by email. Use the portal permissions and agree the required labels with each customer.

Microsoft Azure publishes TISAX compliance documentation, while Google Cloud provides its own provider documentation. These resources support due diligence, but they don’t extend a TISAX result to every cloud workload. Customers must still assess tenant configuration, workload security, operating responsibilities and subcontractors.

Key Takeaways

• TISAX is an automotive assessment and exchange framework, not a conventional certification issued by ENX.

• The VDA ISA catalogue provides the assessment foundation, with ISO/IEC 27001 offering an important management system base.

• Scope is decisive. It must cover the relevant entities, locations, cloud services, processes and subcontractors.

• Assessment level 3 (AL3) is appropriate for objectives involving highly sensitive information, prototypes, special data or very high availability.

• Accurate TISAX results depend on defined information security objectives, the applicable protection level and evidence that controls operate in practice.

• Data protection and GDPR compliance remain separate responsibilities, while provider assurance supports, but doesn't replace, the automotive customer's security duties.

Frequently Asked Questions

Can a cloud provider use a hyperscaler's TISAX result?

A hyperscaler's assessment result can provide supporting assurance for the infrastructure it covers. Evidence from a platform provider cannot automatically cover a managed service or the customer's workload. Each organisation must assess its own responsibilities, scope, controls and dependencies.

What happens if a TISAX scope is no longer active?

An inactive scope may not meet a customer's supplier assurance requirements. It can delay onboarding, lead to additional due diligence and affect contract opportunities. Review scope status before sharing results and before relying on a supplier's assessment.

Is TISAX certification the same as ISO/IEC 27001 certification?

No. TISAX is not a certification; it is an assessment and exchange framework. GDPR obligations depend on the organisation's processing activities and legal role. ISO 27001 is a broader information security management standard, although its risk-based approach supports preparation.

Building Trust Through Clear Cloud Assurance

The strongest response is a well-defined TISAX scope, supported by evidence and accountable owners. It should include tested access, monitoring, continuity and supplier security measures. Cloud providers must show how their defined service protects automotive information against applicable information security objectives. Customers must manage controls that remain within their own environments.

A mature TISAX programme is not just a compliance checkbox. Clear ownership and tested controls give automotive partners a more reliable view of a provider’s security posture.

If you would like to find out more information or require any of our services please Contact Us and complete our contact form.