It usually starts with a phone call.
The CEO is in a meeting. The phone buzzes. It’s the company’s bank, or a customer, or sometimes a reporter. Someone outside the company has noticed that something is wrong. Maybe customer data is showing up where it shouldn’t. Maybe payments are going to the wrong accounts. Maybe the company’s name is on a list of recent data breaches that just got published online.
The CEO hangs up. Calls the head of IT. Asks the question every CEO asks in this situation: how did we not see this?
The head of IT is usually just as surprised as the CEO. The security tools are running. The dashboards look normal. Nothing showed up in the alerts. And yet the company has been broken into, and the break-in has been going on for weeks. Sometimes months. Once, in a case I worked on, almost two years.
This is the part of security that nobody likes to talk about. Most companies that get hacked do not find out from their own systems. They find out from someone outside the company. A bank. A customer. A reporter. The FBI. By the time the company knows, the damage is done. The data is gone. The money is gone. The trust is gone.
You would think, after watching this pattern repeat for the last twenty years, that companies would have figured it out. Most have not. The reason most have not is that the way security tools are usually set up has a fatal flaw, and the flaw is so common that most IT teams do not even see it as a flaw. They see it as the normal way to do things.
Here is the flaw. The watchdog is sitting on the same rack as the thing it is watching.
I have been doing security work for a long time, and that one sentence is the most important thing I can teach anyone who runs a company. The security tools are watching your servers. The security tools are also living on the same servers, or in the same cloud account, or behind the same locked door. When the bad guys break in, they break in to everything at once. Including the security tools that were supposed to warn you.
You don’t go blind. You go worse than blind. The dashboards keep showing green lights. The alerts keep saying everything is fine. The reports keep arriving on schedule. None of it means anything anymore, because the attacker has already changed what those tools see and report. You think you are safe because the screens say you are safe. The screens are lying. They have been lying for weeks.
This is the hack you do not know about yet. It is probably running on a server somewhere in your company right now, while you read this. Most of the people who get this phone call had no warning at all. Their teams were doing the same things every other team does. They had the same tools. The same dashboards. The same green lights.
The good news is the fix is not complicated and is not expensive. The bad news is most companies will not do the fix until after the phone call comes.
What an executive should actually ask
You do not need to be technical to find out if your company is in trouble. You need to ask five questions. The answers will tell you most of what you need to know.
One: where does the security system live?
If your security tools and your main servers live in the same place, you have one lock on the front door. Not two. A single stolen password can let the bad guys turn off your security at the same time they break in. The security system needs to live in a different building, with a different lock, owned by a different company, paid for by a different credit card. This is not paranoid. This is basic. Most companies skip it because the other way is cheaper and easier. Most companies are wrong to skip it.
Ask your IT team this exact question: if somebody steals our main cloud password, what does that person have access to? If the answer includes the security tools, you have a problem.
Two: who is allowed to turn off the alarm?
In a real security setup, the people who run the servers and the people who watch the security alerts are not the same people. The reason is simple. If one person can both run a server and silence the alarm on it, that person is a single point of failure. If they get phished, the attacker can break in and turn off the alarm at the same time, using the same stolen credentials.
This is one of the oldest principles in security. It also gets ignored constantly, especially at small and medium-sized companies, because separating those two jobs feels like overkill. It is not overkill. It is the difference between a security team that catches the attack and a security team that gets phished alongside everyone else.
Ask this question: if our top engineer’s laptop gets stolen, what can the thief see, change, or turn off? If the answer is “basically everything,” you have one of the most common problems in modern IT.
Three: can the AI tools push buttons?
A lot of companies have started hooking up AI tools to their security systems. The AI reads the alerts. The AI decides what is real and what is fake. In some setups, the AI even takes action — locking accounts, blocking IP addresses, shutting down servers.
This is a problem.
AI tools are easy to fool. The way you fool them is by writing trick instructions and getting those instructions into a place the AI will read. This is not science fiction. There are working examples of this attack on every major AI tool that exists. An AI that can read attacker-written text and also take action is, basically, a robot guard reading instructions handed to it by the burglar. The robot does what the instructions say. It does not know any better.
AI is genuinely useful in security. It can read mountains of alert logs and write up a summary a human can scan in a minute. That is good. That saves real time. But the AI should never be the one deciding what to do. The decision needs to be a human one, on a deterministic rule, every time.
Ask your team this: in our security setup, can the AI take any action by itself? Or does it just write reports for a person to read? The right answer is the second one. The wrong answer is shocking common.
Four: what happens when one of our servers gets broken into?
This is the question that separates real security teams from ones that are pretending. The answer should be specific. It should have steps. It should include a number — how many minutes from the alert to the response, how many hours to recovery, how many things need to be done in what order.
Most teams do not have this answer. They have ideas. They have a feeling. They might have a document somewhere from two years ago. But have they ever actually done it, with a stopwatch running, on a real server? Almost never.
When a real break-in happens, you do not have time to figure it out. You have to already know. The teams that do this well practice the recovery on a regular basis. They pretend a server got broken into. They run through every step. They time it. They write down what broke. They fix what broke. They do it again next quarter.
The first time a team does this, it goes terribly. Things take three times as long as expected. Half the steps don’t work. Backup systems turn out not to work. Documentation turns out to be wrong. That is the whole point. You want to find these problems during a drill, not at three in the morning during a real attack.
Ask your team when they last did a recovery drill. If the answer is “we did one when we set up the system,” you do not have a recovery plan. You have a wish.
Five: when a server is broken into, do we fix it or replace it?
The right answer is replace it. Always.
Modern attacks leave behind hidden pieces of themselves. The attacker installs things in places nobody thinks to look. They modify the operating system itself. They put backdoors in deep enough that no scanning tool will find them. There is no reliable way to clean a server that has been broken into. Even the experts cannot do it with confidence. The state of the art in hiding things on a server is far ahead of the state of the art in finding them.
So you do not clean. You throw the server away. You build a fresh one from a known-good copy. You restore the data from a backup that was taken before the break-in started. You change every password and key the broken server ever touched. And then you walk away from the original machine and never trust it again.
This sounds dramatic. It is dramatic. It is also the only honest answer. The teams that do this well have practiced it. They have the tools to build a fresh server in an afternoon. They have the backups that go back far enough. They know which passwords to rotate without having to look it up.
Ask your team: if we found out today that a specific server was broken into a month ago, how long would it take us to replace it and restore service? If the answer is more than a day, your team is not ready.
What to do this week
You do not need to know how to set any of this up yourself. That is not your job. Your job is to ask the right questions and demand real answers.
This week, schedule a meeting with whoever is responsible for security at your company. Ask the five questions above. Listen carefully to the answers. Pay attention to which questions get clear, specific responses and which ones get vague hand-waving.
The questions that get clear answers are areas where your team has thought it through. The questions that get vague answers are areas where you are exposed. Both are useful information. The clear-answer areas tell you what is working. The vague-answer areas tell you where to invest.
You do not need to fix all five at once. You need to know where you stand. Most CEOs have no idea where they stand until the phone call comes. By then it is too late to do anything except control the damage.
I have watched the same scene play out at company after company for two decades. The CEO is sitting in the meeting. The phone rings. The voice on the other end says something the CEO never wanted to hear. The CEO walks back into the meeting changed. The next year of the company is going to be about responding to that call.
The thing is, the call is preventable. Not always. Not every time. But most of the time. The companies that prevent it are not the ones with the biggest security budgets. They are the ones who asked these five questions, took the answers seriously, and fixed what needed fixing before something forced them to.
The companies that get the call had the same chance. They just did not use it.
You have the chance right now. Today. Use it.
The phone is going to ring for somebody this week. The only question is whether it rings for you.
