That game just got a lot more accessible.

This week, Google’s Threat Intelligence Group published a report that will probably be cited in security briefings for years (add to your slides now). For the first time, Google documented a confirmed case of a cybercrime group using artificial intelligence to both discover and weaponize a zero-day vulnerability. This was not done in a lab, or a theory on paper….in the wild, against real infrastructure, with a mass exploitation event just waiting to launch fully. The only reason it didn’t wreak havoc is because Google found it first, quietly alerted and patched by the vendor, and disrupted the operation before it could kick off.

We got lucky. Or rather, the defenders got lucky this time. I wouldn’t count on that pattern holding (I never count on that).

Here’s the short version of what Google found: a prominent cybercrime group, currently unnamed, but described by Google’s chief analyst John Hultquist as having a “strong record of high-profile incidents and mass exploitation” (yikes), used an AI model to identify a previously unknown vulnerability in an open-source, web-based system administration tool. Then they used that AI to build a working Python exploit that could bypass two-factor authentication. The plan, as best as anyone can tell, was mass exploitation campaign, not a targeted small grouping of companies target…pray and spray.

Google figured out that AI was involved not because they caught the group in the act, but because the code itself had AI programming tells. The Python script was full of what Google called “educational docstrings”, the kind of over-annotated, hyper-explained commentary that pops out of a language model like a training manual (or so I’m told). There was also a hallucinated CVSS score embedded in the code (well that sounds like AI to me). For those unfamiliar with a CVSS score it is a standardized severity rating assigned to a real, disclosed vulnerability. This one didn’t exist yet, the AI made it up, wrote it into the exploit code with apparent confidence, and the human operators apparently didn’t notice or didn’t care. The structure itself was, in Google’s words, “a textbook Pythonic format highly characteristic of LLM training data.”

In other words… the code looked like it was written by a very capable student who had read every security textbook ever published but had never actually sat across the table from an older penetration tester who would tell them to cut the commentary and ship the thing. That’s not an actual criticism, it’s a forensic fingerprint (people aren’t that thorough, hackers doubly so). It’s a fingerprint that will get harder to spot as the models get better and write more like we do. (soon they’ll include my spelling errors for me!)

Google says they don’t believe Gemini or Anthropic’s Mythos model was involved. That’s notable, partly because both companies have put meaningful effort into guardrails to stop this kind of thing. Which means the group was using something else (maybe something custom created). The ecosystem of models, including fine-tuned, uncensored, or deliberately weaponized variants, is not exactly limited at this point.

Beyond this specific incident, the Google report documented some other concerning patterns from the same reporting period. Notably that North Korean military hacking group APT45 was observed using AI to test and validate thousands of exploits at scale. Another where a piece of malware called PromptSpy was found using Google’s own Gemini to autonomously navigate Android devices, interpreting what was on-screen and generating commands in real time. Then a separate threat group, TeamPCP, ran a sustained supply chain campaign targeting GitHub repositories for tools like Checkmarx and Trivy, embedding credential stealers directly into the software pipelines that developers trust to make their code more secure. (The irony there is genuinely impressive in the worse kind of way.)

The common thread here is that AI is becoming a force multiplier for the attacker. Not a replacement for human judgment (not yet), but a research assistant, a coding partner, a vulnerability scanner that doesn’t sleep, doesn’t bill by the hour, and doesn’t care about your patching schedule.

I want to be careful here, because the security industry has a well-established tradition of taking every new technology and building a twelve-slide deck about how it will end civilization. We’ve done it with cloud, then we’ve done it with IoT and we’ve done it with machine learning. The threat was always real (I want to be clear), the catastrophizing was always a little much, and eventually the industry figured out how to adapt.

I think this is different, not because AI is magic, not because the attackers are suddenly omnipotent. It’s different because of what it does to the economics of exploitation. The traditional model of zero-day discovery required rare expertise. You needed people who could read code and understand memory allocation and think in terms of the edge cases that developers don’t think about. That talent pool is small, not everyone with a computer could do that. It takes years to develop. It is expensive to acquire and expensive to keep. That expense was a friction that (imperfect as it was) created some natural throttle on how many groups could develop novel exploits from scratch.

AI removes that friction…not entirely, not immediately, and not in every case…. but directionally, it lowers the ground floor. A mid-tier threat actor with access to a capable model and a decent dataset of vulnerability research can now run what amounts to an automated vulnerability discovery operation. The work that used to take weeks from a team of skilled researchers might now take one person and a well-crafted prompt a fraction of that time.

Anthropic’s own CEO Dario Amodei said it plainly… AI has created a window, roughly six to twelve months…for organizations to fix tens of thousands of vulnerabilities that models are now capable of finding. After that, adversaries will be using the same capability at industrial scale, and the window closes.

I don’t know if six to twelve months is exactly right… nobody does (and if they tell you they do…they’re a lair…or in sales) but the direction we’re moving it is not ambiguous.

Let me put on the security leader hat for a moment, because “the threat is evolving” is not a strategy and I’ve often found panic not to be a particularly useful management tool. There are things you can actually do. Things that, frankly, you should be doing anyway… and now you have a very pointed reason to stop deprioritizing them.

First: treat your attack surface like the threat actors already have a better map of it than you do. I say thing because they might. The immediate implication of AI-assisted vulnerability discovery is that the gap between “vulnerability exists” and “vulnerability is known to an attacker” just got shorter. Your traditional assumption…that you have a window between a CVE being published and an adversary developing a working exploit… is no longer reliable. If an attacker can use AI to find vulnerabilities you haven’t disclosed yet, the window between discovery and exploitation can now be (and should be) zero on your side of the equation.

This means your vulnerability management program needs to stop being a queue and start being a triage operation. Not every CVE is equal, not every patch can be deployed in 24 hours. I’ve been in environments where the patch backlog numbers in the thousands, and the team is doing the best they can with the time and resources they have. I understand the constraint for some teams, but the risk calculus just shifted. Anything internet-facing, anything that handles authentication, anything involved in your most sensitive data flows, those need to be at the front of the line, on a compressed timeline, regardless of whether a proof-of-concept has been published yet.

Second: multi-factor authentication is not a finish line. This specific exploit was designed to bypass 2FA. That is not an argument against using 2FA (please, everyone, still use 2FA/MFA) but it is an argument against treating MFA as a solved problem (I’ve been saying this for years). The specific mechanism matters. Time-based one-time passwords delivered over SMS are not the same as hardware security keys. Push notification fatigue attacks are real and documented. MFA configurations that hardcode trust exceptions into authentication flows like the one Google described in this specific case, are the kind of thing that nobody thinks about until somebody finds it from the outside.

A real authentication review looks at how trust is granted, where exceptions have been carved out, and what happens when a session is presented in an unusual way. Most MFA reviews I’ve seen in my past just confirm that a second factor exists…that’s not the same thing.

Third: your AI posture needs a security framework before your AI posture has an incident. I feel like a lot of organizations don’t take security seriously, until after an incident.  I know this is the part where some of you are already nodding because it’s on the roadmap. I know others are nodding because they have no idea what their AI posture actually is and nodding seems safer than admitting it. Both are understandable.

The practical point is this… if your organization is using AI tools, and at this point, if you work in technology, you almost certainly are, you need visibility into which models, which data, which workflows. Agentic AI systems that operate autonomously and have elevated permissions to internal systems are exactly the kind of target the Google report describes as attractive to malicious actors. An agent that can read your source code, execute commands, and access cloud credentials is a very interesting target for an adversary who can manipulate what that agent sees or does. You cannot have a serious conversation about securing AI systems if you don’t know what AI systems you’re running.

Fourth: get your threat intelligence program off the brochure and into practice. Google found this because they were watching. Mandiant and others are watching. The community of threat intelligence analysts who track groups like TeamPCP and monitor dark web leak sites and catalog the techniques of APT45, they do genuinely useful work. The question is… is whether your organization is using that intelligence to inform decisions, or whether the threat intel feeds are generating alerts that go somewhere to be quietly ignored.

In my past I’ve been in environments where the SIEM is alive with telemetry and the threat intel platform is full of indicators of compromise, and yet the security team’s actual understanding of the threat they face is roughly equivalent to reading the newspaper. Detection tells you something happened, understanding tells you what it means in the context of your environment. Those are different investments.

Fifth, and I’ll say this plainly because people don’t say it plainly enough: assume the attackers are already in your environment somewhere. Not because I’m trying to be dramatic. Because this is a foundational shift in how you orient your program. The perimeter model… where your job is to keep the bad guys out…is a comforting fiction that we’ve been letting organizations operate under for too long. If a sophisticated group with AI-assisted vulnerability discovery capability decides your organization is worth their time, the question is not whether they will eventually find an entry point, the question is what they will find when they get there, how long it takes you to notice, and how much blast radius they can generate before you catch it.

Zero trust architecture….network segmentation…least privilege access…comprehensive logging… that covers not just the edge but internal lateral movement. These are not new ideas. They are the right ideas, and they matter more now than they did last week.

Here’s what I keep coming back to. The Google report is being received in a lot of circles as a warning about what attackers can do with AI. And it is that. But it’s also something else. The same capabilities that let a threat actor use AI to find vulnerabilities faster…the code analysis, the pattern recognition, the ability to process massive codebases and identify edge cases…those capabilities exist on the defensive side too. Google is already using AI for exactly that purpose. Mozilla has been using it to find bugs in Firefox. Anthropic built Mythos specifically, in part, for vulnerability research.

The race is real. The attackers have access to AI. So do you. The question is whether your organization is actually using that access to close vulnerabilities, or whether the AI conversation in your boardroom is still mostly about productivity and cost savings and not about the security implications of a world where every attacker now has a research assistant that never sleeps.

I admit I don’t have a tidy answer to that, I wish I did. I think the honest version is that we are in an early and uncomfortable period where neither side has fully figured out how to maximize what AI means for their operation. The attackers are ahead in some dimensions. The defenders are ahead in others and for the next year or two, the gap will widen or narrow based on who moves faster.

The organizations that treat this as a reason to accelerate, to patch faster, to review authentication architectures more thoroughly, to actually operationalize their threat intelligence, I think will be better positioned. The organizations that read the Google report, add it to a file of concerning trends, and wait for their next security assessment to figure out what to do about it will eventually get to explain that choice to someone they really didn’t want to have that conversation with.

The machine that finds the vulnerability is already running. The only question is whose side it’s on when it finds yours.

It is not. And that misunderstanding is the single biggest reason why most zero trust programs produce dashboards instead of security (oh no I went after the dashboards).

I want to be clear about something before going further: zero trust is a genuinely sound security model. The core principles are there, verify explicitly, use least-privilege access, assume breach, are not complicated ideas, and the security rationale behind them is solid and well-established. I want this to be clear this is not a critique of the concept. It is a critique of how organizations approach it, and more specifically, of what they tend to skip over in the rush to implement it (most places).

Zero trust (at its foundation) is a decision about assumptions. Specifically, it is the decision to stop assuming that anything inside your environment is automatically trustworthy. Not your network segments, devices, service accounts and even your users (especially the users). The model says: prove it, every time, in context, with the minimum access necessary to do the job. That is a reasonable thing to want from a mature security program. What it demands in practice is something most organizations have not fully come to terms with.

The first thing zero trust demands is an honest, complete inventory of every identity in your environment. It’s not just your employees. Its identity at every level and it includes contractors, vendors, automated processes, service accounts, APIs authenticating to other APIs, legacy applications running on credentials that were created years ago by someone who no longer works there. I have been in environments where this inventory work alone took months, and not because the tools were inadequate, but because the organization had never asked the question seriously before. You cannot continuously verify access if you do not know who and what is asking for it and most organizations, if they are honest with themselves, have significant gaps in that picture.

The second thing it demands is a working understanding of what you are trying to protect. Zero trust requires that you apply appropriate controls based on the sensitivity of what is being accessed. That means your data classification framework cannot just be a policy document that lives in a shared drive and gets dusted off for audits. It must be operationalized into the actual decisions people make when they build systems, grant access, and respond to alerts. I have seen data classification workshops produce thoughtful, detailed frameworks that were then completely ignored the moment the team went back to their regular work. Zero trust surfaces that gap immediately, because if you cannot define what sensitive looks like, you cannot decide what access to it should look like either.

The third thing, and this is the one that tends to make rooms go quiet, is that zero trust requires your organization to make a genuine cultural commitment to removing implicit trust, including from the people and processes that are most accustomed to having it (the executives who need access to everything). Executives, who find multi-factor authentication inconvenient, so it’s turned off for them. Developers who have had broad production access for years and have never misused it. Business-critical processes that are technically over-privileged but operationally are fragile to change (you sneeze wrong and critical applications break). If you are honest, you’ll realize (or discover during the process) these are not edge cases they are baked into your environment. They are the norm in most mature environments, and they are precisely where zero trust initiatives get quietly neutered.

I have watched zero trust pilots succeed in controlled environments and then stall the moment they start to expand. It’s not because the architecture was wrong, but because expansion required organizational decisions that nobody had made or seriously discussed. Like decisions about who has authority to enforce access controls on privileged users. Decisions about how much friction is acceptable in the name of security. Decisions about what happens when a critical business process conflicts with security controls. Those are governance and culture questions, and no technology deployment answers them.

There is also a sequencing problem worth calling out here. Zero trust is often presented as a destination, but if you understand it, it is more accurately a direction. You do not arrive at zero trust, you move toward it, and how far you can move is constrained by how solid your foundation is. If your identity governance is inconsistent, your microsegmentation project will run into edge cases that stall it. If your logging and monitoring cannot distinguish normal access patterns from suspicious ones, your continuous verification controls will generate noise that engineers eventually learn to ignore (dangerous). Each layer of a zero trust architecture depends on the layer beneath it being reliable. Skipping the foundational work to get to the interesting architectural pieces is a reliable way to end up with a program that looks mature but does not function as one.

None of this means zero trust is the wrong goal (I think we should all be working there). It is the right one, but the path to it runs through some conversations that are less comfortable than a vendor demo (or root canals).

The practical starting point is not an architecture diagram; it is a set of honest (and uncomfortable) questions. What do we actually know about every identity in our environment right now, and where are the gaps? Is our data classification framework real, meaning is it actually reflected in how we build and operate systems, or is it aspirational? Does our leadership team understand and accept the friction that genuine least-privilege enforcement will introduce, or are they expecting a technology purchase to solve the problem invisibly? Who in this organization has both the authority and the organizational support to enforce controls on privileged users when it matters?

Those questions do not have clean answers in most organizations. But asking them honestly, before committing to a zero trust roadmap, is what separates programs that reduce actual risk from programs that produce the appearance of it. The technology to support zero trust has never been better….the tooling is mature, the frameworks are well-documented, and the field has produced real, workable guidance on how to implement it. What the tooling cannot do for you is make your organization ready to have the harder conversation underneath the architecture. That part requires leadership, clarity about what you are protecting and why, and a genuine willingness to apply controls consistently even when it is inconvenient. If you are willing to do that work, zero trust is a meaningful step forward. If you are not, it is a very expensive way to feel like you are.

All of that without understanding of what it really means, isn’t security, it’s just activity and that activity, no matter how busy it looks, doesn’t reduce risk one bit.

Most organizations have invested heavily in detection. SIEM platforms, endpoint detection, network monitoring, cloud telemetry, alerting rules that would make a seasoned analyst pause before clicking “acknowledge.” On paper, it’s everything we’re told that we’re supposed to do. Collect more data, increase visibility and detect faster. None of that is wrong, but somewhere along the way, we started treating detection and understanding as the same thing. They’re not and they aren’t even even close.

Detection tells you something happened, yet understanding tells you what it means in context of your environment. That distinction matters more than most security programs or leaders are willing to admit, because the entire chain of security operations depends on it. When an alert fires, the real question isn’t whether you saw it, it’s whether you knew what to do with that alert.

I’ve been in environments where alerts fire constantly and in high volumes, with high severity, everything looks critical and yet very little of it is really actionable in the way people think. It’s not because the alerts are wrong, but it’s because they have no context to understand what is happening.

I like to think of an alert without context is a smoke alarm going off in a building where nobody knows where the exits are, what’s burning, or if there’s even a fire. While there may be panic at first, eventually people stop reacting. It’s not because they stopped caring, but because they can’t tell what matters. I think that’s where detection fails….and fails quietly, and it’s not the tools, it’s the interpretation. Interpretation requires understanding the environment and what is normal. In most cases that’s a lot harder than deploying a tool.

For example take a suspicious login alert. Now that sounds important, doesn’t it and it probably is, but what makes it suspicious? Is it the location, the time, the behavior, a known pattern? Now let’s add context to that alert. Does that user travel frequently? Is the system publicly accessible? Is there a business process that explains the anomaly? Without context, it’s just a data point, on it’s own not actionable. Yet, with context, it becomes a decision point. That gap is where most programs struggle, because collecting data scales easily but understanding it doesn’t.

The challenge isn’t just that context is hard to build into our programs, it’s just that we’ve built entire programs on the assumption that we don’t need it (purposely or accidentally). We design detection rules around technical triggers and assume the analyst will fill in the rest. We tune our SIEM for coverage and call it done and we measure success by alert volume rather than decision quality. Then we act surprised when our team feels buried.

Security operations has a data problem, we’re excellent at collecting signals and genuinely inconsistent at turning them into real meaning. When meaning is missing, everything looks the same (important, urgent, critical) which is another way of saying nothing stands out. Teams feel overwhelmed, and not because they lack skill, but because they lack clarity.

Alert fatigue is the visible symptom of this, but the damage runs deeper than tired or frustrated analysts. When signals don’t carry enough context to support confident decisions, hesitation sets in. Analysts stop trusting their own judgment, not because they’re wrong, but because the information they’re working with is incomplete. Over time that leads to inconsistency in our programs, where two analysts look at the same alert and reach completely different conclusions, both of them reasonable given what they know. You could argue that neither is wrong and if you’re honest with yourself you know the process is.

Another things to consider is there’s also the delayed action problem. I’m not talking about “we missed it” before taking action, more like “we saw it, we just couldn’t figure out what it meant fast enough to do anything useful.” In most incidents that I’ve talked to my collogues about, the detection wasn’t the failure…the interpretation was. The alert fired like it was supposed to, the team acknowledged it and then they spent the next several hours trying to reconstruct the context that should have been there from the start.

That mistake is an expensive way to operate a security program. The longer it takes to understand an event, the smaller your window to contain it and in security, that window tends to close faster than anyone’s comfortable admitting.

I think that most detection strategies are built backwards. We start with the technology, what can the SIEM detect, what does the EDR flag, what triggers an alert in the cloud environment and then work out from there. That makes sense, that’s understandable, but I also think It’s also a problem.

It comes down to detection logic built around technical triggers without business context tends to generate alerts that are technically accurate but operationally useless. Yes, that login looks anomalous, but is it? Well that depends entirely on what the business was doing at the time. Yes, that process spawned an unusual child process. Should you care? Depends on whether that’s a known behavior in your environment or something that’s never happened before. Every single environment is different, something normal for my environment, might be unusual in yours and cause for alarm.

The missing ingredient is almost always the same, we don’t know what “normal” actually looks like for this specific environment. Not the textbook version of normal. Not the vendor’s baseline. What’s normal for this organization, with these users, with these systems, and these workflows. That knowledge doesn’t come from any tool (at least that I’ve ever seen), it comes from time, documentation, and deliberate effort to understand the environment before you try to detect threats inside it.

I think this is also why threat intelligence programs often underdeliver. I talked about use having a data problem, and the raw intelligence is a data point. To go with my theme if you want actionable intelligence you take that data point and add context. Knowing that a particular threat actor targets organizations in your sector is interesting (bit only mildly helpful). Knowing which of your systems would be most exposed if they came knocking, and what that activity would actually look like in your telemetry, is extremely useful. The gap between those two things is where a lot of threat intelligence programs live permanently.

As I often talk about, I think there need to be a shift in thought, leadership needs to change the question. Instead of asking how many alerts we’re detecting, ask how many we actually understand. That question tends to make people uncomfortable, which usually means it’s a good one.

Understanding requires context, knowing your environment, your users, your systems, your data flows, and what normal actually looks like for your organization specifically. That’s a different investment than buying another detection tool. It’s harder to justify in a budget conversation, and it doesn’t come with a vendor demo…but it’s the work that makes everything else function.

A mature security operations program shouldn’t be measured by how much it detects, it should be measured by how effectively it acts on what it detects. That means investing in context, not just coverage. It means detection logic that reflects how the business actually works, not just what a default framework says to watch for. It means that when an alert fires, the analyst has enough information to make a decision quickly and accurately, not just enough to check a box.

A mature security operation program also means being honest about what you’re actually measuring for success. Alert volume is easy to measure. Mean time to detect is measurable. I think that “Mean time to understand” (which is the actual gap between seeing an event and knowing what it means) almost nobody tracks that (not once have I heard this as a metric). Which is interesting, because that’s the number that tells you whether your program actually works.

Detection and alerting is only valuable if it leads to action. Action only happens when there’s understanding. Otherwise you’ve built a very impressive system that tells you something happened and leaves the rest to chance. Security theatre!

Next time you’re staring at a dashboard full of alerts, ask yourself (and be honest with yourself) are we detecting more, or are we understanding more? One of those reduces risk. The other just looks like it does.

This is not a story about a single incident or a cautionary tale from a breach post-mortem, I (and you) have seen this too many times. This is the operating condition of most modern enterprises, unless audit is in the room…then this never happens. The gap between who “owns” something and who is actually accountable for it is not a mistake. I tend to think, somewhere along the way, is a feature….a unspoken organizational coping mechanism that lets everyone feel responsible without anyone being responsible.

In most organizations, “ownership” means your name is on a spreadsheet. That spreadsheet lives in a SharePoint folder that was last updated within a year (during the audit), and the person whose name appears in the “owner” column may have left the company, changed roles, never told, or simply forgotten that the spreadsheet exists. Asset ownership, system ownership, data ownership…these are concepts organizations love to document and loathe to update or enforce.

The security implications here are not subtle, because when no one really owns an asset, no one is really responsible for patching it, monitoring it, classifying the data it holds, or making the call when something about it looks wrong. The asset responsibility drifts, accumulates technical debt, adds undocumented dependencies, and eventually a vulnerability that someone will have to explain to the board. At that point, ownership suddenly becomes very easy to establish, it belongs to whatever team or whoever is holding the update ticket.

Ownership is generally a label, but the accountability piece is what happens when that label is tested. That distinction matters enormously but also gets collapsed constantly in organizations. You can assign ownership in an afternoon over a cup of coffee, but building genuine accountability, the kind where someone actually feels the weight of a risk decision, that takes intentional governance design, clear authority, and a leadership culture willing to follow through when things go wrong. Most organizations have the spreadsheet, and very few have the culture.

I can hear you scream at that monitor (I can’t really…I just have an active imagination) “The RACI matrix was invented to solve exactly this problem”. Side note: For those unfamiliar, it is a grid where every task or decision gets assigned someone who is Responsible, Accountable, Consulted, or Informed. In theory, it eliminates this ambiguity that I’m talking about. I feel like though in practice, it creates a document that everyone agrees to during a workshop or meeting and no one references again until the next audit (if ever).

The failure piece is not the tool… it’s the mistaken belief that defining accountability in a document constitutes accountability in practice. Real accountability requires two things that a RACI matrix cannot provide. First, the authority to act and second the consequences for inaction. Without those two things, the “A” in the grid is just another label on another spreadsheet.

Security governance can also suffer from this problem as well. Policies get written, controls get documented, and ownership gets assigned, but the authority to actually enforce any of it is fuzzy at best. A CISO can write a patching policy that says critical vulnerabilities must be remediated within 30 days. What happens on day 31 when a business unit has not patched because their application team said it would break something? You going to turn the metric red on another spreadsheet. If the CISO has no authority to escalate (with teeth), the policy isn’t a policy it’s an advisory. The organization is putting on governance theater…all the costumes and set pieces but, none of the plot.

Executive leadership in some companies tend to be surprised by this dynamic during incident response, which is perhaps the most expensive and worse time to learn about it. The conversation that begins with “why wasn’t this patched” rarely ends with a satisfying answer, because the honest answer is that the accountability structure was never designed to make patching anyone who can actually do something’s actual problem.

Organizational psychology (I hate this term exists) has a name for what happens when responsibility is broadly shared…diffusion. The more people who are nominally responsible for something, the less likely any individual is to act on it. The bystander effect plays out in corporate governance with remarkable consistency. When everyone owns the risk, no one loses sleep over it. Compare this to why they recommend during an emergency you point and assign someone to do something (like call 911) versus just asking broadly for someone to do it.

I think that cloud infrastructure has made this worse in ways that are still being fully absorbed. In traditional environments, the boundaries of ownership were reasonably… well physical. A server sat somewhere, and there was someone there who managed it. In modern hybrid and cloud environments, assets spin up and down, teams provision resources without informing IT, and the concept of a “system owner” can become genuinely philosophical. For example who owns a serverless function that was deployed by a developer, runs on infrastructure the security team does not manage, processes data that the legal team hasn’t classified, and touches a third-party API that procurement negotiated? The honest answer is that ownership is ambiguous by design, because the model was optimized for speed and cost, not governance clarity.

None of this is a condemnation of cloud or modern development practices. I love these systems, but it is an observation that the governance models organizations inherited from a simpler infrastructure era have and have not updated to kept pace, and the gap is a security and governance gap. Fixing this does not require a new framework or another governance workshop (I think we have enough of those), but it requires some organizational honesty and a few durable commitments.

The first is to stop confusing documentation with reality, the ownership records spreadsheet, RACI matrices (matixs?, matrixii?), and data classification inventories are useful when they reflect how the organization actually operates (not ideally…really). They are just useless noise when they reflect how the organization wished it operated. Keeping these things current is work…unglamorous, ongoing, detail-oriented work. Organizations that treat it as a one time compliance deliverable will keep discovering the gap in the worst possible moments.

The second is to tie accountability to authority. If a system owner is expected to make security decisions about their system, accepting risks, driving remediation, escalating to leadership, then they need the organizational standing and autonomy to do it. Security cannot function as a team that issues mandates and then politely asks business units to please comply when they feel like it. Authority and accountability have to travel together or neither works.

The third is to make risk visible to the people who own it. One of the persistent dysfunctions in security programs is that risk information lives with the security team while the decisions live with business leaders who never see the data. A business unit director who does not know that their systems are running three years behind on patches has no reason to prioritize fixing it (or usually even the knowledge on how to). Information is the requirement for accountability. If business owners are not receiving regular, intelligible reporting on the security posture of what they own, the governance model has a structural flaw regardless of what the RACI says.

The fourth (and the one executives most reliably resist) is consequences. I am not talking about punitive, reflexive consequences designed to assign blame after incidents, but consequences as a systemic feature of the authority…meaningful escalation paths, visible risk acceptance by named decision makers, and leadership that actually follows through when accountability obligations are not met. Organizations where nothing ever happens when security commitments are ignored have not built accountability. They have built a suggestion system with a compliance aesthetic.

I said at the begining that almost every organization quietly struggles with this, and I want to be precise about the word “quietly.” This is not something that shows up in board presentations or strategic plans. Organizations do not announce that their ownership model is decorative. The gap lives in the spaces between org chart lines, in the meeting where nobody volunteers to take the action item, in the audit finding that gets accepted as a known risk for the fourth consecutive year.

It is quiet because naming it directly is uncomfortable. Saying “we have assigned ownership of this without giving anyone the authority or incentive to actually do anything about it” is an indictment of the governance decisions that leadership made, often deliberately, to avoid the friction that real accountability creates. Real accountability means sometimes the answer is no. It means sometimes a project is delayed because a security gate was not met. It means sometimes someone has a difficult conversation that they would prefer not to have.

Most organizations have decided (sometimes implicitly, sometimes accidentally) that the friction of genuine accountability costs more in the short term than the alternative. That calculation changes reliably and expensively after an incident. The question for every leadership team is whether they want to get ahead of that math or wait to do it under pressure.

The conference room pause… that moment where nobody knows who owns the thing…is not a failure of memory. It is a signal that the organization telling you, clearly, that the accountability structure was never built to survive contact with reality. The solution is not to assign ownership faster, it should be to build a model where ownership means something, where accountability follows authority, and where the gap between the two is treated as the operational risk that it genuinely is…in an incident the spreadsheet is not enough, and honestly it never was.

I think comfort in security programs can sometimes be a signal that something else is happening just beneath the surface. Not failure or negligence….something quieter in the under currents….optimization.

Yet it’s not the kind you want (wait I thought we wanted optimization). Many organizations don’t realize it, but over time their security programs begin to optimize for passing those audits instead of actually managing risk. It doesn’t happen overnight…it’s not intentional (or I’ve never seen it be), no one wakes up and says, “Let’s build a program that looks good instead of one that works.” (If they do…run)

It happens gradually, through incentives, pressure, and the natural human tendency to focus on what gets measured and ignoring what isn’t. Audits measure compliance with the rules and naturally programs optimize for compliance. I shouldn’t need to say compliance, while it’s very important important, is not the same as security. At some point, controls stop being tools to reduce risk and start becoming artifacts to demonstrate that risk is being managed for audits. Documentation becomes the product, evidence becomes the outcome and the actual effectiveness of the control becomes secondary.

While I am guilt of this in my early education, It’s the cybersecurity version of studying for the test instead of learning the material. We can all study to just pass the test, but that doesn’t mean you understand the subject. In my experience one of the most common places this shows up is in policy and control documentation. Policies are written, reviewed annually, approved by leadership, and neatly stored in a repository. Theoretically, they are comprehensive, they cover access control, incident response, acceptable use, vendor management, and more….I dare you to ask any team how often those policies are referenced in day-to-day decisions, and the answer is usually… less impressive…The policy exists….the behavior does not always follow.

I can hear us all think from an audit perspective, the requirement is met…the document exists, approvals are recorded and the review date is current….Check, but is the reality of that document felt?

Another example is access reviews…They are completed on schedule, the appropriate managers certify access, compliance and change reports are generated and the evidence is stored. Everything looks exactly as it should. Yet… if you look closer, very little access is actually removed, but the process was followed and the outcome is unchanged….I’ve talked about this before the review becomes a ritual and rituals, while comforting, do not actually reduce risk.

The same pattern appears in vulnerability management. Systems are scanned regularly, reports are generated, metrics show high percentages of vulnerabilities remediated within SLA and the numbers look strong. In reality not all vulnerabilities carry the same risk, some remediation findings affect systems that are rarely used, others impact critical business functions…if prioritization is driven purely by severity scores without business context, the program may be very efficient at fixing the wrong things…and again, the audit looks good, yet the risk remains.

This is where the disconnect becomes dangerous and risky. When programs optimize for audit success, they start to measure what is easy to prove instead of what is important to understand. I want to state that completion rates, documentation status and control existence are necessary, just want to remind people that none of them, on their own, guarantee security.

Think about any heist movie where the target has “state-of-the-art security.” Cameras are everywhere (no inch unwatched), there are guards at every entrance, and their access controls that look impressive with password and retinal scanner and a little ditty you need to sing to open the secure room….but what happens? The attackers succeed.

This is not because the controls didn’t exist, but because they were predictable, poorly aligned, or focused on appearance rather than effectiveness. The system was designed to look secure….but not actually to be secure. That’s the risk when audit becomes the primary lens, you design controls to pass the audit (appearance) but not really be secure.

I am a fan of audits, audits are essential to run any secure business. They provide the structure, accountability, and external validation to help test and check your program. They help organizations align with standards and regulatory expectations, they are not the enemy (and never should be). Yet like I preach a lot they are not (or should not) be the ending goal, but should be the start.

Security programs that mature beyond compliance understand this distinction. They use audits as checkpoints, not destinations. They design controls that function in real-world conditions, not just in documentation. That requires a different mindset, it requires asking questions that don’t always have clean answers.

Not just “Do we have a control?” but “Does the control work under stress?”
Not just “Is this documented?” but “Is this followed when it matters?”
Not just “Did we pass the audit?” but “Would this hold up during an incident?”

Those questions are harder because they introduce ambiguity and they sometimes reveal gaps that don’t fit neatly into a report…but they are the questions that actually move real security forward. From a leadership perspective, this is where incentives play a critical role. Teams respond to what leadership values and if success is defined by clean audit results, your teams will prioritize audit readiness. If success is defined by risk reduction and resilience, behaviors start to shift and that shift is not always comfortable (and that shows growth).

It means acknowledging that a “passed audit” does not mean “problem solved.” It means accepting that some controls may need to be reworked even if they already meet compliance requirements. It means investing time in areas that are harder to measure but more impactful. I think intellectually this is where the conversations often gets interesting, because optimizing for reality can sometimes create tension with optimizing for audit.

Documentation security can seem simple, but real-world security is messy. It involves tradeoffs, judgment calls, and evolving threats and audits prefer clarity, consistency, and documentation. Bridging that gap requires leadership that understands both perspectives and can combine them without sacrificing effectiveness. I think one way we can do this is by re-framing how controls are evaluated. Instead of asking whether a control exists, evaluate how it performs and instead of focusing solely on completion, examine outcomes or instead of measuring activity, we assess business impact.

Let me give you an example, instead of tracking how many incident response exercises were completed, consider how the team performed during those exercises. Were the decisions made quickly? Were communication clear to not technical partners? Were gaps identified and addressed because of the exercise? That will tell you far more about readiness of your program, than a simple completion metric.

The same applies to access management, monitoring, and vendor risk. The goal is not just to demonstrate that processes are in place, but to ensure they function effectively when needed.

We can’t have a post without mentioning another important aspect is cultural alignment. Security programs that optimize for audit often create environments where people focus on avoiding findings rather than identifying risk. This causes issues to be minimized, edge cases to be overlooked and conversations to become more about presentation than substance.

I hope that is not where you want your program to be. A strong security culture encourages transparency (even when it hurts), it should reward identifying gaps early and it should treat findings as opportunities to improve, not as failures to hide. In security, what you don’t see is usually what hurts you.

Security is not a checklist (but usually has a ton of them)…It is a practice and audits are part of that practice, but they should not define it. The real goal is not to build a program that looks good on paper but to build a program that works when something goes wrong.

Because when an incident happens, no one is going to ask how clean your documentation was….they are going to ask what happened, how you responded, and whether your controls actually made a difference.

And that is not a question you can answer with a checkbox.

Somewhere along the way, we started treating “manager” and “leader” like they mean the same thing and they don’t (at least I don’t think they should) and the gap between those two ideas is quietly shaping careers, teams, and entire organizations in ways we don’t talk about enough.

To set a definition for everyone, to me a manager tells you what to do, but a leader helps you understand why it matters and how to grow beyond it. A manager focuses on output and a leader focuses on development. A manager ensures work gets done but a leader ensures people get better. I hope you can see where I divide the terms, and I’m not saying that a manager is a bad thing.

Both roles exist for a reason, organizations need structure and they need coordination and accountability, but what we’ve done over time is elevate management as the default version of leadership, and in doing so, I think we’ve lowered the bar for what leadership actually looks like.

In my world having a title does not make someone a leader, and not having one doesn’t prevent someone from being one. I’ve had the luck at certain parts of my career to find leaders who weren’t event in my chain of command (so couldn’t call them leaders)…and that’s where mentorship comes in.

Mentorship is the clearest signal of leadership, and it doesn’t follow org charts. It doesn’t care about titles or reporting lines. It shows up in conversations, in guidance, in the way someone invests in another person’s growth without being asked to. Some of the best mentorship I’ve seen hasn’t come from people above me. It’s come from peers. It’s come from people earlier in their careers who had a different perspective, a different way of thinking, or simply the willingness to challenge assumptions. Leadership shows up wherever growth is happening.

That’s what makes it so different from management….”Management” is assigned….”Leadership” is demonstrated and when you start to look at teams through that lens, you begin to see something that’s a little uncomfortable…not everyone in a management role is leading, but that’s not always their fault.

A lot of managers are promoted because they were great analysts, then great engineers or strong individual contributors. They solved problems, they delivered results and they became the “obvious choice” when a leadership role opened up…and then we expect them to lead without ever really teaching them how.

We hand them responsibility for people and assume the skills will follow, we give them a new title and hope they figure it out, we measure them on output, not development and when things don’t go well, we quietly question their leadership instead of questioning the system that put them there without support…because being good at the work is not the same as being good at leading people doing the work.

I’ve had the luck a few times in my career, as I moved up the latter of having some people invest in me for leadership. I’ve been sent to some courses (some good, some just a seminar, and some I thought a waste of my time), but someone invested in me…not just promoted and left to my own devices. In my conversation with that colleague, I admitted I made some mistakes in my early managerial roles, I thought I was a leader (and to a degree I was one), but there was so much more I had to learn…and skills that took years to develop…and as I always am here…a lot a still have to learn…I’m not perfect. (but back to our problem)

Leadership requires a different mindset. It requires patience, it requires listening, it requires the ability to step back from doing the work yourself and instead help someone else grow into it. It requires understanding that your success is no longer defined by what you produce, but by what your team becomes and making sure they get that credit. That transition is not automatic or sometimes easy…and without support, most people default to what they know…They just manage.

They assign tasks, they track progress, they focus on delivery, they ensure things get done (that’s not inherently wrong) but those are necessary functions. Yet when that becomes the entirety of how someone operates, something important gets lost…Growth.

People don’t grow because they were told what to do, they grow because someone invested in them and someone took the time to explain, to challenge, to guide. All because someone saw potential and decided to develop it….That’s leadership. (it’s also where mentorship becomes the differentiator)

A leader mentors because they understand that their role is not just to get work done, but to build capability, a manager who doesn’t embrace that mindset will always operate at the surface level…tasks will be completed…deadlines will be met, but the team will remain dependent, waiting for direction instead of developing autonomy.

That difference compounds over time.

Teams led by managers stay functional.

Teams led by leaders evolve.

But there’s another side to this that we don’t talk about enough, and it’s just as important. Not everyone should be a leader (either not ready, or doesn’t want it)….and that’s okay.

Some people are exceptional individual contributors, they enjoy the work, they take pride in their craft, but they don’t want to manage people, navigate organizational dynamics, or be responsible for developing others…they just want to solve problems, build things, and go deep in their expertise. I took me longer than I would like to realize this.

We’ve created an environment where the only way to advance is to move into leadership roles, more responsibility, more people, more visibility and yes, more compensation…and that causes people to say yes. Not always because they’re ready. Not always because they want to lead. Sometimes because it feels like the next step. Sometimes because it’s expected. Sometimes because they’re chasing a raise….and that’s where things start to break.

Honesty side note, I’ve made this mistake, I took some promotions before I was ready just to chase the promotion latter, and I’ve done this to others to. Now each step I eventually rose to the needs of the role, but in retrospect I sometimes made the jump earlier than I should have…and stunted my growth or been immature in my role….I didn’t have the tool-set yet.

Because leadership isn’t something you can grow into passively. It requires intention. It requires self-awareness. It requires a willingness to shift how you define success. If someone (or you) isn’t ready for that shift, putting them in a leadership role doesn’t just impact them. It impacts everyone around them and this is where organizations play a critical role….Leaders shouldn’t be created out of necessity.

They shouldn’t be promoted just because a role needs to be filled. They shouldn’t be moved into positions of responsibility because they’re the most available or the most convenient choice…that’s how you end up with managers where you needed leaders.

Organizations need to be more deliberate, they need to support new leaders, not just appoint them. They need to provide guidance, mentorship, and development for the people stepping into those roles and they need to create paths for growth that don’t require leadership as the only option.

Because forcing someone into leadership rarely creates a leader, it creates someone trying to survive a role they weren’t prepared for and that’s not fair to them or their team. There’s also a responsibility on the individual side at some point, everyone has to ask themselves an honest question…Am I ready to lead? (and you need to be honest with yourself). Not “Do I deserve the promotion?” Not “Am I good at my job?” But “Am I ready to take responsibility for someone else’s growth?”…That’s a different question, and it requires a different kind of answer.

In my world, I think you can be an amazing analyst and get promoted to engineer or administrator fairly quickly. Yet when you get into the leadership latter and working your way up, each step you should spend more and more time on. For example, if you’re a good supervisor for 2 years (with mentor and leadership training) and get made a manager, then you should spend at least 4 years in management (with mentorship and training…blah) before looking for a director and working your way up. Unless you just want to be a manager…and leader takes time..and each step should take longer to really master that level.

We’re all guilty of looking at our boss at some point thinking they’ve got it easy, and some of us do the interim role where we see all the work that we never saw and the hard decisions they had to make (unless they were just a manager and delegated it all). Every level I’ve ever risen to has it’s own sets of challenges and things I needed to learn and master, it wasn’t just my job but more money…and those steps I needed to master before I was ready to move up.

Because leadership isn’t about authority, it’s about influence, it’s about creating an environment where people improve, where they feel supported, where they are challenged in the right ways, and where they leave better than they arrived…That doesn’t happen by accident and it doesn’t happen just because someone has a title.

The strongest leaders I’ve seen understand this instinctively. They don’t see their team as a list of resources. They see them as people with potential. They invest time. They ask questions. They listen more than they talk. They create space for others to grow, even when it would be faster to do the work themselves.

They mentor.

That mentorship doesn’t stop at hierarchy, it flows in all directions (Up, down, sideways), because leadership isn’t constrained by structure. It shows up wherever someone decides to help another person improve…that’s the shift we need to make.

We need to stop assuming that leadership comes with a title and start recognizing it as a behavior. We need to support managers in becoming leaders instead of expecting it to happen automatically. We need to create environments where mentorship is valued, not optional and we need to be more honest about readiness, both as individuals and as organizations.

Because at the end of the day, the difference is simple.

Managers create output.

Leaders create growth.

If we’re serious about building strong teams, resilient organizations, and meaningful careers, we have to start asking ourselves which one we’re actually developing, because having more managers won’t get us there…having more leaders might.

Don’t get me wrong Mike is, in many ways, invaluable to your organization, but…Mike is also a single point of failure. This is what security architecture looks like when it depends on tribal knowledge, nothing documented, modeled or even consistently understood across teams. Instead, it lives in conversations, experience, and memory. It lives in the heads of the people who were there when decisions were made. That works… until it doesn’t.

Most organizations do not intentionally design their architecture this way. No one sets out to build a system that only a handful of people understand. It all happens gradually growing organically over time. A project gets implemented quickly to meet a deadline and the documentation is created but not updated and the teams change, some people move roles and new systems are added and/or old systems remain because they still work. All this is to say over time, the architecture becomes less of a blueprint and more of a story that has to be told….and stories can change depending on who is telling them.

Ask three different people how a critical system works and you might get three slightly different answers. Not because anyone is wrong, but because everyone sees a different (their) slice of the environment. The network team understands connectivity, the application team understands functionality and the security team understands controls…but holistically very few people understand (or even see) the whole picture.

That gap matters more than most organizations realize, because security architecture is not just about how systems are built… it’s about how they behave under stress, understanding dependencies, the trust relationships, data flows, and failure points. Yet when that understanding exists only in fragments, the ability to respond effectively during an incident becomes limited or chaotic…this is where the problem becomes visible.

During “normal” daily operations, that tribal knowledge feels efficient..you need an answer, you ask the person who knows. You need to make a change to the system, you check with someone who has seen it before. Things move quickly, your decisions get made and the system continues to function. (You know what’s coming next by now)

During an incident, that same model becomes a liability, because incidents do not wait for the right person to be available. Incidents do not respect vacation schedules, do not pause while someone tracks down the one engineer who understands a legacy integration…they unfold in real time, and they demand decisions based on accurate, complete information. If your architecture depends on tribal knowledge, your incident response depends on finding the right person at the right time. Sometimes that isn’t an issue….sometimes they’re hiking the Appalachian trail without cell service.

That is not a strategy (well at least a good one)…that is a gamble. Culture has given us plenty of examples of this dynamic in different stories. There is always that one character in a movie who understands how the system works. You know the person who built it, or who has been around long enough to know its quirks. When everything is going smoothly, they are just part of the background. Yet when something breaks, suddenly they are the most important person in the room. That makes for great (if not sometimes predictable) storytelling, but it does not make for resilient systems.

In real life, that person is not always available, If you are lucky they might just be on vacation or worse case they might have left the organization. Time may have passed and they might simply not remember every detail of a system that has evolved over years and when that happens, the organization is left trying to reconstruct its own architecture and knowledge in the middle of a crisis.

This is where the risk becomes tangible.

Imagine trying to isolate a compromised system without fully understanding its dependencies. You might stop the attacker (yay!), but you might also take down a critical business function (ouch!). Imagine trying to determine data exposure without clear data flow mapping. You may underestimate the impact (or overestimate it) which can create problems for leadership and communication.

Security decisions depend on context, tribal knowledge creates incomplete context in some cases. This issue can also extends beyond “just” incident response into everyday security operations…vulnerability management, for example, relies heavily on understanding system criticality and dependencies. If that knowledge is inconsistent or undocumented, your prioritization becomes guesswork. A high-severity vulnerability on a non-critical system might get more attention than a moderate issue on a system that actually supports core business functions.

The same applies to access control, network segmentation, and monitoring. Controls are often designed based on assumptions about how systems interact. If those assumptions are not validated, updated or consistently understood, controls can be misapplied or bypassed entirely.

The challenge is that tribal knowledge does not feel like a risk that is on most of our radars, we instead we treat it like expertise…and expertise is valuable. Organizations depend on experienced individuals all the time and the goal is not to eliminate that expertise, it is to ensure it is not the only place where critical knowledge exists.

As every article that I write, I think this requires a shift in mindset.

Documentation is often seen as a low priority task (or a task that most of us loathe), it is something teams intend to do “when there is time.”…but here’s the truth there is never time, there is always another project, another deadline, another issue to resolve or fire to put out. So documentation becomes outdated, incomplete, or nonexistent. The result is an environment where the most accurate architecture diagram exists in someone’s head…and that is not sustainable.

Mature organizations treat architectural knowledge as a shared asset, not an individual capability. They invest in keeping diagrams current, map data flows, document dependencies and they ensure that knowledge is accessible, understandable, and maintained over time. Documentation isn’t a silver bullet it is not enough on its own….because documentation can become outdated just as easily as it can be created…the real goal is continuous understanding.

Teams should regularly validate that their understanding of the environment matches reality. Tabletop exercises should include architectural questions, not just response steps. Changes to systems should trigger updates to documentation. New integrations should be reviewed not just for functionality, but for how they fit into the broader architecture…and this is where leadership plays a critical role.

Leaders set priorities, and if documentation and knowledge sharing are treated as optional, they will be ignored. If they are treated as essential components of security and resilience, they will be maintained (even begrudgingly). Us leaders also need to challenge the idea that having “that one person who knows everything” is a strength (it is not), it is a hidden risk that only becomes visible when something goes wrong.

Not everyone needs to know everything, but critical knowledge should not depend on a single individual. Systems should be understandable by teams, not just by the people who built them. This also has implications for talent and team development. When knowledge is shared, teams become more capable. When knowledge is isolated, teams become dependent. Over time, that dependency limits growth, increases risk, and creates bottlenecks.

There is also a cultural element to this, in some work environments, knowledge becomes a form of job security. The more you know that others do not, the more valuable you feel. In security though, that mindset can be dangerous. The goal is not to be the only person who understands the system. The goal is to build a system that can be understood, defended, and managed by the organization as a whole.

Attackers do not rely on tribal knowledge, they rely on discovery. They aren’t asking Mike how something works, they map your environment, identify relationships, test assumptions and they build their own understanding of your architecture, often end up knowing more about systems than some teams…that should be a wake-up call. If an attacker can understand your environment faster than your own teams, the problem is not the attacker, it is the visibility on your end. Security architecture should not be a mystery that needs to be explained, it should be a foundation that can be referenced.

As leaders, we need to move from storytelling to clarity…. from individual expertise to shared understanding… From “ask Mike” to “check the architecture documentation”. Because when the moment comes, and it always does, the question will not be who knows the system best, the question will be whether the organization understands it well enough to respond.

At first the tone of the conversation felt like a victory lap, automation is the buzz of the leadership circles and they all seemed to be making progress. Automation was making everything faster, more efficient and less dependent on manual effort for their teams. It’s the security equivalent of replacing a bicycle with a sports car.

In many ways, that comparison is fair, automation has transformed modern security operations and security teams today are expected to monitor thousands of systems, millions of events, and an attack surface that seems to expand every time a new cloud service appears and without automation, the math simply does not math.

My thought added to the conversation is that speed does not always equal safety and like any powerful tool, automation works best when it is used carefully and well thought out, because sometimes, automation can amplify problems just as quickly as it solves them.

One of the things that came out of that conversation was an observation that stuck with me. Automation often removes friction (that sounds like a good thing), and most of the time that is great, but friction can also serve a purpose, it forces people to slow down, verify assumptions, and think about consequences and when automation removes too much friction, mistakes move faster (even during your busy times).

Consider a common scenario in security operations: An alert fires indicating suspicious activity from an endpoint, maybe a process looks malicious or a command execution pattern matches known attacker behavior. A well-designed automated workflow might isolate the endpoint from the network immediately and that logic is sound, we’ve contained the threat before it spreads and we all want that.

But what happens if the detection rule was wrong?

Instead of a single analyst reviewing the alert and making a decision, the system isolates the machine instantly (which we all would claim that we want). But…If that endpoint happens to belong to someone running a critical system or an executive preparing for a board meeting, the business impact becomes visible very quickly.

Let’s expand that thought a little bigger and imagine that same automation triggering across multiple systems because a detection rule was overly broad and not tuned or tested properly. Congratulations! Your security automation has just executed a denial-of-service attack against your own environment. This is not a hypothetical scenario (well this example is…but many organizations have experienced some version of it.)

Automation does not necessarily make mistakes less likely, it simply makes them faster and more consistent. The same risk appears in vulnerability management if you think about it. Automated patch deployment is often necessary to keep up with the volume of vulnerabilities discovered every week. Without it, security or information technology teams would never catch up, but if patch testing is incomplete or system dependencies are poorly understood, automated remediation can take down critical services just as quickly as it fixes them. Anyone who has ever watched a patch break an application understands this dynamic well.

Automation assumes the environment behaves predictably, but unfortunately, technology environments rarely do. Pop culture offers a good analogy for this. If you have ever watched a science fiction movie where an AI system starts making decisions faster than humans can intervene, you have seen the Hollywood dramatic version of the same principle. The system is not malicious (in some movies it is), but it is simply following its logic faster than anyone expected.

In cybersecurity, our automation is far less cinematic, there are no glowing robots or dramatic countdowns, but the principle is similar. Automated systems follow instructions precisely, and they do it without hesitation or context or situational awareness. That precision is powerful when done right, but is unforgiving when not thought through.

Another area where over-automation can introduce risk is identity and access management. Automated provisioning workflows are a cornerstone of modern identity systems. When someone joins the company, changes roles, or leaves, automation ensures accounts are created, updated, or disabled quickly. In theory, this is exactly what organizations want and every leader will tell you that. If the underlying role definitions are incorrect or outdated (or maliciously changed), automation spreads those mistakes across the entire environment. A flawed role assignment in a manual process affects one user at a time, where the same mistake in an automated process can affect hundreds. Automation does not question assumptions. It scales them.

This is why governance matters so much when automation enters the picture. The more authority you delegate to automated systems, the more important it becomes to understand the logic and the reality behind them. Workflows need guardrails, decisions need context and critical actions need escalation paths.

In many organizations, automation grows organically not part of a well thought out strategy, a script gets written to solve a problem, a few months later another script connects to it to deal with another process and eventually the collection becomes an unofficial workflow system that no single person fully understands and this is where security programs can run into trouble.

Automation that lacks clear ownership becomes difficult to audit, difficult to modify, and even more difficult to trust during incidents. From a leadership perspective, the real issue is not automation itself. Automation is essential and I’m for it wherever it makes sense and the scale of modern infrastructure demands it. Security teams cannot manually review every log entry, manually patch every vulnerability, or manually investigate every alert.

The question leaders should be asking is not whether automation exists but whether it is governed appropriately? Mature automation strategies include visibility into what the automation is doing and why. They incorporate testing (including edge cases) before deployment. They include rollback capabilities when something behaves unexpectedly and most importantly, they ensure humans remain in the loop for high-impact decisions. Automation should support human judgment, not replace it.

A subtle risk with over-automation is the gradual erosion of expertise of your environmental norms. When systems automatically respond to alerts, analysts may become less familiar with the underlying signals. Over time, teams can lose the ability to investigate events manually because the automated workflow has been doing it for them. This can create a dangerous dependency for some inexperienced teams.

If the automation fails or produces unexpected results, the team may struggle to reconstruct what actually happened. In the worst cases, organizations discover during a major incident that the only system that understood the response process was the automation platform itself and usually that realization tends to come at the worst possible moment.

Security leaders should think about automation the same way aviation treats autopilot systems. Autopilot is incredibly useful. It reduces workload and improves consistency. But pilots are still trained to fly the aircraft manually. They understand the underlying mechanics because automation is not infallible.

Security programs should approach automation with the same mindset, use it extensively, use it intelligently, but never assume it eliminates the need for human understanding.

Automation should follow the same governance principles applied to any critical system. It should have defined owners, documented logic, regular reviews, and monitoring to ensure it behaves as expected. It should be tested before major changes and perhaps most importantly, it should be designed with the assumption that something will eventually go wrong….Because something always does (and usually at the worse time).

The irony is that automation is often implemented to reduce operational risk, and most of the time, it succeeds… Security teams become faster, detection improves, response times shrink, but if automation is treated as a magic solution rather than a capability that requires oversight, the same systems designed to protect the organization can create unexpected exposure.

Speed is valuable. Control is essential.

The next time your team discusses a new automation initiative, ask a few simple questions. What decisions is the system allowed to make on its own? What safeguards exist if the logic is incorrect? Who owns the workflow? And if something goes wrong at machine speed, how quickly can you stop it?

Automation is one of the most powerful tools modern security teams have, but like any powerful tool, it deserves respect…the real risk of automation is not that it moves too slowly, but it is that sometimes, it moves exactly as instructed.

Because once the logs start coming in, the story begins to look… strange. One system says the suspicious login happened at 10:02. Another says 9:58. A third system insists it happened at 10:07. The firewall log places related traffic at 10:05. The endpoint agent claims the process started at 9:55. Suddenly, the timeline looks less like a clean sequence of events and more like five different eyewitness accounts of the same event, each confidently insisting they are correct.

At this point, the investigation shifts from answering what happened to answering a far more uncomfortable question….What time is it, actually?

This may sound trivial, and I thought the same thing for a chunk of my career… time synchronization does not exactly headline cybersecurity conference keynotes (and if it did…we wouldn’t attend). No one is putting “NTP configuration strategy” on a motivational poster, but inconsistent system time is one of those quiet technical issues that can quietly undermine an entire security program and rarely noticed (or acted upon) before a security event.

The irony is that most organizations assume they already have it under control…no one really think about it. Ask a room of technology leaders if their systems are synchronized and you will likely get a lot of confident nods. Somewhere in the infrastructure documentation/policy/standards, there is a note that says “all systems use NTP”. So the servers are configured, cloud instances inherit time settings and network devices point to time sources. Everything seems fine….until it isn’t.

The reality is that time drift happens far more often than people realize (or want to admit). Systems reboot, your virtual machines migrate, new containers spin up and down and your cloud environments scale dynamically. In all that complexity network segmentation may block time servers unexpectedly or a team deploys a new system that uses its own default time configuration because they forgot that step or the GPO didn’t apply properly…and suddenly a handful of machines are a few minutes off..and then a few more. Then the gap widens just enough to cause a problem that no one notices until the worst possible moment….that moment is usually during an incident/event/investigation.

Because incident response is fundamentally about reconstructing a story. You are trying to understand how an attacker entered, what they did, how they moved, and when key events occurred. Logs become your evidence. Each entry is a breadcrumb in the timeline. But if the clocks across your environment are not aligned, those breadcrumbs stop forming a trail…they form a puzzle .

Imagine trying to watch a movie where every scene is slightly out of order. The hero shows up before the villain. The explosion happens before the argument that caused it. The ending arrives before the beginning. You can still see the individual scenes, but the story becomes confusing. That is exactly what inconsistent timestamps do to an investigation. If you’ve ever seen the movie memento, the first watch is exactly like this…backwards.

Security teams often assume their biggest challenge during an incident will be detecting the attacker or containing the threat (and during an active attack it is), but when you get to the stage where you’re trying to find out what happened you learn the biggest challenges is simply understanding the order of events. Which activity happened first? Did the suspicious login occur before the privilege escalation or after it? Did the data exfiltration begin before containment measures were applied or afterward? These questions matter because they determine scope, response strategy, and communication with leadership.

When system clocks disagree, those answers become far less reliable (or involve a spreadsheet trying to make the time make sense). This is not just an operational inconvenience, it has real implications for risk management and governance, regulatory investigations, legal discovery, and forensic analysis all depend on accurate timelines. If logs cannot easily be correlated because timestamps are inconsistent, the credibility of your evidence weakens. And in high-stakes scenarios, credibility matters.

Consider a breach investigation where regulators ask how long an attacker had access to sensitive data. If the answer depends on logs from systems that are several minutes apart, the timeline becomes debatable. What looked like a quick containment might suddenly appear delayed. What seemed like immediate detection might actually have occurred later than reported. Small inconsistencies can have large implications when scrutiny increases.

Yet time synchronization rarely gets the attention it deserves (because it’s just time…whats a few seconds here and few minutes there). Part of the reason is that it feels like infrastructure plumbing…it’s not flashy. It does not involve advanced threat intelligence, AI or machine learning. It is the cybersecurity equivalent of making sure the clocks in your office building are set correctly. Everyone assumes it happens automatically somewhere behind the scenes. Like many foundational controls, its importance only becomes clear when it fails.

Inconsistent time does not just affect investigations. It also impacts detection. Security analytics platforms rely heavily on event correlation. They compare activities across systems to identify suspicious patterns. If those events appear out of sequence because clocks differ, detection logic becomes less effective. An alert that should trigger based on a series of events might never fire because the system thinks those events occurred in the wrong order.

Attackers do not need to manipulate this situation intentionally. They simply benefit from the ambiguity.

From a leadership perspective, this is where foundational operational discipline intersects with security maturity. Security teams often focus on high-profile initiatives like zero trust architectures, advanced detection platforms, or cloud security strategies. All of those are important. But they sit on top of infrastructure assumptions that must hold true for everything else to work. Accurate time is one of those assumptions we make without even realizing it.

Without it, your security telemetry becomes less trustworthy. Your incident timelines become less precise. Your ability to explain events becomes weaker and your confidence during investigations becomes fragile.

This is why mature security programs should treat time synchronization as part of their broader operational resilience strategy. It is not just a technical setting, it is an assurance mechanism. Systems should consistently reference reliable time sources. Monitoring should detect drift early and give you time to fix the issue. Critical infrastructure should be one step more resilient by maintaining redundant synchronization paths and teams should periodically verify that timestamps across environments align as expected.

These practices may not generate headlines, but they create the quiet reliability that strong security programs depend on. It is rarely discussed in boardrooms. It does not appear on flashy maturity models. Yet during the most stressful moments of an incident response effort, it can determine whether the investigation proceeds with clarity or confusion.

Leaders do not need to become experts in time protocols to understand the importance of this control. But they do need to ask the right questions. Are our systems consistently synchronized? How do we monitor drift? Do our incident response tools rely on accurate timestamps across environments? And perhaps most importantly, have we ever validated this during an investigation or exercise?

Because assumptions tend to survive until they are tested.

I’m not here to say that lacks in many organizations, and to be fair, many organizations do have a process. In my experience the problem is not the process, the problem is really everything that lives outside of it.

Because identity lifecycle management, in the real world, does not often behave like a neat flowchart. It behaves more like a group chat where half the people are talking, a few are responding late, and someone added a new participant without telling anyone.

This is where the joiner, mover, leaver process works beautifully… until it doesn’t.

Let’s start at the beginning of the process with joiners. New hires are usually well handled, because there is excitement, coordination, on-boarding checklists, and a general sense that everything needs to work on day one (or within the first few weeks). Access gets provisioned quickly, the accounts are created with permissions being assigned. In most organizations that I’ve seen, this is the most mature part of the lifecycle….Which is great, until you realize how much of that access is based on assumptions.

Role-based access sounds clean in theory, yet in practice, roles are often broad, outdated, or designed for convenience rather than precision (plus not zero trust friendly). New hires frequently receive more access than they need “just in case.”, to avoid any friction in their first days, it prevents delays and it keeps the on-boarding experience smooth…. but lets not talk about it quietly introducing risk on day one.

Now let’s talk about movers, and in my experience this is where things start to get interesting. Someone changes roles internally, Maybe it’s a promotion or lateral move or maybe they’re helping out another team temporarily. We all know that the expectation is that their access updates to reflect their new responsibilities. In reality, access rarely gets removed, unless it’s caught in a diligent manager doing access reviews.

Let’s be honest, most of the time it just accumulates.

The employee keeps what they had and gains what they need for the new role (maybe doing some work for their old role until the position gets back-filled..if ever) It feels efficient and avoids breaking anything. It supports flexibility and over time, it creates something far more powerful than intended.

The accidental superuser.

No one planned it, no one approved it as a strategy…it just happened over time, one role at a time.

If this sounds familiar outside of work, it should. It is the same pattern we see in streaming services. You sign up for one for one show, then you need another service for a different show and then another. At some point, you are paying for five platforms and only really watching two, but canceling feels like effort so it continues. I’ve seen to many ads for services to help you identity these services and cancel them.

Access behaves the same way, it is easier to keep the permissions than to remove.

Now let’s get to leavers, which is where most organizations feel confident again. Termination processes are usually well defined, accounts are disabled, badges are deactivated and VPN access is revoked. This is the part that gets the most attention, and rightly so from a security perspective.

Even here in this crucial process, gaps can exist. When we get outside of the normal termination process for employees, we can find issues because not all departures are clean. Contractors roll off without formal off-boarding or are controlled by a central team. Interns may finish programs but retain lingering access because someone forgot to mention to IT. Your third party accounts live outside traditional HR systems and may not have the best documentation are forgotten. Some shared accounts remain untouched because no one is quite sure who owns them. Service accounts continue operating because they are tied to systems, not people.

Those tend to be the “normal leavers” and then there are edge cases like the employee who transfers departments but remains in an old distribution group. The contractor whose access was extended “just for a few more weeks.” The project account that was never tied to an individual. The integration that still has active credentials long after the system it supported was retired.

I want to be clear these are not failures of intent, I’m just as guilty of some of these; they are failures of visibility. Identity lifecycle gaps rarely show up in clean process diagrams, as they exist in the gray areas, the in-between states or the “one time” exceptions. The things that do not fit neatly into joiner, mover, leaver.

And those are exactly the places attackers look (or stumble across). From an attacker’s perspective, identity is the easiest path forward. Why break in and trigger alerts…when you can just log in? Why exploit a vulnerability when valid credentials already exist? The more fragmented your identity lifecycle is, the more opportunities exist for access that no one is actively managing.

This is the part of my post where the conversation shifts from process to leadership. Most organizations treat identity lifecycle as an operational function. Something owned by IAM teams, supported by HR, and reviewed periodically. The impact is strategic, it affects risk posture, audit outcomes, incident response, and overall confidence in your environment.

You cannot claim strong access control if your identity lifecycle has gaps and closing those gaps is not just about tools (despite our hopes we can tool ourselves out of this problem)…like most things it is about mindset.

Leaders need to start asking different questions, not just “Do we have a joiner, mover, leaver process?” (or whatever you organization calls it) but “Where does it break down?”, not just “Are accounts disabled on termination?” but “What access persists outside that flow?”, not just “Who has access?” but “Why do they still have it?”. Because the most dangerous access is not the access you intentionally grant, it’s the access that no longer has a reason to exist.

This is where situational awareness intersects with identity, you need to understand not just identities, but how they evolve over time. What changes, what accumulates and what lingers. That requires visibility across systems, alignment between teams, and a willingness to challenge assumptions…and it also requires ownership.

Every identity, every entitlement, every integration should have a clear owner. Someone accountable for its existence and its lifecycle and understands that entitlement. Without ownership, access becomes orphaned, and orphaned access is one of the most consistent findings in both audits and incidents.

Another overlooked aspect is the human factor. People do not think in terms of entitlements and permissions. They think in terms of getting work done. If removing access creates friction, they will find ways around it. If requesting access is difficult, they will reuse what they already have. Identity programs that ignore this reality tend to create more shadow access, not less.

So the goal should not just be tighter control, but smarter control.

Make access easy to request and easy to expire, make temporary access truly temporary and make ownership visible. When it comes to your normal access review process make reviews meaningful instead of overwhelming and reduce complexity where possible. Translate technical access into business context, because if people do not understand what they are reviewing, they will default to approval.

all that and we are right back where we started.

The illusion of control.

Identity lifecycle gaps are not dramatic, they do not show up with flashing alerts or immediate impact…they build quietly, over time, across roles, systems, and processes…until one day, they are no longer gaps…they are pathways.

Controls are only as strong as their weakest exception….for all of the business functions but especially security. Whether we like it or not identity can full of exceptions. As leaders, we have to move beyond assuming the process works and start validating that it works in practice. That means testing edge cases, reviewing exceptions, challenging accumulated access and creating a culture where removing access is seen as responsible, not disruptive.

Because it is far easier to grant access again than to explain why it was never removed. So the next time someone says, “We have joiner, mover, leaver covered,” take a moment…then ask the follow up question…“What about everything that doesn’t fit into those three categories?” because that is where the real story lives.