In this Black Hat special episode of Risk Grustlers, Nicholas Muy, CISO at Scrut Automation, sits down with Wendy Nather, Senior Research Initiatives Director at 1Password, to tackle a hard truth most security conversations avoid. Not every organization can afford to do security “the right way,” at least not the way frameworks and best practice lists suggest.
Wendy introduces the idea of the security poverty line, the point below which teams simply do not have the resources, time, or clarity to implement the controls they are told are essential. The conversation explores why advice like “go back to basics” often breaks down for small teams, how compliance frameworks can unintentionally widen the gap, and what realistic prioritization actually looks like when you cannot do everything.
Watch the full episode here.
Nicholas: What do you mean by the “security poverty line,” and why does it matter?
Wendy: The security poverty line is a way to describe the minimum level of resources required to achieve acceptable security outcomes. Below that line, teams are not failing because they are careless or irresponsible. They are failing because they literally cannot afford the people, tooling, and time required to meet expectations that were designed with large enterprises in mind.
What makes this dangerous is that we often pretend this line does not exist. We assume that if a control is written into a framework, it must be achievable by everyone. In reality, small organizations are forced to make tradeoffs constantly, and many of those tradeoffs are invisible to auditors, regulators, and even vendors. Acknowledging the security poverty line helps explain why well-intentioned advice does not always translate into real security improvements.
Nicholas: Why does compliance feel especially impossible for smaller teams?
Wendy: Compliance frameworks tend to assume stable environments, clear ownership, and enough staff to separate duties cleanly. Small teams rarely have any of those things. One person may be responsible for infrastructure, security, vendor management, and incident response, all at the same time.
On top of that, scoping is often unclear. A framework might say “protect your assets,” but it does not tell you how to build an accurate asset inventory when everything is cloud based, ephemeral, and constantly changing. The result is that teams feel like they are failing before they even start, not because they lack intent, but because the bar was never realistic for their situation.
Nicholas: People often say teams should just “go back to basics.” Why is that advice misleading?
Wendy: If the basics were easy, they would already be done. Asset inventory, change management, and access control sound simple on paper, but they are extremely hard in modern environments. Cloud infrastructure changes constantly, vendors abstract away visibility, and organizations rely on dozens or hundreds of third parties they do not control.
When we tell teams to go back to basics without acknowledging this complexity, we make it sound ike failure is a personal flaw. In reality, many teams are struggling because the basics themselves have become moving targets. That frustration is part of what pushes people to chase new tools instead of fixing foundational problems.
Nicholas: Your research looks at how much it actually costs to secure an organization. What did you find?
Wendy: One of the most uncomfortable findings is that we do not really know how much “enough security” costs. The answer changes depending on industry, risk tolerance, and architecture, and there is no clear benchmark that small teams can rely on.
What we do know is that security costs do not scale linearly. Doubling headcount or budget does not double security outcomes. This uncertainty makes it very hard for small organizations to plan. They are asked to justify spend without being given a realistic picture of what success even looks like at their size.
Nicholas: You talk about a prioritization pyramid. Where should teams actually start?
Wendy: The pyramid starts with understanding what you have and what you are trying to protect. That sounds obvious, but many teams skip it because it is uncomfortable and time-consuming. Without that foundation, every other control becomes guesswork.
Only after you have clarity on assets and risks does it make sense to talk about controls, tooling, or automation. The pyramid is intentionally designed to slow teams down at the beginning, because rushing into solutions without context often creates more complexity instead of reducing risk.
Nicholas: How do vendors and hidden costs affect teams below the security poverty line?
Wendy: Vendor pricing and complexity can quietly push teams further below the line. Many tools look affordable at first, but require additional staff, integrations, or consulting to be effective. Those costs are rarely obvious during the buying process.
This creates a situation where teams spend money and still feel insecure. They are blamed for poor outcomes, even though the tools they were sold were never realistic for their environment. Transparency around total cost and operational effort would go a long way toward closing that gap.
Nicholas: What do you wish more security leaders and auditors understood about small teams?
Wendy: I wish there was more empathy for constraints. Small teams are not ignoring best practices out of laziness. They are constantly making hard decisions about what not to do so that they can keep the business running.
If we want better security outcomes, we need to meet teams where they are, not where we wish they were. That means clearer scoping, more realistic expectations, and guidance that acknowledges tradeoffs instead of pretending they do not exist.
%201.png){kind=icon}
