We Installed the Security Update and Whether We Were Already Hacked

Your IT person sends a short note on a Thursday afternoon. The security update for the firewall is installed, the website is patched, and everything is back to normal. Most owners read that message, feel relief, and move on. It skips the one question that decides what the problem will actually cost you. Were we already broken into before we installed it?

An update, which the industry calls a patch, closes a hole. It does not tell you whether someone climbed through that hole last week, and it does not remove anything they left behind. A planted login, a tampered order, a hidden email rule or a fake administrator account survives the update untouched. The update fixes the door. It does not search the house.

This post uses four security warnings from the last week of October 2026 to explain what a business in McKinney, Plano, Frisco or anywhere in North Texas should check after the update is done. None of it is technical. It does require asking your IT team a better question than "is it patched?"

Why the Update Does Not Answer the Question That Costs Money

A software company finds a flaw, writes a fix, and ships it. Once you install it, the flaw is gone from that day forward. That is all it promises. It makes no claim about the days or weeks you ran the old version.

That distinction matters because of how attacks really work. When a serious flaw becomes public, criminals start scanning the internet for businesses that have not updated yet. Some flaws are being used in real attacks before the warning is even published. So the time between "the flaw exists" and "we installed the fix" is a window, and anything that happened inside it is your problem whether or not you are now up to date.

The business consequences live entirely in that window. If an attacker got in and left a back door, the update does not close it, so they can return next month. If they changed records, the update does not change them back, so your books, your orders or your payroll stay wrong. If they took data, you may now have legal notification duties, insurance questions and customers to call, and none of that is visible from a version number. A report that says "patched" is good news about the future. It says nothing about the past, and the past is where the bill comes from.

Four Warnings From One Week and What Each One Leaves Behind

The last week of October 2026 is a useful example because four very different warnings landed within days of each other, and every one of them carries the same lesson.

The first was a flaw in Cisco firewalls, the boxes that sit at the edge of your network and run the VPN, short for virtual private network, which is the secure tunnel remote employees use to connect from home. Cisco confirmed attackers were already using it to force the firewall to reboot, which drops every remote worker at once. The obvious cost is lost hours. The less obvious one is that a reboot can wipe the short-term records the firewall was holding, which are exactly the records an investigator would want if something else was happening at the same time. After the update, the question is not only "are we safe now?" but also "did we have any unexplained reboots, and do we still have the records from around them?"

The second was in Drupal Commerce, software that runs online stores. The flaw let outsiders get around the permission checks on orders and payments, and Drupal confirmed it was being used in real attacks. What stood out was the advice that came with the fix. Drupal did not just say "update." It told store owners to audit their orders for inconsistencies. In other words, the damage may already be sitting in your order history as an order marked paid that never was, a discount that should not exist, or a price that does not match your catalog. Installing the update does not fix a single one of those records. Only your finance team reconciling orders against what the payment processor actually collected will find them.

The third was in WordPress, the software behind a large share of small business websites. This one had an ironic twist. The weakness existed during the update process itself, and Wordfence, a WordPress security company, reported blocking nearly 63,000 attempts against it in a single day. At the time it was published there were no confirmed break-ins from this specific flaw, which is good news. Even so, the advice after updating was to look for administrator accounts you do not recognize and plugins you did not install. A plugin is an add-on that gives a website extra features, and an unfamiliar one is a classic sign that someone else has been inside. Our plain-English guide to keeping WordPress plugins under control covers that side in more depth.

The fourth was not a software flaw at all. Researchers at Huntress, a security firm, described a campaign that took over 97 Microsoft 365 accounts at 79 organizations between July and September 2026 by reusing stolen sign-in sessions. There was nothing to update, because nothing in Microsoft was broken. The lesson from that research is the same one, stated even more bluntly. The researchers wrote that a password reset alone does not remove the devices or the MFA methods an attacker registered. MFA, short for multi-factor authentication, is the second step like a code on your phone that proves it is really you. If an attacker added their own phone as your second step, changing your password leaves them with a working key. Our guide to the first 48 hours after a compromised mailbox walks through the full cleanup.

Four products, the same pattern. The fix stops the next attack. Something else has to look for the last one.

The Window Between the Warning and Your Update

How big your window is depends on two dates, and most businesses only track one of them. The first date is when your systems became vulnerable, which is often months or years earlier, because many of these flaws sat unnoticed in the software for a long time. The second is the day you installed the fix. The stretch that matters most runs from the day attackers started using the flaw, which is sometimes before the public warning, to the day your update went in.

Here is a picture of how that plays out. Imagine a 20-person distributor in Allen with a small online store. The store software gets a warning on a Wednesday. The person who built the store years ago is a contractor who answers email slowly, so the update goes in the following Tuesday. That is six days in which the store was exposed while criminals were actively looking for stores just like it. If the owner asks "are we patched?" on Wednesday afternoon, the honest answer is yes. If the owner asks "did anyone change an order during those six days?", nobody knows yet, and that is the question that determines whether the business has a revenue problem.

The same logic applies to a firewall, a website or a mailbox. Write down when the warning came out, when you installed the fix, and whether the flaw was being used in real attacks. A theoretical flaw patched within a day needs a light check. An actively used flaw left open for a week needs a real one.

What to Check After You Patch, in Plain English

You do not need to run these checks yourself, but you should know what they are so you can ask for them by name. They fall into four plain questions.

The first is whether anyone new has a key. That means looking for user accounts, administrator accounts, devices and second-step sign-in methods that nobody on your team recognizes. On a website it is an unfamiliar administrator. In Microsoft 365 it is a phone or computer registered to an account that the employee has never seen. On a firewall it is a login or setting change that does not match a change your team made. Every one of these survives an update, and every one of them is the way an attacker gets back in.

The second is whether anything was changed that should not have been. For an online store, that is the order reconciliation Drupal asked for. For email, it is a hidden inbox rule that quietly moves or deletes certain messages. For a website, it is files that appeared recently, or core files that no longer match the official versions. The goal is simple. Compare what is there against what should be there.

The third is whether you still have the records. Logs are the automatic records that systems keep of who signed in, what was changed and when. If you find something suspicious, logs are how you prove what happened, how far it spread, and when it started. Your insurance carrier will ask for them, and so may an attorney if you have to notify customers. The worst moment to discover that your logs only go back three days is the moment you need four. If the check finds anything at all, the records should be preserved before anyone starts cleaning up, which is the core of digital forensics, the discipline of collecting and reading that evidence properly.

The fourth is whether the same weakness exists anywhere else, such as a second firewall or an old copy of the website nobody remembers. A vulnerability scan, which is an automated check of your systems for known weaknesses, finds the copies you forgot and confirms the update reached everything.

Version numbers alone can mislead in both directions. Whether a Cisco firewall was exposed depended on specific settings, not only the version, so a version-only scan can overstate the risk and a quick settings change can hide it. Our CyberOne platform records the deciding setting next to the version and only closes an item after a retest confirms the fix.

When the Check Finds Something

If the after-the-update check turns up an account nobody recognizes, an order that does not reconcile or a rule nobody created, the situation has changed. You are no longer doing maintenance. You are responding to a compromise, and the order of the next few steps matters.

Preserve before you clean. The instinct is to delete the bad account or fix the bad order immediately, and that destroys evidence. Capture what you found and keep the logs first, then remove the access. Without evidence you cannot answer the questions that drive cost, such as how long they were in, what they touched and whether customer data left the building.

Remove every form of access at once, not one at a time. If an attacker has a registered device, an extra sign-in method and an active session, removing only one leaves the other two working. A partial cleanup tells the attacker they have been noticed without actually locking them out.

Then work out what the business owes. If personal information of Texas residents may have been accessed, Texas law can require you to notify affected people and, at larger scale, the state Attorney General, within set deadlines. Our post on when Texas law says you must notify explains that in plain English. Call your cyber insurance carrier early, because many policies expect prompt notice and may require you to use approved responders. If stolen logins are a concern, dark web monitoring watches the criminal marketplaces where those credentials are traded and tells you if yours show up.

Finally, check whether you can recover cleanly. If a website or server was altered, the fastest way back is often to restore from a known clean copy. That only works if your backups were taken before the attacker arrived, were stored somewhere they could not reach, and have actually been tested. A backup that has never been restored is a hope, not a plan.

What This Costs and Who Should Own It

The after-the-update check is cheap when nothing is found and expensive when it is skipped. A light review takes hours, not weeks. Finding a tampered order six months later, after the customer disputes it and the payment processor has closed the window for a chargeback, costs real money and real trust. Finding a back door after it has been used a second time can cost days of downtime, a larger insurance claim and possibly a renewal at a higher premium.

The bigger issue is ownership. In many small businesses, nobody is responsible for asking whether the window was used. The IT provider installs updates because the contract says so, and the owner assumes installation means safety. If you have one internal IT person, co-managed IT is one way to share that load, with your staff keeping their projects while an outside team takes on the monitoring and the after-the-fact checks.

Whatever arrangement you use, put this sentence in writing with whoever manages your systems. When a warning says a flaw is being used in real attacks, the job is not finished at "patched." The job is finished when someone has checked for new accounts, unexpected changes and missing records across the window, and has told you in plain language what they found. Businesses across Collin County and the wider DFW area hear about these warnings every week. The ones that come through them well are the ones that ask what happened before the fix, not only whether the fix went in.

If you are not sure whether anyone checked your systems after the last round of warnings, call us at 512-518-4408 and we can tell you what a post-update review would cover for your business. You can also start with a free security assessment or contact our team from our McKinney office.

Frequently Asked Questions

If we installed the security update, are we safe from that attack?

You are protected from that flaw from the day you installed the fix forward. The update does not remove anything an attacker left behind before then, such as a new account, a registered device or a changed record. If the flaw was being used in real attacks before you updated, ask for a check of the time in between.

How do I know if we were hacked before we patched?

Look for things that should not be there. That means accounts, devices or sign-in methods nobody recognizes, recent changes nobody made, and records that do not reconcile, such as orders marked paid with no matching payment. Your logs are what make this possible, so confirm they cover the whole period.

Does resetting a password remove a hacker from Microsoft 365?

Not on its own. Security researchers have shown that a password reset does not remove a device or a second-step sign-in method the attacker registered. Sign the account out of every session, reset the password, and remove any unknown devices and sign-in methods together.

How long should a business keep security logs?

Long enough to look back past the gap between a public warning and your update, plus the time it takes to notice a problem. A few days is rarely enough. Ask your IT provider how far back your firewall, email and website records actually go, and whether that matches what your cyber insurance policy expects.