Safeguard
Compliance•

How do software supply chain controls map to TISAX?

TISAX assesses security against the VDA ISA catalogue. Here is how inventory, build control, supplier checks and patching evidence line up with its topics.

Safeguard Security Team
4 min read

TISAX does not have a supply chain chapter you can tick off. It assesses information security against the VDA ISA catalogue, and software supply chain controls show up as evidence under topics like supplier management, system acquisition and development, vulnerability handling and access control. Prepare the evidence by topic, then check the exact catalogue wording with your audit provider.

What is TISAX?

The ENX Association describes TISAX as a standardised information security assessment framework for the automotive industry. A company is assessed once and the result is recognised by many partners. The assessment is based on the VDA Information Security Assessment (ISA) catalogue, which ENX maintains and the VDA publishes. ENX's page says the current version is ISA2027, released in July 2026.

The process, per ENX: register and define scope, choose an approved audit provider, complete a self-assessment against the catalogue, then undergo an external audit. Depth ranges from document review to on-site inspection depending on the protection need. Results are issued as labels, valid for three years, and shared through the ENX Portal with selected partners.

Safeguard does not hold a TISAX label, and this post does not say any software gives you one. It explains how supply chain evidence lines up.

Why does the supply chain matter to automotive buyers?

Carmakers require suppliers to show a baseline of information security. If your software goes into a supplier's product or runs on their network, they will ask how you build it and what is inside. NIST SP 800-161 describes the risk: products and services may contain malicious functionality or be vulnerable through poor development practices, and buyers often have limited visibility into how technology is built.

Which evidence lines up with which topic?

We describe topics in general terms. The catalogue numbers and wording change between versions, so map to the version your audit provider uses.

Supplier and third-party management. Evidence: a list of your own software and service suppliers, how you assess them, the security terms in contracts, and what you do when a supplier reports an incident.

Acquisition and development of systems. Evidence: a secure development process, code review rules, dependency inventory per release, and records of how third-party components are chosen and approved. NIST's SSDF organises similar practices as preparing the organisation, protecting the software, producing well-secured software and responding to vulnerabilities.

Vulnerability and patch handling. Evidence: scan results with dates, a stated response time for critical findings and records showing you met it.

Access control and privileged accounts. Evidence: who can change code, pipelines and registries, how that is reviewed, and where multi-factor authentication is enforced.

Change and release control. Evidence: protected branches, required reviews and deployment logs.

Incident handling. Evidence: your process and a test of it, including how you notify customers.

What do assessors usually want to see?

They want to see that the process exists, is followed and produces records. A scanner report with no owner or response time proves less than a modest process that is followed. Keep samples ready: a handful of recent releases with their inventories, the review record for each and the fix record for one critical finding.

How should you choose the assessment scope?

Scope the environments and teams that handle partner information. A smaller, well defined scope is easier to evidence than a vague company-wide one. Decide this with your audit provider before the self-assessment.

What to do

  1. Confirm with the customer or audit provider which ISA version and assessment objective apply.
  2. List the topics above and the system that produces evidence for each.
  3. Generate a dependency inventory for each release and store it with the build.
  4. Write down response times for critical findings and keep records of meeting them.
  5. Check that review and multi-factor settings are enforced and exportable.
  6. Prepare three sample releases end to end before the audit.

Quick check

Is there a TISAX control that requires an SBOM?

We did not confirm one. Check the catalogue version in use. An inventory is still strong evidence under development and supplier topics.

How long is a TISAX label valid?

ENX states three years.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.