TISAX (Trusted Information Security Assessment Exchange) is the industry-specific security standard of the automotive sector – developed by the VDA and operated by the ENX Association. It ensures that companies demonstrably meet a high level of information security and can reliably share this status with their partners.
As part of TISAX, the regular execution of penetration tests is a key component of the technical security verification process. They serve to practically test the effectiveness of implemented security measures and to identify vulnerabilities at an early stage. This ensures that companies do not merely comply with policies but are genuinely protected against real-world attacks.
In the VDA’s Information Security Assessment Catalogue 6.0.2 (ISA6 DE 6.0.2), penetration testing is explicitly mentioned in two sections. The first reference appears in section 5.2.6 – To what extent are IT systems and services technically reviewed (system and service audits)?
In general, system and service audits must be conducted, planned in advance, and coordinated with all relevant parties. Their results must be transparently documented, reported to management, and used as a basis for appropriate improvement measures. In addition, such audits should be performed regularly and risk-based by qualified professionals using appropriate tools – both from the internal network and from the Internet. After completion, an audit report should be prepared promptly. While penetration testing can help to fulfill these requirements, an explicit demand for such testing only appears in the additional requirements for systems with a high protection need:
Additional requirements for critical IT systems or services have been identified and fulfilled (e.g., service-specific tests and tools and/or penetration tests, risk-based testing intervals).
The next reference appears in section 5.3.1 – To what extent is information security considered in new or further developed IT systems?
In principle, information security requirements must be identified, considered, and verified through security acceptance testing during the planning, development, procurement, and modification of IT systems. Specifications should include security requirements, best practices, and fail-safety measures, and they must be reviewed before systems go live. The use of production data for testing should be avoided or protected by equivalent safeguards. For systems with a very high protection need, the catalogue again explicitly refers to penetration testing:
The security of software specifically developed for a particular purpose, or extensively customized software, is verified (e.g., by penetration testing) during commissioning, in the event of significant changes, and at regular intervals.
The requirements for penetration testing under section 5.2.6 are relatively unspecific. If no proprietary software development is carried out – either internally or by contractors – testing usually focuses on conducting an external penetration test to assess publicly accessible services (e.g., websites) and analyzing the internal network. In traditional IT environments, the primary focus is typically on the Active Directory, the firewall, and internally reachable systems.
The execution of extended penetration tests – such as those including social engineering, phishing, physical security assessments, or DDoS testing – is generally not necessary for typical, limited-scope environments.
