the work
patching and checking it works
Patch on a schedule you wrote down, handle the reports that come in, and test once a year whether the rest of your controls run. Companies skip the last part because nothing breaks when they do.
the reality
There are two jobs here. Patching is familiar. Checking your own effectiveness is the one that goes missing, and an auditor will ask to see it first.
You do not need a separate audit programme to begin. Take a control, ask for its latest evidence and write down whether it was there. The map and the evidence kit give you the list.
basis NIS2 Art. 21(2)(e), 21(2)(f); GDPR Art. 32(1)(d)
what to decide
- Target times for patches, by severity. Your numbers, your reasonshead of IT
- Who reads reports of vulnerabilitieshead of IT
- Who checks the controls, ideally from outside the team running themnamed owner
- Whether you buy a penetration test, and whynamed owner, with the board if it is costly
basis NIS2 Art. 21(2)(e), 21(2)(f); DORA Art. 25(1)
what to build
- Write the patch targets and date them.
- Scan what faces the internet at a set rhythm and record what you found and what you did.
- Publish one address where someone can report a vulnerability to you.
- Once a year, pick five controls and test that they run: pull the evidence and see if it is current.
- Fix what the test finds, with an owner and a date.
basis NIS2 Art. 21(2)(e), 21(2)(f), 21(4); IR 2024/2690 Annex 6.6, 6.10 as a reference; KSC Art. 8(1)(5)(b)
the patching loop
- 1findscans, supplier notices, one address for reports
- 2rateagainst your own target times
- 3patchor record why you cannot
- 4confirmscan again
- 5recordwhat you found and did
every month for what faces the internet (your choice)
basis NIS2 Art. 21(2)(e); DORA Art. 25(1); KSC Art. 8(1)(5)(b). The rhythm is practice.
the evidence it leaves
| what you can show | who owns it | refresh |
|---|---|---|
| patch policy with target times | head of IT | yearly |
| scan results and actions taken | head of IT | monthly (your choice) |
| patch figures against target | head of IT | quarterly |
| yearly control test record | someone outside the team, where you can | yearly |
| findings with owners and dates | named owner | until closed |
basis GDPR Art. 32(1)(d); NIS2 Art. 21(2)(f). The rhythms are your choice.
checking your own work, in an afternoon
- 1pick five controlsfrom your register
- 2ask for the latest prooffrom whoever owns it
- 3is it current?write yes or no
- 4a findingwith an owner and a date
- 5fix itfinding a gap starts a duty to act
basis NIS2 Art. 21(2)(f), 21(4); GDPR Art. 32(1)(d)
what goes wrong
findings with no owner
Finding a gap starts a duty to act. A list nobody owns records that you knew.
targets nobody measures
A policy with a number and no figures against it shows only that you wrote a policy.
no place to report
Someone finds your flaw and cannot tell you. One address fixes it.
basis NIS2 Art. 21(4); the rest is practice
what the texts leave open
- How fast is fast enough. NIS2 sets no number.
- When a penetration test is expected. NIS2 does not name one. DORA lists it among possible tests, and advanced testing applies only to named entities.
- Whether a Polish audit also counts as your effectiveness check. Essential entities owe a first audit by 3 April 2028, so ask whoever performs it.
basis DORA Art. 25(1), 26; KSC Art. 33(2)
check it yourself
what each text says, for whoever checks this page
| text | says |
|---|---|
| NIS2 Art. 21(2)(e) | Security in acquisition, development and maintenance, including vulnerability handling and disclosure. |
| NIS2 Art. 21(2)(f) | Policies and procedures to assess whether your measures are effective. |
| NIS2 Art. 21(4) | Corrective measures without undue delay when you find you fall short. |
| IR 2024/2690 Annex 6.6 | Listed digital providers: security patch management. Annex 6.10 covers vulnerability handling and disclosure. |
| DORA Art. 24(1) | A resilience testing programme, unless you are a microenterprise. |
| DORA Art. 25(1) | Tests such as vulnerability scans, network assessments and scenario tests. |
| GDPR Art. 32(1)(d) | A process for regularly testing whether measures work. |
| KSC Art. 8(1)(5)(b) | Poland: regular software updates, following the manufacturer's recommendations. |
- Directive (EU) 2022/2555 (NIS2) (EUR-Lex)
- Commission Implementing Regulation (EU) 2024/2690 (EUR-Lex)
- Regulation (EU) 2022/2554 (DORA) (EUR-Lex)
- Regulation (EU) 2016/679 (GDPR) (EUR-Lex)
- Poland: Act of 23 January 2026 amending the national cybersecurity system act, Dz.U. 2026 poz. 252 (Dziennik Ustaw)
fyi Last checked 2 November 2026. This is not legal advice. It is a plain reading of the texts listed on this page, and national law can add to them. Before you rely on it in front of a regulator, an auditor or your board, have a lawyer confirm it for your company. What this means.