Supplier TISAX Assessment

“Supplier TISAX assessment” is a simple requirement to state and easy to fail in execution: you can’t claim strong information security for highly confidential automotive data if your supply chain can access that data without a comparable assurance mechanism. VDA ISA 4.1.2 expects you to require suppliers that handle highly confidential data to obtain their own TISAX assessment at an appropriate assessment level, aligned to the sensitivity and exposure created by the work they perform (VDA ISA Catalog v6.0).

For a Compliance Officer, CCO, or GRC lead, operationalizing this requirement means turning it into a repeatable intake-and-gating process: (1) classify the data and activities a supplier will perform, (2) map that classification to a required TISAX assessment level, (3) include the requirement in contracting and onboarding, (4) validate the supplier’s assessment before granting access, and (5) monitor changes (supplier scope changes, new systems, sub-processors) that might increase required rigor.

This page gives you requirement-level implementation guidance with practical steps, artifacts to retain, audit-ready language, and execution planning.

Regulatory text

Requirement (VDA ISA 4.1.2): “Require suppliers handling highly confidential data to obtain their own TISAX assessment at an appropriate assessment level.” (VDA ISA Catalog v6.0)

What the operator must do

• Identify suppliers (third parties) that handle highly confidential data. “Handle” includes storing, processing, transmitting, administering systems that contain the data, or having privileged access where the data could be accessed.
• Set an “appropriate assessment level.” Your requirement to the supplier must match the sensitivity of the automotive information and the exposure created by the supplier’s access and processing activities.
• Make it enforceable and verifiable. The requirement must be embedded in onboarding and contracting, and you must verify the supplier’s TISAX assessment status before you provide the supplier access to the data or environments.

Plain-English interpretation

If a supplier touches your most sensitive automotive information, you can’t rely on a lightweight questionnaire or a generic certification alone. You must require that supplier to go through TISAX themselves, at a level that fits the sensitivity of what they handle and the way they handle it (VDA ISA Catalog v6.0). Practically, this becomes a gate: no verified supplier TISAX assessment at the required level, no access to highly confidential data.

Who it applies to

Entity types

• Automotive suppliers and OEMs that share, outsource, or grant access to highly confidential or strictly confidential automotive information to third parties (VDA ISA Catalog v6.0).

Operational contexts that trigger the requirement

You should treat the requirement as in-scope when a supplier:

• Hosts or supports systems containing sensitive automotive data (cloud, SaaS, managed services).
• Performs engineering, testing, analytics, or support that requires access to sensitive product, prototype, or customer/vehicle data.
• Has admin-level access to networks, endpoints, identity systems, or tooling where sensitive automotive data is present.

What you actually need to do (step-by-step)

1) Define “highly confidential” for your environment (and make it usable)

Create a short, operational definition for teams. Tie it to your data classification policy or information type catalog. Include concrete examples (prototype CAD, vehicle security-relevant artifacts, customer-linked vehicle telemetry, incident details that reveal security controls). The key is consistent classification at intake so you can apply the right supplier requirement.

Output: Data classification criteria + examples that procurement/engineering can apply without interpretation battles.

2) Build a supplier intake that captures “handles highly confidential data” precisely

Add required fields to your third-party intake:

• Data types involved (pick list tied to classification)
• Access method (direct access, VPN, API, file transfer, admin access)
• Processing location (supplier environment, your environment, both)
• Sub-processors (does the supplier rely on other parties)
• Whether work requires production access or can be done with masked/synthetic data

Operator tip: Many teams miss “privileged access” suppliers (IT ops, IAM integrators). Treat privileged access as data exposure unless you can technically prove segmentation and least privilege.

Output: Completed intake record with a clear “handles highly confidential data: yes/no” decision and rationale.

3) Translate data sensitivity into a required TISAX assessment level (decision rule)

Document a rule that procurement and security can apply consistently:

• If the supplier handles highly confidential (or stricter) automotive data, require TISAX at an assessment level that matches that sensitivity and the scope of services (VDA ISA Catalog v6.0).
• If the supplier does not handle highly confidential data, document what assurance is acceptable instead (for example, internal assessment, contract controls). Keep this as a separate track so you don’t over-scope TISAX.

Because “appropriate assessment level” is context-dependent, your auditors will look for a defensible methodology more than a one-size-fits-all mapping. Your documentation should show:

• Which data classes trigger TISAX
• How you decide the assessment level
• Who approves exceptions

Output: A short “Supplier TISAX Level Determination Standard” (one to two pages) referenced by procurement and security.

4) Contractually require supplier TISAX assessment (and make it a gating clause)

Update templates and playbooks:

• MSA/DPA / security exhibit: Supplier must maintain its own TISAX assessment at the required level for the duration of access to highly confidential data (VDA ISA Catalog v6.0).
• Onboarding gate: Access to highly confidential data or environments is contingent on verified assessment status.
• Change notification: Supplier must notify you if scope changes, assessment lapses, or major control changes occur that affect assessment scope or status.
• Flow-down: If the supplier uses sub-processors that will handle your highly confidential data, require equivalent assurance and disclosure so you can confirm coverage.

Output: Updated contract clauses + onboarding checklist with a “stop/go” gate.

5) Verify assessment status before granting access (don’t rely on promises)

Operationalize verification as a control:

• Require documented proof from the supplier that a TISAX assessment exists at the required level and is in-scope for the services they provide to you.
• Validate that the assessment scope matches the locations/services handling your data. A mismatch is common (supplier assessed one site, but your work is done elsewhere).

Output: Verification record tied to the supplier profile and the specific engagement scope.

6) Control access technically so the requirement is enforceable

Tie your governance requirement to actual access paths:

• Don’t create accounts, API keys, VPN access, shared mailboxes, or file transfer endpoints for a high-sensitivity supplier until verification is complete.
• If engineering teams can grant access outside procurement (common), require a centralized “third-party access request” workflow that checks TISAX status before access is provisioned.

Output: Access control workflow evidence (tickets, approvals, system logs) linked to supplier verification.

7) Monitor scope drift and renewal events

The failure mode is predictable: a supplier starts with low-sensitivity work, then gets pulled into a high-sensitivity project. Build triggers:

• New project onboarding
• New data type requested
• New integration
• New sub-processor
• Supplier’s assessment status change

Output: Periodic review or event-based review records; updated determination when scope changes.

Required evidence and artifacts to retain

Keep evidence in a form you can hand to an assessor quickly. Minimum set:

• Supplier inventory showing which suppliers handle highly confidential data and the decision rationale.
• Data classification decision for each in-scope supplier engagement (what data, where, how accessed).
• TISAX requirement mapping document (your “appropriate assessment level” method).
• Contract artifacts: executed MSA/DPA/security exhibit containing the TISAX assessment obligation (VDA ISA Catalog v6.0).
• Verification evidence: supplier-provided proof of their TISAX assessment and that it covers the relevant scope.
• Access gating evidence: provisioning tickets/workflows showing verification completed before access.
• Exception records: approvals, compensating controls, time-bound remediation plan if you granted limited access under strict constraints (only do this if your internal governance allows it).

Common exam/audit questions and hangups

Expect assessors to probe:

• “Which suppliers handle highly confidential data?” They will look for completeness, including IT/admin and niche engineering services.
• “How did you determine the appropriate assessment level?” Show a documented method and consistent application.
• “Prove it was enforced.” Contracts and a control gate matter more than a slide deck.
• “Does the supplier assessment scope match the service you use?” Be ready to show site/service alignment and sub-processor awareness.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Blanket-scoping all suppliers into TISAX

Why it fails: It slows procurement, creates noise, and teams route around the process. Avoid it: Only require supplier TISAX when the supplier handles highly confidential data (VDA ISA Catalog v6.0). Keep a separate assurance path for lower-sensitivity suppliers.

Mistake 2: Treating “TISAX required” as a contract clause only

Why it fails: Access gets granted anyway, and you can’t show enforcement. Avoid it: Put a hard stop in identity/access workflows. No verified assessment, no access to sensitive environments.

Mistake 3: Accepting irrelevant or out-of-scope assessment proof

Why it fails: The supplier may have a TISAX assessment that covers a different location or different services. Avoid it: Verify scope alignment to your engagement: where the work happens, which systems, which sub-processors.

Mistake 4: No change control for scope drift

Why it fails: An initially “safe” supplier becomes high-risk through incremental access expansion. Avoid it: Add triggers tied to project onboarding and new data requests; require re-review before expanding access.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, your risk is still real: failure here concentrates exposure in the supply chain, which can undermine your own assurance position with OEM customers and lead to commercial consequences (loss of business, delayed onboarding, or restricted data sharing). Treat this as both a compliance requirement and a customer trust requirement grounded in VDA ISA expectations (VDA ISA Catalog v6.0).

Practical 30/60/90-day execution plan

First 30 days: Stand up the gate

• Define “highly confidential” examples and publish the classification aid.
• Add supplier intake questions to capture data sensitivity and access paths.
• Draft the “appropriate assessment level” determination standard.
• Update contract templates with the TISAX obligation for in-scope suppliers (VDA ISA Catalog v6.0).
• Implement a manual approval gate: security sign-off required before any access for in-scope suppliers.

By 60 days: Convert the back book and fix access paths

• Identify existing suppliers already handling highly confidential data; prioritize those with the broadest access.
• Remediate: obtain verification evidence or restrict access until compliant.
• Centralize third-party access requests so engineering/IT can’t bypass verification.
• Create an exception process with senior approval and a time-bound remediation plan.

By 90 days: Make it sustainable

• Automate reminders and re-validation triggers tied to scope change (new project, new integration, new data type).
• Add sub-processor disclosure and review into onboarding for in-scope suppliers.
• Build an audit-ready dashboard: in-scope suppliers, required level, status, verification date, contract status, exceptions.
• If you need a system to track determinations, evidence, and renewals without spreadsheets, Daydream can act as the control system of record for third-party due diligence and TISAX evidence collection.

Frequently Asked Questions

Do we need to require TISAX from every supplier?

No. The requirement targets suppliers handling highly confidential automotive data, and you should scope it based on data classification and access (VDA ISA Catalog v6.0).

What counts as “handling” highly confidential data?

Treat it broadly: storing, processing, transmitting, or having privileged access where the supplier could access the data. If the supplier can administer systems that contain the data, assume exposure unless you can prove technical isolation.

Can we onboard a supplier while they are “working on” their TISAX assessment?

You can require the assessment contractually, but you still need an access gate. If you allow any early work, restrict it to non-sensitive data and non-production environments until verification is complete.

What evidence is usually acceptable to prove supplier TISAX assessment status?

Keep supplier-provided proof of their TISAX assessment and document how you confirmed it covers the relevant scope of services and locations tied to your engagement.

How do we handle sub-processors used by our supplier?

Require disclosure of sub-processors that will handle your highly confidential data and contractually require equivalent assurance expectations. Reassess if the supplier adds or changes sub-processors.

Our engineering teams share files directly with suppliers. How do we enforce the requirement?

Put the gate where sharing happens: restrict external sharing on repositories, require named supplier accounts, and route provisioning through a workflow that checks TISAX verification before granting access.