In short: ISO 27001 and TISAX affect web servers mainly through three requirements: vulnerabilities must be identified and handled, service providers such as hosts and agencies must be managed, and security incidents need a regulated procedure. A situation like PHP2Shell is a practical test for every ISMS. Anyone who documents assessment, patch and restart traceably has a good basis for the next audit. A certificate or label does not replace the patch.
What ISO 27001 and TISAX are, in two paragraphs
ISO/IEC 27001 describes the requirements for an information security management system, ISMS for short. This means an orderly cycle: assess risks, define measures, implement, check and improve. The current 2022 edition contains, in Annex A, a catalogue of 93 controls in four themes. Which of them apply is decided by the company on the basis of its risk assessment and recorded in the statement of applicability.
TISAX is the assessment and exchange mechanism widespread in the automotive industry. It is run by the ENX Association; its basis is the ISA requirements catalogue, which ENX maintains and the VDA (German Association of the Automotive Industry) publishes. Independent audit providers carry out an assessment whose scope depends on the protection need and ranges from document reviews to on-site visits. According to ENX, the results are issued as labels, are valid for three years and are shared only with selected partners via the ENX portal.
ISO 27001 on the web server: which requirements apply?
A web server is rarely a chapter of its own in the ISMS. It appears in several places, and that is exactly where gaps arise. The following overview assigns the most important themes in general terms. It does not replace a look at your own statement of applicability.
| ISMS theme | What this means for the web server | Evidence that helps in the audit |
|---|---|---|
| Inventory of assets | Every website, server and PHP version is recorded | Current list with operator, version, owner |
| Management of technical vulnerabilities | Alerts such as PHP2Shell are assessed and handled | Ticket with assessment, decision, patch date |
| Supplier relationships | Host and agency have clear security duties | Contract, division of tasks, written confirmation of the patch level |
| Logging and monitoring | Web server logs are retained and evaluated | Retention rule, example of an evaluation |
| Incident management | Suspicion is reported, assessed and closed | Incident record, lessons learned |
| Configuration management | PHP and web server settings are defined | Target configuration and deviation check |
For TISAX, comparable themes apply, because the ISA catalogue is aligned with other major standards. In addition, some assessment objectives, such as prototype protection, call for particular care with systems through which partners exchange data. These can also be PHP-based portals.
PHP2Shell as a practical test for the ISMS
On 21 October 2026, the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. There are no official updates any more for PHP 8.1 and older. In this situation, a functioning ISMS should trigger a chain that can later be evidenced.
- Intake: Who received the alert and when, and where is it recorded?
- Assessment: Which systems are affected? This presupposes a current inventory, see Know what is running.
- Decision: Patch, interim measure or temporary shutdown, with justification and the name of the person deciding.
- Implementation: Package level, restart of all PHP processes, check. For distribution backports, the package changelog counts, not the displayed version number; how to prove this is shown in Checking the PHP version and patch level correctly.
- Suppliers: Written confirmation from the host that patching and restart have been done.
- Follow-up check: Check for signs of compromise since 17 October 2026, because a patch does not undo earlier break-ins.
How to turn this one-off chain into a permanent procedure is described in Vulnerability management for mid-sized businesses and Patch management as a process.
Common weaknesses in documentation
In practice, evidence rarely fails because of technology but because of gaps in the chain. Typical is a website that a department operates with an agency and that is missing from the inventory. Equally common are host contracts with no statement on how quickly security updates are installed and whether customers are informed.
Another classic: the patch ticket is closed, but nobody has restarted the PHP processes. Formally the item is done, technically the old code keeps running. Good evidence therefore contains not only “update installed” but also the restart and a check afterwards.
It also gets difficult with systems that cannot be patched immediately, such as an application on PHP 8.1. An ISMS does not demand miracles here, but it does demand a conscious decision: which interim measures apply, who has accepted the remaining risk, and by when is the move planned? A written risk acceptance with an expiry date is clearly better in an audit than a legacy system quietly running on. The logs are similarly important. After PHP2Shell, trade press and specialist authors advised retaining server logs from 20 October 2026 onwards. Whether your retention rule allows that, and whether the logs are held by the host or by you, should be clarified before the next incident, not during it.
If your company also falls under NIS2, these requirements are reinforced. The basics are under NIS2 and web server security. This is general information, not legal advice.
A certificate or label describes the state of a management system at the time of the audit. It does not protect any individual server from a new vulnerability. What matters is that the procedure actually works in an emergency.
How does PHP SOS help?
- We record your web servers and PHP installations in a way that fits the inventory of your ISMS.
- We patch and document with our PHP patch service: package level, restart, check, with dates and evidence.
- We draft the questions to hosts and agencies and assess their answers for your supplier management.
- We supply your ISMS manager with the technical facts. The assessment within the management system and the audit remain with you and your audit body.
Conclusion
ISO 27001 and TISAX do not require a particular web server, but they do require a traceable way of handling it. PHP2Shell shows whether inventory, vulnerability handling and supplier management work together. Anyone who cleanly evidences the chain of intake, assessment, patch, restart and follow-up check has not only the audit but above all the server under control.
Frequently asked questions
Does the company website fall within the scope of ISO 27001?
That depends on how your company has defined the scope. If the website processes customer data, is connected to internal systems or is operated by a service provider, there is much to be said for including it or at least covering it through supplier management.
Is TISAX a certificate?
The ENX Association describes it as an assessment by independent audit providers, the results of which are issued as TISAX labels. According to ENX, the labels are valid for three years and are shared selectively with partners via the ENX portal; they are not public.
Must I inform my auditor after PHP2Shell?
There is no general obligation to do so. Your ISMS should, however, document how you assessed and handled the vulnerability. These records are typically examined at the next audit.
Which version of ISO 27001 is current?
The authoritative edition is ISO/IEC 27001:2022. Its Annex A groups the controls into four themes: organisational, people, physical and technological.