Speed is Built: The Operational Antidote to Urgency Culture

Last year, I wrote about how unchecked urgency gets in the way of quality security analysis. The premise was simple: pressure isn’t the same thing as clarity, and speed without thinking doesn’t lead to better outcomes.

"Anyone can react. It takes true skill and mental prowess to know when to."
- from Urgency: The Silent Killer of Security Analysis

To be clear, it was always meant to be a two-part argument. Over here on The Sec Edit, we see all sides and celebrate nuance. So, let's get into it: speed still matters. We're in security for goodness' sake, of course it does. But my original point also stands: pressuring someone doesn’t automatically result in fast, good security.

Well, what's the alternative? How do we move quickly without sacrificing critical thinking or devolving into headless-chicken chaos?

Urgency is a reaction or a state of being. It's imposed, highly emotional, and typically accompanied by chaos. But speed? Speed is a capability. One that can, and should, be built deliberately.

Teams that move quickly and think critically tend to have three things in place: well-defined processes, meaningful investment in experiential training, and the proper socialization of organization-specific security context. To see what this actually looks like on the ground, let’s follow Sol, our on-call security analyst, navigating these scenarios with and without these capabilities in place.

Documentation: More Than Busywork

As cybersecurity professionals, we're no strangers to the idea that written processes matter. But point me to an organization that consistently makes the time to create and maintain them... Right. It'd be easier to milk a chair. Many of us have joined organizations with no real security maturity plan, no documentation, and no rules; just you, your tools, random KPIs, and the looming threat of a breach, day in and day out. Organizations will gladly shell out for shiny new security tooling, but hesitate to make time to document how the work is supposed to happen. And eventually, we all pay for that decision.

When teams lack clear processes, they lose time in ways that are hard to see but easy to feel. Analysts spend hours consulting coworkers, waiting on leadership input, or second-guessing themselves because there’s no shared understanding of what “right” looks like. Good processes do the opposite: they reduce the number of decisions that have to be made in the moment.

Experience alone doesn’t fix this. Many organizations hope...or assume...that a seasoned security analyst will simply know how to handle whatever comes their way. But while experienced professionals have been to the rodeo before, they don’t know how your organization runs its rodeo. Without documented processes, teams either improvise or get micromanaged by leaders who are afraid of mistakes. Neither approach scales, and neither enables speed. Processes are how organizations preserve institutional knowledge so individuals don’t have to rediscover it under pressure.

To further illustrate:

• Without Documentation: The SOC gets an alert that indicates anomalous PowerShell activity. Sol the Security Analyst spends 25 minutes combing through old ticket history, trying to figure out if their team isolates the host immediately or pages an on-call manager for approval/guidance. With no manager response and zero documented precedent, Sol decides to contain the host...only to get pinged 20 minutes later and reprimanded for taking down an active production machine during peak business hours.
• With Documentation: The playbook states: Isolate host immediately if process X spawns from location Y; create an escalated ticket and ping the manager of team Z. The decision was already made and documented three months ago. Triage time: 90 seconds.

This is how the sausage gets made. By deciding what matters and what to do in advance, teams can exhibit uniformity where it's relevant. Leaders get the information they care about without hovering. Analysts onboard faster because expectations are explicit. Training becomes more cohesive because everyone is operating from the same playbook. Speed emerges not from urgency, but from clarity that’s already in place. There is a reason that NIST frames preparation as the foundation for efficient incident response. Clarity in roles, tooling, and procedures is what allows teams to move quickly when it matters.

Practice Away Your Micromanaging Days

The next step is to encourage your team to practice their skills against your environment. What your staff needs is more experience in securing the environment in front of them. Like I alluded to before, an analyst/engineer can know incident response. They can know malware analysis. They can know containment. But speed depends partly on having practiced applying those skills against your systems, your architecture, your processes, your people, your constraints.

Let me hop on my soapbox again: experience in the industry does wonders for fast ramp up, but it does not make your staff some sort of know-it-alls that can just plug and play in any security environment they see seamlessly. This is a common misconception. By hiring an experienced professional, you're purchasing transferable expertise. That comes with pattern recognition, technical knowledge, judgment, prior experience, etc. But that doesn't include the familiarity and practiced judgment associated with this organization's systems and response expectations. Operational speed still has to be developed.

So, what forms of practice are we talking? Things like drills, simulations, tabletop exercises and other related activities. Simple, right? But in my experience, very few organizations do it, and very few do it right. Is it the funnest thing in the world to be involved in as an analyst/engineer? No. It's a bit nerve-wracking and stress-inducing, but so are real incidents. However, practice gave us somewhere safe to encounter uncertainty before the uncertainty came with consequences. We discovered what part of the procedure didn't work, learned what information we needed, encountered organizational quirks, made mistakes, practiced escalation, and developed familiarity with how an incident actually unfolded in that specific environment. When a real incident happened, we weren't starting from scratch.

Let's go through another illustration:

• Without Practice: A ransomware alert hits. Sol locates the runbook, identifies the infected hosts, and starts the process for containment. But when they try to notify the system owners, they find the escalation list contains two former employees and a shared inbox forwarding emails to...you guessed it! The same two former employees and an engineer that moved to another team a year ago. By the time Sol tracks down a currently employed and relevant on-call engineer, two hours have been burned on internal logistics.
• With Practice: Having hit this exact wall during a drill two months earlier, the team had already cleaned up the escalation paths and tested a dedicated bridge for containment. Sol triggers the tested page, has the verified engineer on the bridge within three minutes, and executes containment immediately.

In my career, I have only worked for one organization that invested time into this. And I understand why. But speed depends on a high level of operational understanding that can only come through repeat exposure. I hope you're seeing the flow here, documentation tells people what "good" looks like. Practice lets them rehearse doing it. Together, those reduce the need for managers to hover. And fewer managers hovering means more time for them to attend meetings, amirite?

Security Context Makes a Unified Front

If you take an older car to a mechanic, I'm pretty sure they could find a million and one things wrong with it. It's up to you with the limited budget to define what to prioritize to the mechanic. In that same way, we as security leaders need to invest time in making sure that everyone has the same understanding of our security context. Which means we ourselves have to have a good understanding of the risks our organization faces, the important assets, the architecture involved, the stakeholders, etc. You can't socialize context you haven't even established.

Why is security context important? Because not everything needs to be handled immediately and with the same scrutiny. Context assists us with prioritizing and knowing what to care about and what to add to our backlog. When Bob or Alice have 30 alerts branded 'critical' going off at the same time, them having a good grasp on security context helps them decide on the fly which 'critical' is most critical. All organizations aren't built the same, and yet we try to act like they are. What's dire to one company is mitigated or transferred in another.

When that security context is established, it is very important to make sure that ALL staff is aligned with it in relevant ways. But for the purposes of this article, we will focus on security teams and how this helps enable speed. Writing things down is only half the battle; institutional knowledge cannot live exclusively in the heads of your senior engineers. We've all been on that one team that runs smoothly until Bob the senior engineer with the junior salary goes on a much-deserved vacation and all hell breaks loose. All of a sudden, no one knows if that weird script hitting the database is Bob's pentest simulation project or an active breach. Does that sound like operational capability to you? It's giving bottleneck to me.

When context is democratized across the team, your analysts stop playing detective just to figure out what a server does, who owns it, or why it matters to the business. For example:

• Without Socialized Context: An alert shows an unusual, high-volume database export at 3:00 AM on a Sunday. Sol, who is on-call, scrambles, initiates high-severity escalation, wakes up two directors, and spends two hours discovering it was just the web design team’s scheduled quarterly backup.
• With Socialized Context: Sol reads the alert, notes the staging environment and remembers that same environment runs an authorized database export on the third Sunday of every month. The web design team had already given an update on their backup schedule weeks prior and it was located in the security team's internal documentation. Sol verifies the associated data (IPs, service account names, timing of the activity), closes the ticket as benign, and moves on to actual threats without waking leadership. Triage time: 3 minutes.

Speed is a Proactive Art, Not a Reactive Flounder

Urgency is a reflex, speed is a discipline. When organizations treat speed as a test of raw individual stamina, they get burnt-out analysts, rash decisions, and expensive blind spots disguised as "fast response."

Real operational velocity doesn't come from pushing people to act faster or panic harder. It comes from having the discipline to write down what "good" looks like, the humility to practice until the flaws reveal themselves, and the foresight to ensure everyone knows the terrain they’re defending. Documentation gives your team clarity. Practice builds their muscle memory. Context gives them permission to act. When those three pillars are in place, you don’t have to demand speed because it's already built.