TLDR

We spent Q1 deep in security conversations across a range of industries and organization types. Certain themes surfaced so consistently that ignoring them felt dishonest. This post is our attempt to document what kept coming up, framed as questions your organization should be able to answer heading into Q2. We’ve attached a short checklist at the end if you want the quick version.

We’ll be honest: we came into 2026 with a thesis about where security programs were struggling. Some of what we found confirmed that thesis. A lot of it surprised us.

Over the last three months, conversations kept circling back to a handful of the same problems regardless of who we were talking to, what their industry was, or how mature their security program looked on paper. The specifics changed. The underlying gaps didn’t.

This post isn’t a comprehensive security framework. There are plenty of those, and most organizations have already collected more frameworks than they’ve implemented. What follows is a more modest attempt to document the questions that kept coming up, because we think they’re worth sitting with as you plan the next quarter.

The Vendor List Nobody Has Actually Looked At

Third-party risk came up constantly. That’s not surprising given how much attention it gets in the industry. What was surprising was how often the conversation revealed a gap between the process organizations had and the visibility they thought it gave them.

Most organizations have a vendor risk process. Many have questionnaires, tiering systems, and annual review cycles. What they often don’t have is a clear picture of which third parties have active access to their environment right now, what that access allows, and whether any of it has drifted from what was originally approved.

The checklist question worth asking: Can you produce a current list of every third party with active access to your systems, what they can reach, and when that access was last reviewed?

If the answer requires pulling from three different systems and a spreadsheet someone maintains manually, that’s the gap. The access problem doesn’t live in the questionnaire. It lives in the environment.

The Annual Test That Measured a Moment, Not a Posture

Penetration testing came up more than almost any other topic, and the conversation almost always arrived at the same place: organizations were treating the annual pentest as a security verdict rather than a point-in-time measurement.

A clean pentest report is meaningful. It’s also a snapshot of a specific environment, tested by a specific methodology, at a specific moment. The environment changes the week after the test. New systems come online. Configurations drift. A vendor gets access. The snapshot ages.

The checklist question worth asking: When was your last assessment, and how much has changed in your environment since then? Not in your documentation. In your actual environment.

We’re not arguing that annual assessments are worthless. We’re saying the organizations that treat them as a continuous input rather than an annual checkbox tend to have a clearer picture of their actual posture.

The Legacy System That Everyone Knows About and Nobody Wants to Touch

This one showed up in almost every conversation in some form. Every organization seems to have at least one system that predates the current security team, runs something critical, and hasn’t been meaningfully assessed in years because touching it feels risky.

The instinct to leave it alone is understandable. Modernization is expensive, disruptive, and hard to justify to leadership when nothing has visibly gone wrong. The problem is that attackers don’t share that instinct. Legacy systems tend to have exactly the characteristics that make them attractive: limited logging, outdated authentication, inconsistent patching, and an institutional assumption that they’re too important to probe.

The checklist question worth asking: What systems in your environment have been explicitly excluded from security testing, and do you know why?

The exclusion might be completely justified. But if the answer is “we’ve always excluded it” rather than “we assessed the risk and made a deliberate call,” that’s worth revisiting.

The Incident Response Plan That Lives in a Document

Incident response planning surfaced repeatedly, and the pattern was consistent. Organizations had plans. The plans were documented. The plans had not been tested under anything resembling real conditions.

There’s a significant difference between having a plan and having a team that has practiced executing it under pressure. The first hour of a real incident has a way of revealing which is which. Communication chains that look clean on paper break down when people are working across time zones at 2am. Escalation paths that seem obvious in a document become ambiguous when the person at the top of the chain is unavailable. Containment steps that are straightforward in a tabletop become complicated when the systems involved aren’t behaving the way the documentation describes.

The checklist question worth asking: When did your team last walk through your incident response plan under simulated pressure, and what broke?

If the answer is “we haven’t” or “we ran a tabletop but it was fairly scripted,” the plan may be less operational than it looks.

The Backup Strategy That Hasn’t Been Tested for Recovery, Only for Backup

Ransomware defense came up regularly, and conversations kept arriving at the same distinction: most organizations have invested seriously in backup. Fewer have tested what recovery actually looks like under adversarial conditions.

Backup and recovery are not the same problem. Backup asks whether the data is there. Recovery asks whether you can restore critical systems to operational status within an acceptable window while an incident is ongoing, your team is under stress, and the environment you’re restoring into may not be fully clean. Those are different questions, and the answer to the first one doesn’t tell you much about the second.

The checklist question worth asking: Has your organization tested full recovery from a ransomware scenario, including the decision-making process around what to restore first and how to verify the environment is clean before bringing systems back online?

The Compliance Audit That Passed & the Gaps It Didn’t Find

This was the theme that came up most consistently, and it cuts across everything above. Organizations were passing audits and feeling reasonably confident as a result. When conversations went deeper, it became clear that the audit process and the actual attack surface were measuring different things.

Compliance frameworks are designed to verify that controls exist. They’re not designed to verify that those controls would hold up against an attacker who is actively trying to defeat them. Those are related but distinct questions, and confusing them is one of the more expensive mistakes a security program can make.

The checklist question worth asking: What does your most recent assessment tell you about what an attacker could do, not just about whether your controls are documented?

Q2 Readiness Checklist

A quick reference version of the questions above. These aren’t meant to be exhaustive. They’re meant to be honest.

• Can you produce a current list of every third party with active access to your systems and what they can reach?
• How much has your environment changed since your last security assessment?
• What systems have been excluded from security testing, and was that a deliberate risk decision?
• When did your team last walk through your incident response plan under simulated pressure?
• Has your organization tested full recovery from a ransomware scenario, not just backup integrity?
• What does your most recent assessment tell you about what an attacker could actually do?

These are the questions we kept coming back to over the last three months. We don’t think any organization gets perfect marks across all of them, including organizations with mature security programs and significant security investment. The point isn’t a perfect score. The point is knowing where you actually stand.