"You need a penetration test for TISAX." It's on half the security vendor pages in Germany. It's also not in the catalogue. The VDA ISA names a pentest only as you move up in protection need, and even then as an example.
What every label does require is harder to buy the week before the audit: regular technical checks, with results that reach management and turn into fixes. ISA2027 adds a question nobody could ask before: did you fix it in time?
What TISAX actually asks
ISA 6.0.3 is the version assessed today. For every label, 5.2.6 asks for regular audits of your systems, performed from the internet and the internal network. Pentests only appear as protection need goes up.
Every label
5.2.6- What the catalogue says
- Regular system and service audits, from the internet and the internal network, with results to management.
High (AL2)
5.2.6- What the catalogue says
- Human penetration tests named for critical systems, at risk-based time intervals.
Very high (AL3)
5.2.6- What the catalogue says
- Regular vulnerability scanning.
Very high (AL3)
5.3.1- What the catalogue says
- Purpose-built or heavily customised software is tested, for example by penetration testing, at go-live, after significant changes or at regular intervals.
| Protection need | Control | What the catalogue says |
|---|---|---|
| Every label | 5.2.6 | Regular system and service audits, from the internet and the internal network, with results to management. |
| High (AL2) | 5.2.6 | Human penetration tests named for critical systems, at risk-based time intervals. |
| Very high (AL3) | 5.2.6 | Regular vulnerability scanning. |
| Very high (AL3) | 5.3.1 | Purpose-built or heavily customised software is tested, for example by penetration testing, at go-live, after significant changes or at regular intervals. |
The catalogue sets no fixed frequency, and it never mentions retests.
The pentest was never the requirement. The evidence that you act on test results is.
The one line that changes
The VDA published ISA2027 on 1 July 2026. Catalogues are now named for the year they take effect.
1 Jul 2026
ISA2027 published
1 Jan 2027
Applies to every assessment ordered from this date
Mar 2027
Last month to open an initial assessment under ISA 6
The pentest wording barely moves. What moves is what the auditor can ask about after a test. ISA 6.0.3 only asked you to derive measures from your results. ISA2027 asks you to carry them out, in time.
5.2.6- ISA 6.0.3
- Measures are derived from audit results.
- ISA2027
- Measures are derived from the results and implemented in an appropriate timeframe.
5.2.5- ISA 6.0.3
- Vulnerabilities are assessed and treated.
- ISA2027
- Affected systems are identified, the risk is assessed, and risks arising from vulnerabilities are treated.
1.6.2- ISA 6.0.3
- Reported security events are handled.
- ISA2027
- New for high: maximum response times by class, category and severity are defined.
| Control | ISA 6.0.3 | ISA2027 |
|---|---|---|
5.2.6 | Measures are derived from audit results. | Measures are derived from the results and implemented in an appropriate timeframe. |
5.2.5 | Vulnerabilities are assessed and treated. | Affected systems are identified, the risk is assessed, and risks arising from vulnerabilities are treated. |
1.6.2 | Reported security events are handled. | New for high: maximum response times by class, category and severity are defined. |
Three smaller changes point the same way: scanning at very high protection now covers confidentiality and integrity as well as availability, reports from outside parties must be processed on time, and test systems holding production data need production-grade protection.
Picture the audit: PHP2Shell
October gave every supplier a live test. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets an attacker run code on a PHP server without logging in. The fix shipped on 21 October. CISA listed both bugs as exploited on 26–27 October, the BSI issued a warning, and Censys still counts more than 4 million PHP services in Germany showing a vulnerable version.
Now your auditor asks one question:
Which of your systems ran an affected PHP version on 21 October, and when was each one fixed?
Two ways to answer (an example)
A single pentest report
- Dated March
- Before PHP2Shell existed
- Lists the hosts IT knew about
Can't answer the question
A test history
- Every internet-facing PHP host
- Patch date per host
- Retested from outside
Answers it in minutes
The second answer needs four things: every internet-facing host that runs PHP, including the forgotten ones; the version each ran, or the vendor backport it received (fixed upstream in 8.5.12, 8.4.27, 8.3.36 and 8.2.35); the date each was patched; and a check from outside that the fix is live. Version banners can mislead, because Linux distributions often backport fixes without changing the number.
If you can't produce that list for PHP2Shell, you won't have it for the next critical bug either.
What to have ready
Each item answers a question your auditor can now ask.
- 01
An external inventory
Which systems are affected? Every host and subdomain reachable from the internet, compared with what IT thinks is there. Attackers start with the ones you forgot: the old supplier portal, the 2023 test instance.
- 02
A test plan
When did you last test them? Which systems, how often, from outside and from inside, and who decides the intervals.
- 03
Dated results
What did you find? Reports with dates and proof that management saw them. Level 3 maturity means a process used over time, not a one-off report.
- 04
A record per finding
What happened to each finding, and when? The measure, an owner, the date it was fixed and a retest that confirms it.
- 05
Written response times
How fast counts as in time? Maximums by severity, for your own findings and for reports from outside.
Where the catalogue names them, add human pentests: critical systems at high protection needs, and your own software at very high. None of this needs a bigger budget. It needs testing that runs more often than the audit cycle, and one place where results, owners and dates stay together.
Where SecNode fits
SecNode's AI agents test your web applications and APIs continuously, not once a year. Attack surface monitoring keeps the external inventory current. Every finding comes with a working reproduction and a dated report, and a retest after each fix shows it closed.
We don't replace the human pentest the catalogue names for critical systems. We cover the other eleven months.