If your business runs SharePoint Server on-premises, patching is not just “IT housekeeping”. When CISA adds a SharePoint vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog, it is a practical signal: attackers are using it in the real world, and you should treat it like a priority business risk.

The tricky part is that SharePoint patching is rarely a one-click job. You need a clear inventory, a clean maintenance window, and a way to prove the farm is actually at the right patch level afterwards.

Start with the why (so the checklist makes sense)

CISA’s KEV Catalog is a curated list of vulnerabilities that have been exploited “in the wild”. It exists to help organisations prioritise what to fix first, even when there are thousands of CVEs competing for attention.

For SharePoint, this matters because:

  • Internet exposure changes the stakes. If a SharePoint web front end is reachable from the internet, you do not get to patch “when things slow down”. Your timeline is driven by real attacker activity.
  • “We patched” is not the same as “we’re protected”. SharePoint updates can be cumulative, but farms can still end up inconsistent (one server behind, a required component missing, config not completed).
  • Patching is also a readiness test. A good patch window proves your backups restore, your logging is usable, and your team can execute a controlled change without surprises.

Checklist 1: Inventory your SharePoint footprint (especially anything internet-facing)

Before you patch, you need to know exactly what you have.

  • List every SharePoint farm and version. Note whether it is SharePoint Server 2016, 2019, or Subscription Edition (SE). Include dev, test, DR, and “old but still running” systems.
  • Identify every server role. Web front ends, application servers, and database servers (SQL) should be documented, with hostnames and IPs.
  • Confirm what is internet-facing. Document the public DNS names that resolve to SharePoint, what firewall or reverse proxy publishes it, and which ports are open.
  • Capture authentication and entry points. Is it classic Windows auth, ADFS, SAML, Entra ID integration, or something custom? Also note any external integrations (workflow tools, third-party web parts, line-of-business systems).
  • Write down who owns what. You want a named owner for: SharePoint, SQL, backups, firewall/WAF, and identity. During a patch window, “who is on point” saves time.

Checklist 2: Confirm what you’re patching for (KEV and Microsoft guidance)

You do not need to become a CVE expert, but you do need to be precise.

  • Check the KEV entry for the CVE(s). Confirm the CVE ID, the affected product, and CISA’s required action.
  • Read Microsoft’s advisory or security update notes. Make sure you have the right update for your SharePoint version and that you understand prerequisites.
  • Decide your deadline and communicate it. For KEV items, set a short internal SLA and tell the business what the maintenance window will look like.

Checklist 3: Pre-maintenance safety checks (backups and logging)

This is the part that prevents a patch from turning into a scramble.

  • Verify you have a recent, restorable backup. Do not stop at “backup succeeded”. Confirm you can restore what you would actually need in a real incident: SharePoint configuration and content, SQL databases, and the servers (or at least the ability to rebuild them).
  • Confirm your RPO and RTO expectations. If SharePoint is down for four hours, what breaks in the business? If you lose one day of SharePoint content, is that acceptable? Get agreement before the window.
  • Make sure logs will be there after the reboot. Confirm you are collecting Windows event logs and relevant SharePoint/IIS logs into a central place (SIEM or log platform) and that retention is long enough to investigate.
  • Take a “before” snapshot of versions. Run a version check across all farm servers so you can prove what changed.

Checklist 4: Patch execution (a controlled, repeatable window)

SharePoint patching is safest when it is consistent and boring.

  • Patch in the right order. Follow Microsoft’s guidance for your SharePoint version and topology. In a farm, you typically patch all servers, then complete the upgrade steps so the farm is coherent.
  • Reboot when required. Plan for it. A “no reboot” patch window is often a fantasy.
  • Complete the post-install steps. If SharePoint requires a configuration/upgrade step after binaries are installed, do it. This is where many “we installed the update” stories fall apart.
  • Watch Health Analyzer and farm status. Use Central Admin and PowerShell to confirm the farm reports a healthy update state, not just that Windows installed something.

Checklist 5: Post-maintenance verification (prove you’re actually patched)

This is where you turn patching into evidence.

  • Confirm patch levels with PowerShell. Use SharePoint’s tooling (for example, Get-SPProduct) to validate the installed product and update versions across the farm.
  • Check every server, not just one. One lagging web front end can keep the vulnerability alive.
  • Validate core user journeys. Test: open a site, search, upload/download a document, and any business-critical workflows or integrations.
  • Review logs for odd behaviour. After a KEV patch, do a quick sanity check for unusual errors, authentication anomalies, or unexpected process activity.
  • Run a small restore test soon after. Even a quick test (restore a database to an isolated environment, or restore a small set of content) increases confidence that you can recover if something goes wrong later.

A simple rule for owners: treat KEV SharePoint items as “patch plus verify”

When CISA flags a SharePoint Server vulnerability as known exploited, the win is not installing an update. The win is knowing exactly which SharePoint servers you have, which ones face the internet, and being able to prove the farm is patched and observable afterwards.

If you would like help inventorying your SharePoint footprint, planning a safe maintenance window, and verifying patch levels, backups, and logging, the Flexnet Networks team can help you run it end to end.

Sources