Of all ten topics, this is the one attackers are most grateful for when it is not in order: a known vulnerability in a system that has not been updated is the most used route in.
What is a patch policy, and what does on time mean?
A patch policy is a fixed agreement about when updates are installed, with deadlines per urgency. Common for smaller companies: critical security updates within days, regular updates within a month, and automation where possible. "Structurally" is the key word on questionnaires: on a rhythm, not when someone remembers.
Do not forget the peripherals. Firewalls, switches, printers and phone systems run software too, and that software is rarely updated.
Why does a customer want to see my inventory?
Because you cannot secure what you do not know you have. An up-to-date list of hardware and software, with versions and end-of-support dates, is the foundation under the patch policy. Without an inventory, any statement about "everything is up to date" is a guess, and auditors know that too.
While you are at it, think of that one old machine in the workshop still running an outdated operating system because the control software cannot do otherwise.
What if I use software that no longer gets updates?
Unsupported systems are an immediate finding in almost every customer audit. The order is: map out what is end of life, plan replacement, and isolate whatever you cannot replace right away from the rest of the network, so a break-in there goes no further.
Do I need a penetration test?
For most suppliers, a yearly vulnerability scan on everything reachable from the internet is an appropriate answer; a full penetration test is heavier and more expensive and mainly worthwhile if you supply software yourself or run a lot of custom work. What counts is that someone looks periodically and that the outcome is written down somewhere.
How do I know which vulnerabilities affect me?
Not by following everything, because that is work for a security department you do not have. But by switching on two sources that come to you: the security advisories of the vendors whose products you use, and the warnings from the Dutch National Cyber Security Centre, which are public and state in plain language how serious something is.
Tie that to your inventory. The question at every warning is the same: do we have this product, and if so, in which version? With a current inventory that takes a minute; without one it takes an afternoon of phone calls. Briefly record what you concluded each time, including when the conclusion was that it did not affect you; that little log is your evidence that someone looks structurally.
What do I agree with the party doing my updates?
At most suppliers an external managed service provider does the patching, and then the question on the questionnaire is really a question about your contract. Record within what deadline they apply critical updates, that they tell you when something cannot be updated, and that you receive a periodic overview of what was done.
That last one is the document you show your customer. Without reporting you only know that you are paying for it, not that it happened; see also assessing your own suppliers.
Do I have to test updates first?
For workstations and phones, no: there the risks of delay outweigh those of a failed update, and automatic updating is the best choice. For the systems your production runs on it is different, because there an update can cause standstill just as easily as prevent it.
The workable middle ground is a fixed maintenance window, a short check afterwards, and a way back that you know in advance: a snapshot of the virtual machine or a tested backup before you start. That last part makes this topic a twin of business continuity. Where you cannot install a critical update straight away, note what you do in the meantime to limit the risk; that is exactly what an auditor means by "risk-based patching".
This part rarely comes alone: the other nine are on the same questionnaire.