Four deadlines from the last two months, all verifiable:
- Citrix NetScaler CVE-2026-19490 — added to CISA's Known Exploited Vulnerabilities catalogue on 9 September 2026, remediation due 12 September.
- WordPress core CVE-2026-87902 — patch published 22 September, first exploitation attempt logged at 11:49 UTC the same day. KEV on 25 September, due 28 September.
- Ivanti Connect Secure CVE-2026-104935 — advisory and KEV listing both on 13 October, due 16 October, flagged as requiring forensic triage.
- Atlassian CVE-2026-21589 — KEV on 15 October, due 18 October, with exploitation attempts starting roughly two hours after the technical write-up went public.
Three days, three days, three days, and in one case three hours. None of those fits inside a monthly maintenance window. None of them survives a change advisory board that meets on alternate Tuesdays.
The interesting question is not whether your organisation can patch quickly. Most can. It is whether your organisation can decide quickly, and that is a different machine entirely.
The constraint is almost never technical
Ask a team why a critical patch took eleven days and you will rarely hear that the patch was hard. You will hear some version of these:
- The system owner was on leave and nobody else could approve a restart
- The change board does not sit until Thursday and this was not classed as an emergency
- The change freeze was in effect for the quarter-end and nobody knew who could lift it
- The vendor portal credentials were held by one person, and it was a Saturday
- Nobody wanted to be the one who rebooted the box that turned out to be load-bearing
Each is a process failure wearing a technical costume. The patch was available the whole time.
What NIS 2 actually asks for here
Article 21 of NIS 2, transposed in Romania by OUG 155/2024, lists "handling and disclosure of vulnerabilities" among the required measures, alongside incident handling and business continuity. It does not prescribe a number of days. Auditors will not hand you a target and most of them do not want to.
What a competent assessment looks for instead is whether the process exists, whether it has deadlines written into it, and whether evidence shows those deadlines being met — or consciously missed, with a decision recorded by someone with the authority to make it.
That last clause is the one organisations skip. A missed deadline with a dated risk acceptance signed by the system owner is a functioning process. A missed deadline nobody noticed is not.
The pre-approved emergency change
The single most useful artefact here is a change template written before you need it, approved once by whoever normally approves changes, and kept warm.
It should name, in advance:
- The trigger conditions that make a change an emergency — a KEV listing, a vendor advisory above an agreed severity, confirmed exploitation in the wild, or an instruction from the national CSIRT
- Who can authorise, by role and not by name, with at least two roles deep so one person's holiday does not stop it
- Who can authorise out of hours, and how they are actually reached at 22:00 — a phone number that someone answers, not a shared mailbox
- What testing is waived under emergency conditions, and what is never waived
- What is recorded during the change rather than before it, so documentation does not become the blocker
- Who is told, and when — service desk, affected business owners, the on-call team
The point of writing it down in advance is that at the moment you need it, nobody is deciding who decides. They are executing.
The change freeze problem
Most organisations freeze changes around quarter end, peak trading, year-end close or a major go-live. Most freeze policies are silent on security emergencies, which means in practice they get interpreted on the day by whoever is most nervous.
Write the exemption into the freeze policy itself, with the same named roles. A freeze that cannot be lifted for an actively exploited vulnerability is a policy that has decided a quarter-end report matters more than a compromise, and somebody should make that decision deliberately rather than by omission.
The things nobody can find on a Saturday
A surprising amount of emergency patching stalls on logistics:
- The vendor support portal login, held by the person who originally bought the product
- The maintenance contract number needed to download the fix
- The out-of-band management credentials for the appliance
- Which of your three similar-looking servers is actually the one in the advisory
- The current firmware version as it is actually running, rather than the version in the asset register
That last one is worth dwelling on. The Ivanti case included an appliance that was fully patched at the time it was compromised, and the Atlassian advisory applies to "all versions" — so an inventory that records intended versions rather than running ones tells you nothing useful in either case.
Patching is step one, not the whole response
The Ivanti chain is the clearest recent argument that applying the fix is where the work starts.
Volexity found no web shell and no first-stage malware on the appliance it investigated, because the privilege escalation ran entirely in memory and the attacker re-executed the whole chain for each command. Ivanti's own integrity checker could not see it. CISA told organisations they would need network and memory forensics, and its KEV entry flagged the CVE as requiring forensic triage — a distinct instruction from "install the update".
So the emergency change process needs a second half: when the advisory says exploitation preceded disclosure, what evidence do you collect, who collects it, and what do you rotate afterwards? In the Ivanti case the answer included every domain, administrator and local account password, plus stored certificates, API keys and licence credentials. A patched appliance with the stolen credentials still valid has closed the door and left the keys outside.
Rehearse it once
This is one of the few things a tabletop exercise genuinely improves, because the failure modes are organisational and they surface immediately.
Run it as a ninety-minute session. Pick a real advisory from the last month — there is no shortage. Set the clock at Friday 18:00. Then work through it out loud: who declares this an emergency, who do they call, what happens when that person does not answer, who holds the vendor credentials, who signs off the reboot, who tells the business that the VPN is going down, and what do you do if the advisory says assume compromise.
You will find two or three broken links in the chain. Fix those, and you have shortened every future response by more than any tooling purchase would.
What to write down this month
Three documents, none of them long:
- An emergency change template, pre-approved, with trigger conditions and named authorising roles including an out-of-hours path
- An explicit security exemption clause in the change freeze policy
- A one-page contact and credential map for your internet-facing systems: who owns it, who can authorise a restart, where the vendor credentials live, and how to confirm the running version
If you are not confident which systems should be on that list — which services answer on your public addresses and what version each actually reports — that is a question an external attack surface review answers from the outside, the same way an attacker would build the list. Where the process itself needs examining rather than the technology, an audit and compliance review under NIS 2 covers it, and an internal penetration test shows what an unpatched system actually reaches once someone is inside.
The deadlines are not going to get longer. A three-day federal remediation window is now ordinary rather than exceptional, and the gap between a public write-up and the first scan is measured in hours. The organisations that close that gap are not the ones with better scanners. They are the ones where somebody already knows who to call.
Sources: CISA Known Exploited Vulnerabilities catalogue · Volexity on the Ivanti Connect Secure chain · Atlassian advisory for CVE-2026-21589 · Patchstack on CVE-2026-87902 exploitation timing
The KEV addition dates and deadlines above are as reported by the vendors and security press; we have not read every catalogue entry directly. The exploitation timings are vendor telemetry from honeypot networks and are not counts of compromised organisations.
This article is general information, not legal or regulatory advice.