In short: For the IT security of tax advisors, what matters is which systems the firm operates itself. Large portals run by software vendors are the vendor's responsibility, whereas your own website, upload forms and data rooms are yours. These now belong on patched PHP, with a restart and written proof.
Which systems in tax firms run on PHP
For financial accounting and payroll, most firms use specialised software and its portals. Alongside it, in-house solutions build up over the years: an upload form on the website for receipts, income tax questionnaires, a page for clients' new employees to enter payroll master data, an application portal, or a self-hosted Nextcloud for large files.
These systems almost always run on PHP and are looked after by an agency, an IT systems house or a host. It is the small forms in particular that fall into oblivion, because they were set up once and have simply worked ever since. Uploaded receipts then often sit for years in the web server's upload folder, even though they were long since processed in the firm's software.
Which data is at stake
Tax firms process data at a density that hardly any other sector reaches: IBANs and account statements, tax IDs, proof of income, shareholder lists and payroll statements. Payroll data sometimes also contains special categories under Art. 9 GDPR, such as religious affiliation for church tax.
On top of that comes professional secrecy: tax advisors are bound to confidentiality, and unauthorised disclosure can be a criminal offence under Section 203 StGB (German Criminal Code). And many of those affected are not your clients at all but their employees. In a leak, the circle of affected people therefore grows quickly.
Tax advisor IT security: what an incident actually triggers
An attack on a tax firm has typical consequences that differ from other sectors:
- Fraud with real data: Anyone who knows invoices, bank details and contacts can send deceptively genuine payment requests to clients.
- Deadline pressure: If the upload portal fails during filing season, receipts pile up and clients switch to insecure routes such as unencrypted emails.
- Trust: Clients rely on their finances remaining confidential. An incident they learn about from the press weighs more heavily than one the firm itself reports factually.
If your upload portal sits on a server whose PHP patch level nobody can confirm, take it offline until the patch and restart are proven. This is what the BSI (German Federal Office for Information Security) recommends for servers that cannot be updated immediately.
The responsibility gap between systems house and agency
The systems house looks after the firm software and workstations, the agency the website, the host the server. Who is responsible for PHP on the web server is rarely stated explicitly in the contract. Clarify that now and have the package version confirmed. How to interpret the details is explained in the guide Checking your PHP version and patch level.
Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If an interface shows an older version, a backport may nevertheless have been applied. Conversely, an update without a restart of the PHP processes is not enough.
What clients should know from you now
Clients react to news about security vulnerabilities with uncertainty, especially if they upload receipts regularly. A short, factual notice then builds trust: which routes currently apply for exchanging receipts, that the firm never changes bank details by email, and that suspicious payment requests should be queried by phone.
For corporate clients, one further note makes sense: payroll offices and HR departments should be particularly alert to requests about salary data or changed bank details of employees. Such fraud attempts like to use knowledge that comes from firms like yours. Whether a specific incident requires a formal notification under the GDPR is a separate question, which you clarify with your data protection officer.
First hours for the firm's management
- List all your own PHP systems that are reachable from the internet, including old forms and test installations.
- For each system, have the patch level and restart confirmed in writing, or switch it off temporarily.
- Preserve logs from 20 October 2026 onward and define a secure fallback route for the exchange of receipts.
- Inform the insurer and the data protection officer early. What your policy requires is explained on the page about cyber insurance.
How does PHP SOS help?
- We record all externally reachable PHP systems of the firm and clarify which are with the software vendor and which are with you.
- As part of the PHP2Shell emergency help we patch, or have patching done, restart all workers and document the result.
- We check upload directories and databases for webshells and unknown access.
- We tidy up: what is no longer needed we switch off in agreement with you, rather than continuing to patch it.
- With a security maintenance contract, responsibility for PHP stays clearly settled afterwards.
Frequently asked questions
Is the exchange of receipts via large software portals affected?
Portals that a software vendor operates in its own data centre are the vendor's responsibility. The vendor is responsible for their patch level. What can be affected are above all systems that your firm operates itself or through an agency, such as website forms, upload pages or your own Nextcloud.
Why is tax advisors' data so interesting to attackers?
A tax firm bundles the data of many companies and private individuals: bank details, income, tax IDs and employees' payroll data. This makes it possible to prepare credible fraud emails and identity abuse. A single incident therefore often affects hundreds of people who never directly instructed the firm.
What if the portal has to go offline in the middle of filing season?
Define a fallback route for the exchange of receipts in advance, for example an encrypted handover via an unaffected system. Inform clients briefly and factually. You settle deadlines and possible extensions as usual on the merits; taking a portal offline is no substitute for coordination on that.
Will the cyber insurance pay if we were unpatched?
That depends on the terms and obligations of your policy. Inform the insurer early and document when you took which measure. Only the insurer or your broker can give you a binding answer.