A retest means the tester repeats the attacks from the penetration test after the fixes and says whether each fix holds. If your service falls under the higher-obligations regime of Act No. 264/2025 Coll., you have to do a retest: Section 24(6) of Decree No. 409/2025 Coll. requires every finding from a vulnerability scan or a penetration test to be tested again. For other firms the law does not require it. They still have reason to want one, because without it all you know is that you changed something, not that the hole is closed.
- A retest is mandatory in the higher-obligations regime, required by Section 24(6) of Decree 409/2025 Coll.
- The tester repeats the same attack and writes for each finding: fixed, partly fixed, not fixed.
- In that regime a penetration test is done regularly, at least once every 2 years.
- OWASP marks manual escaping against SQL injection as strongly discouraged; the right fix is a parameterized query.
What a retest checks and what it does not
The tester returns to every finding in the original report and repeats the same procedure used to exploit it the first time. For each finding they then write one of three words: fixed, only partly fixed, not fixed. The US guide NIST SP 800-115 says the team can confirm a fix only if it runs a mirror copy of the original test.
A retest is not a new penetration test. It does not look for further vulnerabilities across the whole application and it does not change the scope. It answers one question: did the fix work or not? How a whole test runs, from the scope agreement to the report, is described in the article on how a penetration test works.
What the law says
Act No. 264/2025 Coll. has been in force since 4 August 2025 and took effect on 1 November 2025. It splits providers of regulated services into two regimes, and each has its own decree. What you must do about testing differs a lot between them.
| What | Higher-obligations regime (Decree 409/2025 Coll.) | Lower-obligations regime (Decree 410/2025 Coll.) |
|---|---|---|
| Vulnerability scan | At least once a year, from the internal and the external network | Regularly, for the relevant technical assets |
| Penetration test | Before going live, after a significant change, and regularly at least once every 2 years | The decree does not mention it |
| Retest of findings | Mandatory, Section 24(6) | Not in the text of the decree |
Decree 409/2025 Coll. allows a penetration test to be split into parts in justified cases, but the whole scope must then be finished within 5 years at the latest. For every test the firm records the date and the names of the people who carried it out. The act itself describes a penetration test as looking for vulnerabilities with a simulated attack and gives the authority NÚKIB the power to order one.
Which regime you belong to is decided by size, number of users and the importance of the service under Section 8 of the act. The NIS2 page shows who falls under the law. If you are not covered, the law does not decide about a retest, your contract with the supplier does.
- 4 Aug 2025The act is in forceAct No. 264/2025 Coll. has been in force since 4 August 2025.
- 1 Nov 2025The act takes effectThe act and Decrees 409/2025 Coll. and 410/2025 Coll. take effect on 1 November 2025.
- Before going liveFirst penetration testTesting of technical assets before going live and after a significant change.
- After the fixesRetest of every findingA duty under Section 24(6) of Decree 409/2025 Coll.
- Every 2 yearsRegular testA penetration test is repeated at least once every 2 years.
- Within 5 yearsA test split into partsIf a test was split into parts, the whole scope must be finished within 5 years at the latest.
Why fixes fail
A fix that looks right often only masks the attack. A typical example is SQL injection. The developer "treats" the input with manual escaping and the attack from the test stops working. But OWASP explicitly marks manual escaping as strongly discouraged and writes that it depends on the SQL dialect and on how the database is configured. The right fix is a parameterized query. During a retest the tester tries the attack again, written differently, and manual escaping does not stop it.
The second reason is simple: the fix may have gone wrong when someone deployed it. NIST advises trying a change on a test system first and adds that this greatly reduces, but does not rule out, the risk of an adverse reaction by the system. A fix that survives the test may behave differently in production. A retest runs against the system you actually use.
The third reason is organisational. The developer holds the finding and confirms that they changed the code. They do not verify that the attack no longer gets through. "Done" and "does not work" are two different things.
How a retest runs step by step
- Agree on it when you order. Ask how many rounds of retesting the contract includes, how soon after the fixes it takes place and what happens if a fix fails.
- Divide the findings. Give each one an owner and a deadline. A finding you do not want or cannot fix goes down as an accepted risk with the reason. Decree 409/2025 Coll. explicitly wants the firm to take penetration test results into account in risk management.
- Fix through your change process. NIST points out that administrators want to fix things at once and expect the tester to recheck the system immediately. Even so, they should stick to their own rules for changes.
- Tell the tester exactly what changed. They then do not have to guess where to look, and the retest is shorter.
- The tester repeats the attacks. They use the same procedure as in the original test.
- You get a result for every finding and a supplemented report. Store it with the original one. For regulated services it serves as proof that you closed the finding.
What to do in a firm of twenty people
Take a firm where one administrator or an external IT supplier does the fixes and nobody has a security team. The procedure is short.
- Turn the original report into a table: finding, how serious it is, who fixes it, by when, status.
- Start with the most serious findings and arrange the retest for the whole batch of fixes, not one finding at a time. The supplier gets one report on the changes and you get one result.
- Ask whether the fix is in production, not just in the repository or on the test environment.
- Ask the supplier for a result on every finding separately, not a general "all fine".
The price of a retest varies with the number of findings and the scope. What affects the price of a test as a whole is covered in the article on the price of a penetration test. The retest should be stated in the contract up front. On its own penetration testing page Lumenax states that the retest is included in the price and that after the fixes it verifies that the findings are truly resolved.
Mistakes that keep repeating
- A retest is mistaken for a scan. Decree 409/2025 Coll. treats a vulnerability scan and a penetration test as two separate activities. A scan does not repeat the specific attack from your test.
- The fix goes out without a change process because there is a rush. NIST explicitly warns about this situation.
- The retest report is not stored. A year later nobody knows about it and at an inspection you have nothing to show.
- A finding is closed quietly. Whoever does not want to fix it should record it as an accepted risk, not let it vanish from the list.
- No retest is ordered at all. The report stays a list of findings where nobody knows how they turned out.
How to prepare for the test so that fewer findings come out is summed up in the article on preparing for a penetration test.
Common questions
Is a retest after a penetration test mandatory?
For a provider of a regulated service in the higher-obligations regime, yes, Section 24(6) of Decree No. 409/2025 Coll. requires it. Decree 410/2025 Coll. for the lower-obligations regime mentions neither a penetration test nor a retest. Other firms may face it as a requirement from a customer or an insurer, but the law does not address that.
By when after the fixes must the retest take place?
Decree 409/2025 Coll. sets no deadline. Agree a date with the test supplier in advance and write it into the contract.
What if a fix fails the retest?
The finding stays open. Fix it again and have it tested again. Until then count it as an unclosed risk and put it in the risk overview.
Is a retest the same as a vulnerability scan?
No. The decree treats a vulnerability scan and a penetration test as two separate activities. You must retest findings from both, but with a penetration test it is done by a person who repeats the attack.
Is it enough for the developer to confirm the fix?
No. NIST SP 800-115 names a system audit, repeated testing and records of who made the change as ways to confirm a fix. The developer confirms the change, but whether the attack gets through only a repeated test shows.
Is the retest included in the price of the test?
At Lumenax yes, as the penetration testing page states. With another supplier, check the contract before you order the test.
Sources
- Act No. 264/2025 Coll., version in force from 1 Nov 2025: https://www.zakonyprolidi.cz/cs/2025-264
- Decree No. 409/2025 Coll., in force from 1 Nov 2025: https://www.zakonyprolidi.cz/cs/2025-409
- Decree No. 410/2025 Coll., in force from 1 Nov 2025: https://www.zakonyprolidi.cz/cs/2025-410
- NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, September 2008, sections 7 and 8.3: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
- OWASP Cheat Sheet Series, SQL Injection Prevention Cheat Sheet, viewed 25 Oct 2026: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
- Lumenax, Penetration tests, viewed 25 Oct 2026: https://www.lumenax.cz/penetracni-testy
PHP2Shell vulnerability: does it affect your website and what to do
Free CRM: when it's enough and when it costs more than a paid one
Ollama: how to run local AI over your own company data
