I heard something on a podcast the other day that’s been rattling around in my head ever since. The hosts were talking about Mike Rowe’s “Safety Third” concept — the idea that safety matters, sure, but treating it as the absolute top priority above everything else can actually make you less safe. Not because safety doesn’t matter, but because the “Safety First” mantra creates complacency. It makes people think someone else is responsible for their wellbeing. It replaces common sense and personal awareness with compliance theater.

And listening to them explain it, I realized we’ve built the exact same problem in information security.

The idea: declaring safety the absolute top priority makes people complacent. They stop thinking critically. They assume someone else made everything safe. That’s when accidents happen.

That’s exactly what we’ve done with “Security First”.

You hear it everywhere. Microsoft says “security comes first when designing any product or service” and tells employees “if you’re faced with the tradeoff between security and another priority, your answer is clear: Do security.” AWS states “cloud security at AWS is the highest priority.” Meta claims “safeguarding your data is our highest priority.”

And just like the safety banners Rowe saw before being asked to do something dangerous, these declarations create a problem: they make people believe someone else is responsible for security. Over time, organizations become convinced that because they’ve said security is first, because they’ve implemented the tools and policies and compliance frameworks, they’re actually secure. They stop looking both ways. They trust that if the process allowed it, it must be safe. And that’s when things go wrong.

Now look — for companies like Microsoft and AWS, maybe “security first” actually makes sense. They’re becoming the world’s infrastructure. Their product is security and availability. But the rest of us? The manufacturers, financial institutions, retailers, healthcare systems? Our business isn’t security. Our business is making things, moving money, serving customers, treating patients. Security enables that mission. It doesn’t replace it.

And yet we keep demanding that security be first. We push for CISOs on boards. We complain that only 12% of S&P 500 companies have board directors with cyber credentials, that 19% of Fortune 500 companies don’t have a CISO. We point out that when Krebs on Security looked at the Fortune 100, only five companies listed a security professional on their executive leadership pages. We act like the problem is that security doesn’t have enough authority, enough budget, enough executive visibility.

But what if that’s backwards? Whether you’re at a Fortune 500 with a CISO reporting to the board or a regional company where security reports to IT, the pattern is the same. What if demanding “security first” and a seat at the executive table is actually the problem—not because security doesn’t matter, but because it makes security someone else’s job? The CISO’s job. The board’s job. The security team’s job. Not everyone’s job.

Maybe we should stop pretending security can actually be first — and start admitting that Security Third is closer to how this really works.

The Complacency Problem

Here’s what Rowe noticed on Dirty Jobs: he kept hearing “your safety is our top priority” right before someone asked him to do something objectively dangerous. Walk up a suspension bridge cable. Test a shark suit. Climb into a bosun’s chair hundreds of feet up. And over time, he and his crew started believing it. They started trusting that someone else had made everything safe for them. They stopped looking both ways before crossing the street because the sign said it was safe to cross.

That’s when people got hurt.

We’ve done the same thing in infosec. I’ve sat in meetings where leaders pointed at me and said “he makes us secure.” I’ve been in new hire orientations where I ask who’s responsible for information security, and the whole room points at me and my team. Once in a while, maybe once a year, someone will say “we all are” — and that’s the only right answer. I’m accountable for the security program. I build the framework, own the tools, manage the team. But every single employee is responsible for implementation.

And yet somehow, despite years of trying different approaches, I still hear “he makes us secure.” I hear it from auditors. I hear it from business units in meetings with vendors. I hear it in leadership meetings. Every time I do, I know I’ve failed. Not because the program isn’t working, but because the entire world keeps saying “Security First” — which translates in people’s minds to “security equals the InfoSec team’s job.” I can stand in new hire orientations all day explaining that security is everyone’s responsibility, but I’m drowned out by every breach notification letter, every vendor pitch, every industry article reinforcing that security is handled by the security people. It’s the exact complacency Rowe warned about — his production crew stopped being careful because someone else on the jobsite was responsible for safety.

And the industry reinforces this everywhere. Tools and policies and training modules (often terrible, hour-long videos that feel like OSHA’s greatest hits from 1987) that create the impression that if you follow the rules, you’re safe. If you’re in compliance, you’re protected. If you click the right buttons on the annual training quiz, you’ve done your part. Security is handled.

But compliance isn’t the same as security. Never has been.

The First Priority Fallacy

Mike Rowe has a way of cutting through the noise on safety that applies perfectly to security. In a post explaining his “Safety Third” philosophy, he poses a question:

Would you be OK if the government reduced the posted speed limits by 50%, required all motorists to wear helmets, and outlawed all left turns? If not, why not? Doing so would save almost 40,000 lives a year.

His point? We’ve already come to terms with the human cost of driving the way we want to drive. We believe, collectively, that 40,000 annual deaths are an acceptable price to pay. We’ve made things safer with seat belts, airbags, and ABS brakes, but we haven’t done all we can to eliminate traffic fatalities. Nor will we. Because when it comes to driving, safety isn’t actually first—we’ve just decided it’s important enough to manage intelligently.

Security works the same way. If security were actually first, businesses wouldn’t function. If we truly put security above all other considerations, we’d shut down internet connectivity, disable email, remove all cloud services, and send everyone home with a pen and paper. We’d achieve perfect security by doing absolutely nothing.

Obviously, that’s absurd. But it exposes the lie in “security first.” What we actually mean is “security is important and needs to be considered in everything we do.” But that’s not as catchy, and it doesn’t fit on a banner.

The problem with ranking values is that you end up with nonsense. If security is first, what’s second? Revenue? Customer service? Innovation? Employee satisfaction? And if those things conflict with security (which they will), do we always sacrifice them? Of course not. In the real world, we balance competing priorities every single day—just like we balance safety against the need to actually get somewhere when we get in our cars.

I’ve sat in countless meetings where someone invoked “security first” to shut down a conversation—except I wasn’t in the room. Early in my tenure at one organization, an executive confronted me: why did I shut down a productivity tool their team desperately needed? I had no idea what they were talking about. I’d been there barely over a year and was still fighting to get invited to meetings. I pressed for details—not to assign blame, but because I needed to know what conversation had happened where I’d outright said no.

There was no conversation. Security never said no. Someone in IT just assumed we would, and killed the idea before it could be evaluated. This is “security first” in action—used as a shield by people who didn’t want to implement another tool, didn’t want to take on the work, didn’t want the risk. Security became the convenient excuse.

I finally convinced the executive to have their business leader approach me directly. They caught me in the hallway, gave me an elevator pitch. My response? “That sounds fantastic and like it would really help the team. Here are the areas I’d watch out for. Can you invite me to the next vendor meeting so we can run through this short list and figure out how to make this happen?” We implemented it. It worked.

Fast forward five years. Same leader, very different scenario. They wanted to upgrade one of their customer-facing systems. This time, my team was on the project from the start. The test servers were built, and we started working through the implementation. That’s when we began peeling back the layers.

First issue: we couldn’t get it to integrate with our authentication system. After troubleshooting, we discovered why—the application required LDAP communication over an unencrypted channel. No LDAPS support, no alternative. Then we looked at the logs. Unencrypted sensitive data everywhere—usernames, passwords, all of it in plaintext. As we dug deeper, we found the tech stack was built on end-of-life .NET components that hadn’t been supported in three years, with no plans by the vendor to update.

It was actually worse than the system currently in production. This “upgrade” was a years-long step backwards in technology and architecture.

I didn’t say no. I wrote a risk assessment. Ranked it against our published risk tolerance statements. We sat down with this business leader and walked through what we’d found. She shut it down herself—because she realized the vendor had sold them six-year-old software disguised as a new upgrade.

Did we lose time? Yes. Did we invest resources in building test environments only to discover it wouldn’t work? Absolutely. But as a project management leader told me recently, “We figured out it wouldn’t work, and we—the company—made the call.” That’s the difference. Security was part of the process, not shoved down anyone’s throat. We provided information. The business made the decision.

People still say security shut it down. But ultimately, it was that business unit leader who made that choice based on the risks we helped her understand. That’s not security first. That’s security in its proper place—informing decisions, not making them.

Here’s the thing: the business exists to do business. To make money, serve customers, deliver value. Security exists to enable that mission, not to replace it. When security becomes the top priority, you’re no longer running a business—you’re running a compliance department with a product attached.

The Human Factor

There’s another problem with “security first,” and it’s the same one Rowe identified with “safety first”: it absolves individuals of personal responsibility.

When you tell people that security is someone else’s job—that the security team, or the tools, or the policies are what keep things safe—they stop thinking critically about their own actions. They trust the guardrails. They assume that if the system let them do something, it must be okay to do it.

But humans are the biggest variable in any security program. Not because they’re stupid or malicious, but because they’re creative, resourceful, and focused on getting their jobs done. And when your security controls get in the way of that, they will find a way around them.

A peer in my industry shared their environment with me: their organization doesn’t allow general web browsing. At all. No Google. No Yahoo. No search engines. Every single website must be explicitly whitelisted before anyone can access it. When I asked how their company researches new products or evaluates vendors, they just shrugged.

Think about what that actually means. You’ve got knowledge workers who need to do their jobs, and you’ve made it impossible to do basic research on company equipment. So what happens? They take work home. They use personal devices. They email documents to personal accounts. They find workarounds—because the business still needs to get done.

The organization thinks they’ve locked down their perimeter. In reality, they’ve just pushed their data outside the perimeter where they have zero visibility and zero control. They’ve made themselves less secure while feeling more secure. That’s the Fort Knox mentality—build the walls so high that your own people have to tunnel under them.

I’ve seen variations of this everywhere. Recent research shows the problem is getting worse, not better. A 2024 CyberArk study found that 65% of employees bypass cybersecurity policies to boost productivity Help Net Security, while 74% said they would bypass cybersecurity guidance if it helped them achieve a business objective Help Net Security. The consequences are predictable: when organizations make security controls too restrictive, hospital technicians share login sessions to avoid five-minute authentication delays Medium, and 75% of information workers share corporate data via personal email and cloud accounts, jumping to 87% for senior managers Software Connect. Healthcare faces particular challenges, where healthcare professionals rely on mobile apps or cloud platforms to manage patient information without following IT security guidelines Reco, contributing to 90% of healthcare institutions experiencing at least one security breach in recent years.

You can’t manage humans the way you manage infrastructure. You can’t firewall rule your way out of human behavior. And trying to do so—building tighter and tighter controls, more and more restrictions, deeper and deeper monitoring—doesn’t make you more secure. It makes you more brittle. Worse, it drives risky behavior underground where you can’t see it, can’t measure it, and can’t help mitigate it.

The alternative isn’t to give up and let chaos reign. It’s to recognize that security works best when it enables work, not when it becomes an obstacle to overcome. Instead of asking “can we do this securely?” start asking “how can we do this securely?” That’s a subtle change, but it completely reframes the relationship between security and the business. You’re no longer the Department of No. You’re a partner in finding solutions.

That’s what Security Third actually looks like in practice. Not security as an afterthought, but security as a realistic, balanced consideration alongside the other priorities that keep the business running. When security becomes something people work with instead of around, you’ve actually made your organization more secure.

What Security Third Actually Means

Let me be very clear: Security Third doesn’t mean security doesn’t matter. It doesn’t mean we should ignore risks or abandon controls or let compliance slide. It means we need to be honest about what security actually is.

Security is not a state you achieve. It’s not a checklist you complete. It’s not something someone else does for you. Security is a practice. It’s a way of thinking. It’s a continuous process of understanding risk, making informed decisions, and staying aware of what’s actually happening in your environment.

When I joined a company to build their first formal information security department, they already had some security components in place—mostly unmanaged, but they existed. One of those components was security training. During my own onboarding, I sat through an almost hour-long video on phishing and other security topics. It was painful. Think those OSHA safety videos from the ’80s and early ’90s—bad acting, outdated scenarios, the kind of thing that makes you want to check your watch every three minutes.

I died a little inside watching it. And in that moment, building a real security awareness program jumped from somewhere in my top 20 priorities to my top 5.

The first thing I did was kill that video. Instead, I built a presentation and showed up in person to every single new hire class. For almost five years, I personally delivered security awareness education to every new employee on their first day. We also had computer-based modules and other training components, but even to this day, during new hire orientation, one or two members of my team are in that room talking through security awareness in person.

And every year for the last few years, our Training Department has tried to take my hour-long slot down to 30 minutes. Or 15 minutes. I get it—they’re trying to streamline onboarding, make it more efficient. So every year, we have a conversation about what we’re actually trying to accomplish. Is the goal to check a compliance box, or is it to actually change behavior? Because if it’s the former, cut me to 15 minutes and run a video. If it’s the latter, here’s why we need that hour. Every year, they’ve agreed that effectiveness matters more than efficiency. And every year, I’ve kept that hour.

Because cutting it down and relying solely on computer-based modules is compliance theater. It’s not effective security awareness. It’s checking a box so someone can say “we did training.” That’s the “security first” mentality in action—treating security as a requirement to satisfy rather than a practice to build.

Not because it scales better than a video—it doesn’t. But because it works better. When you’re in the room, it becomes a conversation instead of a compliance checkbox. People ask questions. They share concerns. They start thinking about security as part of their job, not as something the security team handles for them. They report suspicious emails not because they’re required to, but because they understand why it matters.

That’s Security Third. It’s the recognition that security works best when it’s embedded in everything you do, not when it’s treated as the top priority that overrides all other considerations. It’s about being present, being practical, and being honest about what actually makes people more secure.

The Organizational Implications

Here’s where this gets uncomfortable for a lot of security practitioners: if security isn’t first, then we’re not the most important team in the organization. We’re not the final word on what does or doesn’t happen. We’re advisors, partners, enablers—not gatekeepers.

And that’s hard to accept, especially in an industry that’s spent the last two decades trying to get a seat at the table, trying to get executive buy-in, trying to get budget and headcount and authority. We’ve fought to make security matter. And now I’m suggesting we need to step back?

Not exactly. I’m suggesting we need to be honest about what matters and why. Security matters because the business matters. The customer data we hold matters. We protect things because those things have value. We manage risk because unmanaged risk threatens the mission. But we’re not the mission itself.

This has real implications for how we build programs. It means we can’t design security architectures in isolation from business needs. It means we can’t implement controls just because they’re best practices or compliance requirements. It means we need to understand what the business is actually trying to do and figure out how to make that happen securely, not how to make it so secure it can’t happen at all.

And here’s where I need to be honest: I haven’t figured this out.

I’ve worked in organizations where security is “first” in theory but last in practice. Where every project timeline includes a buffer for “security delays.” Where business units hide initiatives from security until the last possible moment because they assume we’ll kill them. Where we’re perpetually fighting fires because we’ve lost visibility into what’s actually happening. Some parts are good, some parts are terrible. Others improve after a breach forces the conversation. Some are better because leadership genuinely gets it. It’s always a mixed bag.

I’ve explained repeatedly that we need to be in the strategic planning sessions—not the big end-of-year kickoff where decisions are already made, but the early meetings where the business starts making tactical decisions about new markets, new initiatives, new directions. That’s where security needs a seat. Not to say no, but to start thinking ahead. If I know the business is moving into a new market or launching a new product line, I can start planning—mentally, architecturally, in my own year-over-year roadmap. What tools will we need? What knowledge should my team develop? What risks should we be ready to address?

But more often than not, despite executives saying “we take our customers’ data security seriously,” I’m left out of those conversations. And I’m back in reactive mode: “Oh, this business unit just bought X? Oh crap. Okay, let me figure this out.”

I still don’t have a perfect answer for how to fix this. In the last few years, it’s gotten better—but not because leadership suddenly decided security should be first. Other business units started complaining that they didn’t know what was happening across the organization. The contact center finds out sales launched something new when customers start calling about it. Marketing discovers a new product line exists when the contact center asked what sales did and to get the marketing literature for it. When leadership started fixing that broader communication problem, security got pulled into those earlier conversations too.

But there are still areas where I find out after the fact, where I’m constantly chasing decisions that have already been made. If you’re reading this and you’ve made real strides on this—getting security the visibility and lead time to understand what’s coming, to gauge risk early, to identify the gotchas before they become project delays, to prepare the tools or start applying existing ones to the new initiative—I’d genuinely like to know how you did it. Share the book, the article, the framework, the conversation that worked. The rest of us are still figuring it out.

Because here’s the thing: the earlier we know, the less we become a roadblock. When I find out a business unit bought a new SaaS tool the day before go-live, I am the delay—not because I want to be, but because we’re not ready. We haven’t evaluated it, we don’t know how it integrates, we haven’t figured out logging or access controls or data flows. But if I know six months out? We can work through all of that in parallel. Security stops being the thing that slows you down and becomes the thing that helps you move faster.

Maybe that’s just the life we have. But it’s definitely not the life of ‘security first.’

What I do know is this: Security Third doesn’t mean we accept being left out. It means we stop using ‘security first’ as a weapon and start making the case for why involving security early makes the business faster, not slower. It means proving, project by project, conversation by conversation, that we’re there to enable the mission, not block it.

It’s messy. It’s frustrating. And it’s the reality most of us are living in.

The Compliance Trap

One of the biggest lies we tell ourselves is that compliance equals security. Get your ISO cert, pass your SOC 2 audit, check all the NIST CSF boxes, and you’re secure, right?

Not even close.

Early in my career, I started on a Data Security & Compliance team. My entire day revolved around compliance minimums and passing the next audit. I learned the frameworks inside and out. I documented controls. I prepared evidence. I sat through audits. And I learned something critical: compliance is about meeting minimum standards. It’s about documenting that you’ve done the things you said you’d do. It’s valuable—I’m not arguing against compliance frameworks—but it’s not the same as being secure.

I’ve seen organizations that were fully compliant and completely compromised. I’ve seen audit reports that gave clean bills of health to environments that were actively being exfiltrated. I’ve seen companies pass penetration tests in June and get breached in July.

SOC 2 has become a marketing checkbox more than a security assessment. When engagements are funded by marketing departments rather than security or risk teams, you’re not measuring security posture—you’re producing sales collateral. The framework allows vendors to scope out entire trust criteria while still claiming compliance. You can skip Privacy and Confidentiality entirely and still be ‘SOC 2 compliant.’ That’s not assessment—that’s selective reporting.

And before you think I’m just being cynical: security practitioners have been documenting this problem for years. One former auditor writing on Medium put it bluntly: “Passing an audit doesn’t mean you’re secure. It means you’re auditable.” When auditors arrive, he wrote, “it’s not a test of security posture — it’s a theater production. Policies are dusted off, controls are ‘shown to exist,’ and everyone plays their part.” CPA firms have warned about the “SOC 2 rubber stamp crisis”—auditors rushing through assessments to hit rock-bottom price points, sometimes with inquiry-only testing that violates AICPA standards. One CPA firm documented ultra low-cost auditors offering reports $5,000-$10,000 while hiding failed peer reviews from the public AICPA database.

And the framework itself allows companies to pick and choose their scope, to ignore any of the four additional trust criteria beyond security, and still walk away with a “passing SOC 2.” (Only the Security criterion is mandatory—Availability, Processing Integrity, Confidentiality, and Privacy are all optional. What that means is that a vendor handling your customer data can elect to skip Privacy and/or Confidentiality entirely and still be “SOC 2 compliant.”) That’s not security assessment. That’s theater.

PCI DSS? Too many of my years have been consumed by PCI. It’s a needed foundation—I get why it exists and what it’s trying to accomplish. But the implementation is maddening. I’ve seen QSAs pass companies that were clearly below the bare minimum. I’ve also seen QSAs who expect audit perfection and treat every gap like a catastrophic failure. The inconsistency is the problem.

Here’s the reality: compliance is often about checking boxes, not about understanding and managing real risk. It’s about having a policy, not about whether that policy actually works. It’s about documenting the control, not about whether the control is effective.

I think the frameworks are all needed—they help point to the bare minimum. But no one framework is right for all companies and industries. CSF is probably the closest to being universally applicable, but even that requires translation and adaptation to your specific environment.

The Security Third mindset changes how you approach compliance. Instead of asking “what do we need to do to pass the audit?” you ask “what do we need to do to actually be secure?” Sometimes those align. Often they don’t.

Real security comes from understanding your environment, knowing what you’re protecting and why, having visibility into what’s actually happening, and being able to respond when things go wrong. None of those things are compliance requirements. All of them are harder than compliance.

Making It Work

So what does this actually look like in practice?

First, stop treating security as a binary. Nothing is perfectly secure. Nothing is completely insecure. Everything is cyber risk management. Your job isn’t to eliminate all risk—it’s to help the organization understand and manage information security risk in the context of what they’re trying to accomplish.

But here’s the thing: you can’t do that without a baseline. Does your executive team, your board, your C-level leadership actually have a documented statement of what level of cyber risk they’re willing to accept? If not, stop what you’re doing and get them to document this. This becomes your guiding light for determining if something is risky, too risky, or “not what I would do, but it’s not horrible.” Without this, what are you even securing to? Why? What level of security is required? You have no baseline. You’re making it up as you go.

Second, build security into workflows instead of bolting it on. If your security process requires people to stop what they’re doing, fill out a form, wait for approval, and then continue, you’ve already lost. They’ll find a way around it. Instead, figure out how to make the secure path the easy path.

This ties back to getting that seat at the table for strategic conversations. If I’m part of the planning process, I can help build security in from the start. But that’s where I still struggle—not because of me, but because business leaders don’t see a need or reason why I should be there. They think I’m protecting them so they can do whatever they want, and I’ll just… protect them somehow. That’s not how this works.

Third, focus on visibility and awareness over control and restriction. You can’t control everything—and trying to makes you blind. But you can instrument everything, monitor what matters, and respond quickly when things go wrong.

This means two things: technology and people.

On the technology side, invest in a solid SIEM—one you can actually afford and will actually, and can use. Log everything you can—but know why you’re logging it. Some Windows Event logging can be extremely noisy with no real value. Do you need that? Probably not. Don’t just log for logging’s sake because someone said “log everything.” Know the why. Revisit it often. Yes, there’s a cost-benefit analysis here—the more you log, the more visibility you have, but also the more expensive it gets and the more noise you have to filter through. You’ll need to make trade-offs based on what matters most to your environment and what your budget allows. Some of it you won’t be able to alert on in real-time, and that’s okay. Think of airplanes—they have flight data recorders not to prevent crashes, but to understand what happened when things go wrong. That’s what your SIEM is. When an incident happens, you need the data to explain how and why it occurred so you can shore those areas up. Without an effective, immutable SIEM, you’re left guessing.

On the people side, this is where that security awareness program we talked about earlier matters. When people understand why security matters and what to look for, they become your sensors. They report the suspicious email. They flag the weird request. They ask questions before clicking links. You can’t monitor every human interaction, but you can make humans part of your monitoring system.

Visibility isn’t just about tools—it’s about creating an environment where both your technology and your people are watching for the things that matter, and where you can actually see what’s happening in your environment instead of building walls and hoping nothing gets through.

Fourth, invest in people—and make sure they understand the mission. Not just training, but actual development. Help your team members understand not just what the rules are, but why they exist. Give them context. Make them partners in security, not subjects of it.

But here’s the critical part: your own team needs to understand what the mission actually is. All too often, we hire someone into the security team, usually transitioning from another IT function, and they interview well—but we miss that they have a preconceived notion of what security is. Lock everything down. Control the human. That’s not security—that’s a prison. They become the naysayer. ‘That’s not secure!’ Okay, to what standard? At what risk level? Compared to what baseline? How does turning this place into Fort Knox help the business accomplish anything?

I’ve seen this play out multiple ways. I had someone at one organization—maybe two jobs ago—accuse me to executive management of putting the company at risk because I wasn’t taking security seriously. Why? Because I wouldn’t lock down the firewall the way he wanted. If we’d done what he advocated for, we would have crippled half the business on day one. He didn’t understand the role or the why. He just wanted to secure everything.

At another organization where I started the InfoSec team, the network admin had apparently applied for my role. I got hired instead, and there was constant friction. His perspective on security was to lock everything down, control every bit of traffic, implement strict content filtering, and control the human. I was trying to enable the human. I advocated for less restrictive content filtering—just block the big bad stuff HR would freak out over and the other obvious threats. We butted heads constantly because we had fundamentally different understandings of what the job was.

Your team needs to understand that security exists to enable the business, not replace it. If they don’t get that, they’ll create the exact ‘Department of No’ problem we’re trying to avoid.

Fifth, be honest about limitations—especially when those limitations are outside your control. Don’t promise perfect security. Don’t tell people that following the policy makes them safe. Don’t create the illusion that someone else is responsible for their security. Make it clear that security is everyone’s job, including theirs.

And be honest when you can’t protect something anymore.

The last two years, my industry—like a lot of organizations—has been hell-bent on moving everything to “The Cloud.” We’re highly regulated. Our auditors and examiners really like the program we’ve built. It provides reassurance that we’re protecting what we can control. Our on-prem environment has been audited. Our examiners like what they see.

But when the business keeps buying SaaS solutions, once the data leaves our environment, I lose all insight. I lose control. I lose the ability to respond. I can’t protect data we’ve entrusted to that vendor the way I can protect data in our own data center.

So I’ve gotten hard on vendors. I ask tougher questions than apparently a lot of my peers do. That’s caused friction. But when the business asks why, I explain: we are secure in our data center. We have no control once the data goes to that vendor.

It’s an area of contention because the vendor is supposedly the expert. They built their system. They secure the data. But during due diligence, I’ve seen vendors scope their SOC 2 assessments to ignore three of the four trust criteria. And no one cares. The business sees a passing SOC 2 and thinks “secure.” I see a vendor that scoped their assessment to avoid scrutiny and I have no way to verify what’s actually happening to our data.

This is where honesty matters most. I can’t stand in front of leadership and say “we’re secure” when half our data is sitting in vendors I can’t audit, can’t monitor, and can’t control. The best I can do is say “here’s what we control, here’s what we don’t, and here’s the risk we’re accepting by going this route.”

That’s not a popular message. But it’s an honest one. And in a Security Third world, honesty about what you can and can’t do is more valuable than false assurances that everything is fine.

The Uncomfortable Truth

Here’s what I’ve learned over the years: the organizations with the best security are rarely the ones with the most security tools or the strictest policies or the biggest teams. They’re the ones where security is ingrained in how people work. Where it’s common sense, not compliance. Where people understand the threats and think critically about risk without needing to be told.

You can’t mandate that. You can’t policy your way there. You can’t achieve it by making security the top priority and overriding everything else.

You get there by making security third. Not unimportant—third. Important enough to always consider, but not so important that it replaces judgment, common sense, and personal responsibility.

That’s uncomfortable for a lot of security practitioners. We’ve been trained to think that if we just had more budget, more authority, more executive support, we could finally make things secure. But that’s the same fallacy as “safety first.” It creates the illusion that security is something someone else does for you.

The truth is, security is something we all do together. Or we don’t do it at all.

I didn’t come to this realization by reading another information security white paper or sitting through another conference keynote. I came to it by listening to a podcast that had nothing to do with InfoSec or technology. Someone mentioned “Safety Third,” and the host explained what that meant—Mike Rowe’s concept from his experiences on construction sites and dirty jobs. That moment has been rattling around in my head ever since, because in that explanation, someone articulated something I’d been struggling with for fifteen years in information security but couldn’t quite name.

Rowe innovated Safety Third not to diminish safety’s importance, but because “safety first” was creating the exact opposite of what it promised. It was making people less safe by making them complacent, by convincing them that safety was someone else’s job, by replacing personal awareness with compliance theater.

We’ve done the same thing with “security first.” And reflecting on the last fifteen years in this field—the breaches, the compliance theater, the reactive firefighting, the battles for strategic seats we never quite get—it’s time to admit it: we need to adopt Security Third. Not as a catchy slogan. Not as a way to downplay security’s importance. But as an honest acknowledgment of how security actually works and what actually makes organizations more secure.

That conversation—the honest one about what security actually means and how it actually works—is worth having, even if it makes people uncomfortable. Especially then.

Because the alternative is what we have now: organizations that say security first, act like security last, and wonder why they keep getting breached despite all their compliance checkmarks and all their tools and all their policies.

Maybe it’s time to just admit what we’re actually doing and build from there.

Maybe instead of fighting to be first, we should fight to be third. Because right now, in practice, we’re last. And moving from last to third—to a place where security is consistently considered, embedded in how work gets done, and honestly acknowledged as one of several critical priorities—would be a massive step forward.

Security Third. Not because it doesn’t matter, but because pretending it’s first hasn’t been working.

Podcast: Download (Duration: 44:49 — 24.0MB) | Embed

Subscribe to the Cultivating Security Podcast Spotify | Pandora | RSS | More