The SharePoint attacks made patching and recovery one conversation

A server can be running the right update and still need an incident investigation. The July SharePoint warning is a useful example of why those two jobs belong in the same conversation.

What the warning said

On July 14, CISA warned that attackers were exploiting vulnerabilities in on-premises SharePoint Server. Its advisory described remote code execution, stolen IIS machine keys, and activity that could help an attacker maintain access. It urged organizations to apply updates, investigate signs of compromise, and strengthen the way their servers were exposed and monitored. Read the CISA bulletin.

The advisory also gave an important sequence: find and remove intrusion artifacts before rotating machine keys, so an attacker cannot simply steal the replacements. That is a recovery instruction, not just an instruction to install a patch.

Ask two separate questions

My practical recommendation is to give the update and the investigation their own owners. The first question is whether every affected server has the correct fix. The second is whether an attacker used the vulnerability while that server was exposed. One answer cannot stand in for the other.

A small business may rely on a provider for the whole environment. Ask that provider for a short written status: the affected assets, the update applied, the date the update was verified, the logs reviewed, and the conclusion of the investigation. An invoice for patching does not supply all of that evidence.

Make the system list complete

Start with the application people use, then follow its dependencies. Include the administration interface, database connections, service accounts, reverse proxy, and backup process. Record which organization owns each part. A provider handoff is where an overlooked server or credential can disappear from the plan.

Keep the scope precise. This particular warning concerned on-premises SharePoint Server. Establish whether your environment uses that product before applying its instructions to a different service. Product names and hosting arrangements matter when a vendor issues urgent guidance.

Recovery needs a stopping point you can explain

Decide what evidence will let the business resume normal operation. That might include rebuilt systems, rotated credentials, reviewed logs, and a successful restore test, depending on what the investigation finds. Have the incident lead document those decisions and their limits.

For the next urgent advisory, a useful preparation exercise is to find one business application and answer four questions: who owns it, how quickly can it be updated, where are its logs, and how would it be recovered? If those answers take a week to locate, the response plan needs work before the next vulnerability arrives.