The Real Reason Your Process Isn’t Working
It’s not the process, it’s how we follow it, adapt it, and act on it.
Before we get started, I want to clarify a common source of confusion: Many people mistake processes for policies, but understanding the difference is (in my opinion) critical. A policy sets the principle or rule: it tells you what should be done and why. A process, on the other hand, describes the steps to achieve it: it tells you how to do it.
Process (how):
A series of actions, steps, or operations directed toward achieving a particular result.
Policy (what/why):
A formal statement of principles, rules, or guidelines adopted by an organization to influence and determine decisions.
For example, a company might have a patch management policy stating that all critical systems must be updated promptly to minimize vulnerabilities.
The process is the series of actions that IT teams follow to implement this policy: identifying vulnerable systems, testing patches in a staging environment, scheduling deployment, verifying installation, documenting the update, and rolling back if needed.
Confusing these concepts can have real consequences. Policies guide decisions; processes operationalize them. Together, they form a framework that is both principled and actionable.
So, with that out of the way, let’s continue.
When something goes wrong in e.g. cybersecurity, it’s tempting to blame the process. “The process didn’t work,” people might say. But here’s the truth:
A process is never at fault.
A process is simply a framework created by us humans. If it fails, it’s probably because it was poorly designed, outdated, or applied without context.
Processes exist to guide, support, and safeguard. They are meant to make complex situations manageable and help organizations respond consistently. Yet in practice, many companies treat processes as rigid rules instead of an adaptable tool. I discussed this mistake in one of my most popular articles, Reference Architecture Explained: What It Is, What It Isn’t, and Why It Matters, where I highlighted how frameworks are intended to guide decisions, not constrain them. When processes are treated as fixed rules, a safeguard can quickly become a blind spot.
The problem often comes down to mindset. In a traditional waterfall approach, processes were built as linear, step-by-step checklists meant to reduce uncertainty in long, sequential projects. But in today’s agile environments, the role of a process must shift: it needs to act as a flexible framework that guides work while leaving space to adapt. A common reason organizations struggle with agile adoption is that they bring old, waterfall-style processes with them. What worked in a sequential model often clashes with the fast, iterative nature of agile. The result is that the very processes meant to bring structure end up becoming bottlenecks.
Why Smaller Companies Move Faster
Smaller firms often appear more agile, innovative, and responsive than large organizations. It’s not that they don’t use processes, but that they keep them as simple and lean as possible, constantly reviewing and adjusting them. This reflects principles like KISS (Keep It Simple, Stupid) and DRY (Don’t Repeat Yourself), both of which highlight that clarity and simplicity usually outperform complexity. especially when speed and clarity matter. The process for updating a process is often short and informal, with decisions revised over a quick chat in the corridor or a discussion at the coffee machine. This flexibility allows teams to react quickly to new information, unexpected problems, or changing priorities. In practice, small firms turn process into a living tool rather than a rigid rulebook, enabling them to innovate and respond faster than organizations weighed down by layers of bureaucracy. But it’s worth remembering that a process is just a process until it becomes a habit.
Processes exist to support the strategy and are not to be viewed as goals in themselves. Define the strategy first, and then create processes to enable it, rather than setting up processes and expecting them to create the strategy. When a process becomes habitual, it reinforces the strategy naturally, but only if it is designed with purpose and continuously adapted to changing circumstances.
Large corporations, by contrast, tend to accumulate processes like layers of sediment. Over time, these processes become focused more on compliance than on actual function. They often slows things down instead of enabling progress.
In cybersecurity, this is more than just a nuisance. An outdated incident response plan or a patching workflow bogged down by approvals does more than waste time. It gives attackers a clear advantage.
Agility and Continuous Review Are Non-Negotiable
The single most important truth about processes is this: they must evolve. A process that is not regularly reviewed and adapted will, sooner or later, become a risk in itself. Far too many organizations cling to outdated checklists or workflows because “that’s the way it’s always been done.” This attitude is not just inefficient, it is dangerous.
As we all know by now, the world around us is changing at a pace we have never seen before. Threat actors develop new tactics constantly. Technology shifts (AI, to name one), infrastructures modernize, and regulations evolve. If defenders are locked into rigid processes designed years ago, they are essentially fighting today’s battles with yesterday’s strategies and attackers thrive on this mismatch. They are not bound by approval chains, committee reviews, or hierarchical sign-offs. They adapt in real time.
To counter this, cybersecurity processes must be agile, responsive, and continuously re-evaluated. A good process should not be a stone tablet carved once and worshipped forever, it should be a living, breathing framework. It should be stress-tested under realistic scenarios, reviewed against the latest threat intelligence, and updated the moment cracks begin to show. Organizations that fail to do this will eventually discover the cost of rigidity: missed warning signs, delayed responses, and preventable breaches. In contrast, those that embed agility and adaptability into their processes build resilience, not just compliance.
A good process should not be a stone tablet carved once and worshipped forever.
Competence Over Hierarchy
One of the most common mistakes I’ve seen over the years is letting job titles, rather than actual expertise, dictate who designs and owns processes. Just because someone holds a senior position doesn’t mean they are closest to the problem or understand the operational details best.
In cybersecurity, this is especially risky. Analysts, engineers, and responders often see where bottlenecks form and how attackers operate. Ignoring their input can leave processes misaligned with reality. This does not mean dismissing leadership or structure, but it does mean authority must be paired with expertise and processes must remain open to revision when evidence shows they are failing.
In practice, however, evidence is often ignored. Sometimes it’s ego, sometimes fear of admitting past mistakes, sometimes hierarchy, or even simple ignorance. But effective risk management demands honesty. Doing what’s right means acknowledging when the world has changed and yesterday’s correct decision is no longer the right one today.
A process should never be protected for its own sake. It should serve the organization’s risk posture. If new information emerges, the right move is to adapt, even if it means admitting that what worked before no longer applies.
Decisiveness Beats Hesitation
Here we can learn from a principle often used in the military: decisiveness is better than hesitation.
A mediocre decision arrived at quickly and executed vigorously is always better than a perfect decision arrived at too late.
In cybersecurity, waiting for the flawless plan often means acting too late, when the damage is already done. Another leadership maxim reinforces the same truth:
In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing.
The lesson for cybersecurity is clear: move, adapt, and correct course as new information emerges. Inaction is not safety, it’s a decision in itself. One that usually benefits the attacker and a good example of this is zero-day exploits. Waiting weeks for the perfect patching plan may feel like risk management, but it leaves systems exposed. Deploying temporary mitigations immediately, then refining the approach as patches and intelligence become available, reduces risk far more effectively.
Or consider incident response. In the heat of a breach, delaying containment while leadership debates optics is often catastrophic. Acting quickly: isolating systems, cutting off attacker access, might not be perfect, but it buys time and control. Cybersecurity favors movement. Attackers don’t wait for you to decide.
Move, Adapt, and Correct (MAC) course as new information emerges, is usually a good process to keep in mind.
Conclusion
Cybersecurity and processes are as much about people and decisions as they are about technology. Processes are not goals in themselves. They are tools to turn strategy into action. If a process slows you down, blinds you to threats, or adds unnecessary friction, it needs to change.
Smaller companies stay agile by constantly questioning and refining their processes. Larger organizations must learn to do the same. Rigidity is vulnerability. Flexibility, guided by expertise and continuous review, is what builds real resilience. Move, adapt, and correct. Let your processes evolve as quickly as the threats you face.
The real reason your process isn’t working is rarely the process itself. It is how you follow it, how you adapt it, and how you act on it. A process only delivers value when it is treated as a living framework rather than a fixed rule. Review it, test it, challenge it, and adjust it as the world changes. In cybersecurity, and in business more broadly, the organizations that thrive are those that embrace this mindset and turn their processes into tools for continuous action and improvement.
“Processes exist to turn strategy into action, not to become goals themselves. Only when a process becomes a routine habit does it truly support effective execution.”