Most security programs don't fail because they lack tools. They fail because the time between spotting a threat and doing something about it is too long. Defensive agility is really a measure of that gap, and it's shrinking the most in teams that treat security as a loop they run continuously instead of a document they update once a year.
Anant Adya, an executive vice president at Infosys, puts the goal plainly: "As attack surfaces expand, organizations must prioritize risk quantification and identify vulnerabilities to strengthen their security posture and improve their ability to recover from attacks that are inevitable." That last clause is the part many boards still skip. Assuming a breach is coming changes which investments look smart.
Here's a practical way to check where you stand. Pick the last incident your team handled and time each handoff. If the clock ran mostly on waiting, you have an agility problem, not a tooling problem.
Start with zero trust, but treat it as operations
Adya argues that agility starts with a zero-trust approach that continuously verifies access across users, devices, and applications. The point isn't the label. "An effective zero-trust strategy must be embedded into an organization's technology framework and business lifecycle in order to build resilience and foster an organization-wide security mindset," he says.
His more interesting claim is about the business case. Security, he says, has to stop being a protective afterthought and start working as a business accelerant. Teams that bake zero trust into daily operations and AI workflows can move faster on acquisitions and global expansion without piling up architectural debt. That's a harder sell than a compliance checkbox, but it's the argument that gets budget approved.
Clean up the stack before adding intelligence
Sharon Chand, cyber defense and resilience leader at Deloitte, sees the bottleneck in large enterprises that are running old software, custom code, and a patchwork of security tools that don't talk to each other. Each disconnected system adds minutes to containment, and attackers don't wait for the integration project to finish.
Her advice is to audit how the existing stack actually responds to threats, then consolidate toward a more integrated system. Only then does AI pay off. "Security organizations must also have access to AI-driven systems to detect and automate response to machine-speed attacks at the pace of adversaries," she says. Bolting AI onto a fragmented environment mostly produces more alerts to sort through.
Automate the actions you can safely reverse
Randy Gross, CISO at CompTIA, draws a line that many teams haven't drawn yet: decide ahead of time which responses can happen without a person in the loop. His test is simple. "Locking an account, killing a session, or isolating a device should already be automated when confidence is high and the action is easy to reverse," he says.
The reversibility criterion matters more than it sounds. A false positive that locks out one user for ten minutes is a manageable cost. A false positive that takes down a production service at 3 p.m. is not. Automation earns its place on the first kind of action and should stay out of the second until the detection logic has proven itself.
Gross also warns against treating strategy reviews as governance. He recommends reviewing strategy at least quarterly, but in a medium-to-large enterprise, he notes, "agents' permissions and integrations may change frequently, so the guardrails around them must be continuous and automated." Revisit the strategy whenever changes have shifted risk materially, not just when the calendar says so.
His sharpest line is about purpose: "The strategy shouldn't be just to put more AI in the SOC; it should be to reduce the latency between finding a threat and doing something useful about it." Measure the latency, and the AI question answers itself.
Build resilience into the architecture
Jatin Chopra, a senior software engineer at Microsoft, describes the shift from perimeter thinking to something more structural. The goal is an environment that can absorb, isolate, and adapt to anomalous behavior without waiting for a person to intervene. "It marks the transition from static perimeter defense — where you build higher walls — to dynamic, structural resilience where the environment itself constantly shifts to restrict threat propagation."
Chopra's practical point is that approval queues are a hidden form of friction. "When defensive protocols are codified into the architecture rather than enforced by a review board, engineering teams can maintain high developer velocity while inherently restricting the attack surface." In his framing, security stops being a workflow tax and becomes a platform capability that developers get by default.
Shorten the chain of decisions
Bob Maley, CISO at Black Kite, argues that many security strategies die in committee. His prescription is to treat strategy as a continuous loop fed by data the team trusts, and to route decisions to someone who can actually make fast, consequential calls.
His warning is about tempo. Attackers aren't waiting for your review cycle. "When a new vulnerability opportunity lands on a Friday afternoon, nobody on a ransomware crew is waiting for a quarterly review to approve going after it," he says. "If your defense team needs a steering committee before it can react, the gap between their tempo and yours is where the breach lives."
Let automation handle the routine so people can judge
Timur Rakhmatullin, a senior software engineer at Softline Solutions, sees a common failure pattern. Teams build static defenses with rules, alerts, and runbooks, then freeze when reality doesn't match the playbook. "They set up rules, configure alerts, and write runbooks, but then something happens that doesn't match the runbook and everyone freezes."
He runs automated security scans across more than 30 repositories using in-house tools, and he's clear about where the human fits. "The scans catch vulnerabilities, license issues, and other gaps," he says. "But the key part is that any engineer can override a scan result, escalate it, or reclassify a finding in minutes." Automation does the volume. People make the calls that depend on context. As Rakhmatullin puts it, "Humans make the judgment calls."
Rehearse the ugly scenarios
Chris McGlasson, founder of ClearStack Advisory, makes the case for practice. Teams should rehearse difficult scenarios before they arrive. The useful question isn't whether you have an incident plan, but whether everyone knows their role in it. Who patches, who tests, who talks to the business, and who has authority to take a system offline at 2 a.m.?
His recommendation is concrete: "Write it down and run it twice a year." The teams that do this, he says, "treat incident response like a fire drill."
McGlasson points to the recent Citrix situation as a live test. Ongoing critical exploits affected Citrix NetScaler ADC and NetScaler Gateway appliances, and the flaws were critical zero-day exploits. Citrix urged administrators to patch immediately. Many organizations had to set their own timelines, and the ones that moved fastest weren't necessarily the ones with the best tools.
McGlasson's observation is that those teams had already settled the basic questions. "They were the ones that already knew who patches, who tests, and who calls the shots before the advisory ever dropped."
Where to start
If you do one thing this quarter, map your response chain for the three most likely incidents and time each handoff. Then pick the reversible actions you'd trust a machine to take and automate them. Those two steps shorten the gap that attackers exploit, and they generate the evidence you need for the harder work of architectural change.
Agility, as McGlasson puts it, is a muscle. "You build it through repetition."
