Has your customer's security questionnaire already arrived? By 31 October 2026 the answer must also be in the software
Application penetration testing of the system you use and the system you sell, fixes made in the code, checks that stay in CI. For SMEs in the NIS2 perimeter and for their suppliers.
Do you recognise at least two of these?
- A large customer sent you a security questionnaire with questions about software, and you answered "in progress".
- Your NIS2 consultant did the register, the contact person and the procedures, but wrote "check with the vendor" next to the management system.
- The system you use (or sell) was written years ago, and nobody knows whether one user can see another user's data.
- PHP or Laravel are on a version that no longer receives security updates.
- Nobody has ever tried to attack the software before a customer, or an unhappy employee, does.
If you said yes at least twice you are in the most common situation: the organisational side of NIS2 is covered, the side inside the software is not. And the audit looks at both.
What finding out later costs
The EU NIS2 directive (2022/2555), transposed in Italy by Legislative Decree 138/2024, requires companies in essential and important sectors (energy, transport, health, water, waste, manufacturing of devices and machinery, digital services) to adopt minimum security measures by 31 October 2026. Many SMEs fall in as suppliers: if a customer sends you a questionnaire, it has already started.
- A broken access control vulnerability (one user seeing or changing others' data) is the most common in management systems and the most serious: customer and employee data exposed, regulator notification, customer lost.
- A supplier questionnaire with vague answers weighs on the next order, even if nobody tells you.
- If you sell the software, from 2027 the Cyber Resilience Act adds security-by-design and update obligations.
What if you filled in the next questionnaire with a report in hand?
Imagine answering with one page: what was verified in the system, when, with which method, with what outcome, and what was fixed. It is what your NIS2 consultant wants to attach, and what your large customer wants to read.
An OWASP application penetration test looks exactly where management-system problems live:
- Authorisation: can a user see or change other users' data?
- Input: SQL injection, XSS, file upload, manipulated parameters.
- Sessions and authentication: passwords, tokens, reset, sessions that never expire.
- Dependencies: libraries with known vulnerabilities, unsupported PHP and Laravel versions.
- Configuration: debug on in production, secrets in the repository, exposed backups.
The difference from a pentester who does not code
A test alone leaves you with a list. Here the list is closed in the code, because the person testing has built Laravel software for fourteen years and in recent years found and fixed broken access control in management systems of organisations with thousands of users, with zero regressions thanks to tests added before every change. What you receive:
- Report with every vulnerability, severity, how to reproduce it and how to fix it.
- Fixes in the code with automated tests that prevent regression.
- Static analysis (PHPStan) and dependency checks added to your CI, so the control stays after the engagement.
- One page for your NIS2 consultant: what was verified, when, with what outcome, ready for the audit.
Time, cost and the first step
An application penetration test on a web management system takes 3 to 8 days depending on its functions, at €700 to €900 per day, report included; fixes are quoted after the report, in writing. Between the request and 31 October 2026 there is less time than it seems: tests are scheduled one at a time.
The first step is free and commits you to nothing: 30 minutes to understand whether you are in the NIS2 perimeter, which software is exposed and where to start. You leave with a written list, even if someone else then runs the test.