questionnaire asks about our patch policy for software updates

Patch policy falls under vulnerability management, not incident response

The question about patch policy belongs to the process for identifying and remediating vulnerabilities, not to incident response. Customers want to know whether updates are rolled out structurally and on time, with a distinction between critical patches (often within days) and regular updates (often within a fixed cycle of weeks). An answer that only says "we update regularly" is too vague; what is usually asked for is a concrete timeframe per risk class and clarification of who is responsible for executing and monitoring it.

If you have no documented timeframes, then "no" is the honest answer, even if you patch quickly in practice. A procedure that exists only in someone's head is not a policy you can demonstrate. Often the same list also asks whether this patch policy is part of a broader process for risk analysis — if documented policy already exists for that, you can incorporate patch policy as part of it instead of documenting it separately. Also pay attention to the scope of the question: does it concern your own infrastructure, products you deliver, or both. This determines whether your evidence is an internal policy document or a release note to customers.

Traceable to Article 21(2) NIS2

Vulnerability management and its remediation (handling and disclosure) is mentioned as a separate measure in Article 21(2) of Directive (EU) 2022/2555, alongside basic practices for cyberhygiene. Patch policy is the operational implementation of that measure. In ISO/IEC 27001 this is reflected in Annex A, under control measures for technical vulnerability management, where patch timing is explicitly named as a control. Under the Dutch Cybersecurity Act, the Dutch transposition of NIS2, this requirement enters into force on 15 August 2026 for entities falling under the Act.