At your next IT service review, ask your provider to open one recently completed patching job. Choose a real system that matters to the business. Then ask what was updated, how the work was prioritised and what evidence shows that the update is installed.
This is a practical starting point for a conversation about patch management. You do not need to become the person selecting software updates. Your role is to agree the scope, understand unresolved decisions and know who will act when routine maintenance needs an exception.
NIST describes enterprise patch management as a process that includes finding, prioritising, obtaining, installing and verifying updates. It frames this work as preventive maintenance for technology. That makes a useful basis for a business discussion: what maintenance have we agreed to fund, and how will we know it has been completed? NIST’s patch management planning guide.
The following questions are a suggested agenda for an Australian business reviewing its managed IT arrangements. They are conversation prompts, not a claim that a particular service, product or percentage guarantees security.
1. What exactly is included?
Ask for the agreed scope in plain language. Which laptops, servers, business applications and network devices are included? Which items belong to another supplier? Who owns any equipment outside the agreement?
For your review, request a short scope table with an owner against each category. Include an explicit row for systems whose ownership has not been settled. Ask the provider to identify the information it still needs from your business rather than assuming the inventory is complete.
Take one example from each important business function. For finance, ask about the software used to complete a payment run. For operations, ask about the system used to deliver a customer order. The point of the exercise is to agree what the patching conversation covers before discussing its results.
Finish this section with a decision: who will maintain the list, who will review changes and when will you next reconcile it with your service agreement?
2. How do you decide what happens first?
Ask your provider to explain its priority rules using two examples: a routine update and a vulnerability requiring an urgent response. Request the source advisory, the affected systems, the proposed action and the reason for the proposed timing.
Avoid setting a single deadline during the meeting without first discussing the relevant system and vulnerability. Instead, agree who assesses the situation and who can authorise work outside the normal maintenance window. Ask how that person will be reached after hours and who acts if they are unavailable.
NIST’s enterprise patching practice guide covers routine and emergency patching, alongside inventory capabilities and emergency mitigations. Use that distinction to ask for two procedures your team can actually follow. NIST’s enterprise patching practice guide.
For the urgent example, request a simple sequence: notification, decision, action and confirmation. Agree what you want to receive at each point. A short message naming the affected business service and the decision required is a reasonable format to propose.
3. What happens when an update cannot go ahead?
Ask to see the exception process. For every deferred item, request a named owner, the reason for deferral, the next action and a review date. Ask the provider to distinguish a scheduling issue from a technical problem that requires another supplier’s help.
NIST discusses isolation and other emergency mitigations as possible alternatives to patching. That does not establish which alternative is appropriate for your system. Ask the provider for its recommendation, the supporting vendor guidance and the limits of the proposed measure before agreeing an exception.
For a business application awaiting supplier advice, make the next decision concrete. Who contacts the supplier? When is a response needed? What will the business do if the answer does not arrive? Keep an unresolved item visible in the review rather than recording it as completed maintenance.
4. How will the change be tested and communicated?
Patching can affect service availability, and NIST identifies testing and prioritisation among the practical challenges organisations face. Ask your provider to describe the testing and recovery arrangements for the example you selected at the start of the meeting.
Choose a business task to check after the change. You might nominate signing into an application or completing a representative workflow. Agree who performs that check and how the result is recorded. These are suggested acceptance steps; your provider should adapt them to the actual system.
Discuss communication with the same precision. Who tells staff about the maintenance window? What should staff do if their work is interrupted? Who decides whether to continue or stop when a check fails? Record the contact and decision owner before the next planned change.
5. What proves the work is complete?
Return to the patching job you opened. Ask for evidence of the installed version or successful update, the time it was checked and any remaining actions. Verification belongs in the patch-management process described by NIST; make it a specific part of your requested report.
For a report covering many devices, ask what is included in the count and how devices with no recent result are presented. Request separate entries for completed work, failed attempts and unresolved items. If a restart or follow-up check is still needed, ask who owns it and when it will happen.
Close the meeting with three agreed actions: confirm the scope, assign the outstanding decisions and set the next review date. Keep the evidence alongside those actions so the next discussion can begin with the work you asked to see completed.
For your next managed IT conversation, bring these five questions and one real patching job. Use them to agree the level of detail your business expects from its provider.
Explore Q360’s managed IT services when planning your next provider conversation.