How to protect yourself from the next cyber security threat

Earlier this month, Microsoft confirmed that attackers had exploited a critical vulnerability in SharePoint servers. A patch had already been issued, but it failed to fully resolve the problem. Within days, sophisticated attackers found a way around the fix, compromising thousands of systems.

The flaw was real. So was the patch. The breach happened anyway.

Think of it like finding a crack in a dam, sealing it up, but still waking up to flooding—somehow, the water found another way through.

This was a patch that didn’t stick, and no one caught it in time.

The SharePoint incident shows that vulnerabilities happen in every environment. What matters most is how quickly an organization detects an issue, responds to it, and contains the fallout when something goes wrong.

That response involves different teams working together under pressure.

Vulnerabilities are expected. Effective responses are key.

It’s normal for new flaws to be discovered every day—in code, in third-party dependencies, and in internal tooling. No organization can prevent every vulnerability from appearing.

What’s more important is the ability to respond quickly and effectively when they emerge.

In this case, a fix was assumed to be sufficient when it wasn’t. The vulnerability continued to exist, but there was no immediate signal that the patch had fallen short.

What’s worse is that we know researchers were able to reproduce the vulnerability by examining the difference between versions of the patch Microsoft first gave.

In many companies, a fix gets logged as complete and quietly dropped. Weeks later, the same issue resurfaces because the update never made it everywhere it was needed. No alert, no second check. Everyone thought it was done. It wasn’t.

This points to a deeper challenge in how modern software is secured. When security updates are shipped, the job isn’t over. The team responsible for the system must monitor whether the fix is effective, whether attackers are still probing it, and whether follow-up action is needed.

Organizations that build and ship software must treat response as an ongoing responsibility.

Where companies can improve their response

The SharePoint breach shows how even fast responses can fall short if no one checks whether the fix actually worked. This applies to any organization that manages software, whether internal systems or external platforms (which is the large majority).

These are technical failures, but they’re rooted in human ones: missed signals, misaligned teams, and no agreement on what still needs fixing.

Here are five ways to respond more effectively:

1. Know what’s still exposed

Fixing a problem isn’t the same as removing the risk. Teams need a clear view of which systems remain vulnerable after a patch goes out.

2. Make sure the right people see the issue

Security alerts often sit in tools that developers don’t use (or like to use). Engineers should be able to see and act on what needs fixing without extra steps.

3. Focus on real risk

When every alert looks urgent, the ones that matter get missed. Prioritize what’s actually exploitable and affects the systems you rely on.

4. Follow through after the fix

An exploited vulnerability is rarely a one-time event. Teams should keep an eye on it to confirm the threat is fully contained.

5. Track how long real problems stay open

It’s easy to count alerts. It’s more useful to track how long serious vulnerabilities take to get resolved. That shows whether your response is actually working.

Shifting this mindset takes empathy. The person responsible for security should think about developers in the same way Apple’s product team thinks of their customers. Is the information clear? Is it delivered where they already work? Are we helping them succeed? Or, are we just giving them one more ticket in a backlog that never ends?

And beyond tools, it takes trust. Teams need permission to speak up when something’s unclear, and they need clarity on who owns what.

Clarity is key

The SharePoint breach revealed a blind spot in how teams track, validate, and follow through on the risks they already know about.

Security is failing because teams don’t have the visibility to see what’s still vulnerable, the clarity to focus on what matters, or the workflows to make fixes stick. Without that, speed doesn’t matter, because you’re still exposed.

The organizations that avoid the next breach won’t be the ones who patch the fastest. They’ll be the ones who can see the whole picture, cut through the noise, communicate effectively, and close the loop before attackers get there first.