---
title: "How frequently is software updated, vulnerabilities patched, unnecessary services disabled?"
url: https://insuranceposture.com/questions/endpoint-and-patching/frequently-software-updated-vulnerabilities-patched-unnecessary-services-disabled
category: "Endpoint protection and patching"
canonical_key: q_edr_005
evidence_state: partial
updated: 2026-08-24
---

# How frequently is software updated, vulnerabilities patched, unnecessary services disabled?

URL: https://insuranceposture.com/questions/endpoint-and-patching/frequently-software-updated-vulnerabilities-patched-unnecessary-services-disabled
Section: Endpoint protection and patching
Evidence state: Partly verifiable from your tenant

Carriers stopped accepting "regularly" some years ago. This question now wants a cadence, and the next one wants a deadline for critical fixes.

## What the carrier is actually asking

The carrier is asking three things bundled together: how often software is updated, how quickly known vulnerabilities are remediated, and whether unnecessary services are disabled. The third element is about hardening, and it is the one most organisations skip when answering.

## Why it is underwritten

Exploitation of known, patched vulnerabilities remains one of the top initial access vectors, which means the loss was preventable with work that had already been published. Carriers price the gap between disclosure and remediation because that window is where their claims originate.

## Where the answer lives in Microsoft 365, Entra ID, and Azure

Cloud workload patch state is directly readable. Endpoint patch compliance comes from your management tooling.

| Platform | Where the setting lives | What has to be true |
| --- | --- | --- |
| Azure | Update assessment and patch compliance across virtual machines | Periodic assessment enabled, with missing update counts rather than an assumption that automatic updates work |
| Azure | Vulnerability assessment on virtual machines and databases | A vulnerability solution deployed and reporting, so remediation has an input |
| Azure | System update recommendations in Defender for Cloud | Outstanding recommendations tracked and closed rather than accumulating |
| Microsoft 365 | Update rings and compliance policies for endpoints | Deployment rings with deadlines configured, so updates install rather than being deferred indefinitely by users |
| Microsoft 365 | Attack surface reduction and baseline configuration | The hardening half of the question: unnecessary features and legacy protocols disabled by policy |

**Deferral is the invisible failure**

Update policies commonly allow users to defer, and a device that has deferred for months looks compliant right up to the point someone checks the installed patch level. Deadlines with enforced restarts are what turn a cadence into a state.

## What a defensible yes requires

- A stated cadence exists per system class, with a shorter path for security updates than for feature updates.
- Patch compliance is measured against the estate rather than assumed from policy.
- Vulnerability assessment feeds the remediation process, so patching is driven by findings and not only by vendor release dates.
- Deferrals have limits and restarts are enforced.
- Hardening is addressed: unnecessary services, legacy protocols, and default features disabled.

## How this answer goes wrong

The gap between policy and state is the recurring theme. Automatic updates are enabled and a third of the fleet has not restarted in two months, so patches are downloaded and not active. The other gap is third-party software: the operating system is current while the browser, the runtime, and the line-of-business application are not, and those are the components with the exploits.

## If this answer turns out to be wrong

Agent coverage, patch state, and end-of-life software are the answers that move fastest without anyone deciding to move them, so this block is where an accurate answer most often ages into an inaccurate one before the policy expires. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [why an accurate answer ages, and when the policy makes that matter](https://insuranceposture.com/glossary/point-in-time-underwriting). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary).

## Frequently asked

### What cadence do carriers expect?

Monthly for routine updates is the baseline expectation, with a much shorter window for critical severity. The next question on most forms asks for that window specifically.

### Does automatic update satisfy this?

Only if you measure the result. Automatic update is a mechanism; patch compliance is the answer, and the two diverge in every real estate.

### Does third-party software count?

Very much so. Browsers, runtimes, PDF readers, and remote access tools are frequent exploitation targets and frequent gaps in patch programmes built around operating system updates.

### What about the hardening element?

Answer it explicitly. Baselines and attack surface reduction rules are concrete, and mentioning them distinguishes your answer from the majority that address patching only.

## Related questions

- [What is the critical patching target (24h / 72h / 7d / >7d)?](https://insuranceposture.com/questions/endpoint-and-patching/critical-patching-target)
- [Does the Applicant use any operating system, hardware or software that is no longer supported / End-of-Life?](https://insuranceposture.com/questions/endpoint-and-patching/applicant-operating-system-hardware-software-no-longer-supported-end)
- [Does the Applicant conduct regular vulnerability scans?](https://insuranceposture.com/questions/network-and-logging/applicant-conduct-regular-vulnerability-scans)
- [Does the Applicant conduct regular penetration testing? In-house or outsourced?](https://insuranceposture.com/questions/network-and-logging/applicant-conduct-regular-penetration-testing-house-outsourced)

---

Insurance Posture by SecValley. https://insuranceposture.com
The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished.
SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact.
Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.
