Standards Don’t Keep You Safe. Decisions Do.

Zero Trust turns “minimum requirements” into a starting point, then forces real-time, protect-surface choices.

Let me start with something I’ve seen in almost every organization I’ve worked with. You know the moment. It’s time to “do security,” so we go straight to the corporate standards. We treat them like a checklist, build solutions that meet the requirements, and then take a well-earned breath because, hey, we can say we’re aligned. And I get why that feels good. It creates comfort. It creates consistency. It gives you a tidy story to tell auditors and leadership.

But here’s the part we all eventually run into: comfort and consistency don’t automatically equal security. They mostly prove that lots of people did the same thing the same way. And in today’s threat landscape, that’s not the same thing as being resilient when things shift (which they do… constantly).

Quick story. A few years back, I got pulled into an environment that was genuinely proud of its standards program, and they should have been. Policies were current, the control library was clean, and most teams could tell you exactly which requirement they were meeting and where the evidence lived. On paper, it looked great. But you know that little itch you get when everything is “green” and you cannot quite explain why you are still uneasy? I noticed something that would matter later: when we talked about risk, we mostly spoke in control language, not in plain business terms with a clear owner on the other side of the table.

Then we had one of those weeks where the real world politely kicks the door in. A new exposure dropped, exploit chatter started building, and suddenly “Are we compliant?” was not the question anyone cared about. The question was, “Can an attacker reach this system through that path, and if they can, how fast will we know, and what can we contain?” You know the moment. The room gets quiet, and the conversation gets very specific, very fast. That is when it got uncomfortable: we had met the standard in a lot of places, but the most critical protect surfaces still had gaps, because the standard simply was not written for our specific blast radius.

That’s why I keep coming back to this. Zero Trust is not just a new architecture diagram. It is a new expectation. The baseline matters, sure, but the protect surface decides what “enough” looks like.

Why the “standards are the roadmap” model breaks

You’ve seen how these things get written. Corporate standards, industry standards, and regulatory controls are usually designed to be broadly applicable. They aim for the lowest common denominator that most teams can implement without breaking the business. That is not a criticism. It is literally their job. The problem is when we confuse “broadly applicable minimum” with “what this environment needs to be safe.”

You know what makes this especially painful right now? The time between “exposure” and “exploit” keeps shrinking. A standards-based approach is naturally slower because it waits for the next revision cycle, the next project, the next quarter’s funding, the next architecture review. Attackers do not wait for any of that. Zero Trust, at its best, assumes we need the ability to respond quickly and with authority, sometimes in real time or near real time, because the environment will change faster than our paperwork can.

And when I say “respond with authority,” I mean you have the technical and organizational permission to act. You can force stronger sign-in requirements, revoke tokens, disable a risky integration, quarantine a workload, tighten segmentation, or raise alerting thresholds without waiting for a slow chain of approvals. In some cases, that response has to happen in minutes, not meetings.

Zero Trust is one of the clearest signals that we’re moving past the expectation that standards will provide the roadmap for implementation. In a Zero Trust world, “minimum requirements” are not a destination. They are a baseline. They tell you where the floor is, not where the ceiling should be. And no longer can we rely on what we defined on Monday being adequate for what may happen on Friday.

Zero Trust forces a different question: what are we protecting, right here, right now?

Zero Trust is not only a design mindset, it is a response mindset. We design controls for the protect surface we have today, with the access paths and dependencies it actually uses, then we stay ready to adjust as the threat landscape changes. If a new exploit chain shows up on Wednesday, we should be able to tighten access, change enforcement, increase monitoring, or contain blast radius without waiting for the next standards refresh.

One concept I love, because it’s so practical, is the idea of the “protect surface,” the specific data, applications, assets, and services you actually care about defending (sometimes described as DAAS). And you know the moment it clicks for a team: instead of treating the whole enterprise like one uniform blob, we pick one protect surface and evaluate it on its own terms. What would compromise look like? What’s the business impact? How is it accessed? What controls actually reduce risk here? That framing shows up in Zero Trust implementation guidance, where defining and analyzing protect surfaces is an early, iterative step, not an afterthought.

This is where the “one size fits all” checkbox mindset starts to fall apart. Two systems can both be “in scope” for the same corporate standard and still deserve wildly different protection. A payroll system, a manufacturing control network, and an executive collaboration workspace might all satisfy the same baseline requirements, but if we secure them the same way, we’re basically telling the attacker, “Pick whichever one is easiest this week.”

Mini example. “Customer PII in our SaaS CRM” is a protect surface. For that one, a reasonable Zero Trust requirement might sound like, “Only corporate-managed devices, strong authentication, and approved network locations can access customer export functions, and we must alert within 5 minutes on mass download behavior.” Now compare that to “the build pipeline for product X.” The requirements shift: integrity controls, privileged access hardening, segmentation, and monitoring for unusual changes matter more than where the user is sitting. Same company, same standards library, totally different protect surfaces, so the security design should look different too.

To be clear: this isn’t anti-standards

I’m not saying we throw standards away. Standards are useful. They create shared language, they reduce chaos, and they keep us from forgetting the basics. The shift is that Zero Trust treats them as the starting point, then asks you to go further based on what you’re protecting and how it can be attacked. Zero trust approaches are often described as dynamic, moving beyond static perimeter assumptions and pushing for granular, continuously evaluated decisions. That posture aligns much better with modern threats than the idea that a static document can define “secure” once per year.

Designing controls in business language (and treating exceptions like real risk)

Here’s the part that tends to surprise teams. This shift changes how we design controls. In the “standards are the roadmap” world, we translate requirements into technical controls and call it done. In a Zero Trust world, the requirement has to be framed in language the business sponsor can understand, because what we’re really doing is buying down business risk for a specific protect surface. You know the moment it starts working. The sponsor stops nodding politely and starts making real trade-offs with you.

That means the sponsor is not just “informed.” They explicitly agree to the security stipulations: the access paths we will allow, the identity strength we require, the monitoring we need, the recovery expectations, the segmentation boundaries, whatever the protect surface demands. It becomes a clear trade. If you want this capability, these are the conditions that keep the blast radius acceptable.

If it helps, here’s a simple way to frame those stipulations so a sponsor can actually engage without needing to speak “security”:

·         Access: Who (or what) can access this, from where, and under what conditions?

·         Blast radius: If something goes wrong, what limits how far it can spread (least privilege, segmentation, isolation)?

·         Detection: What must we be able to see, and how fast do we need to know?

·         Response authority: What are we allowed to shut off or tighten quickly, and who can pull that lever?

·         Recovery: How quickly do we need to restore service, and what data loss is acceptable?

And when the design can’t meet the requirement, I don’t want that treated like a routine “standards exception.” This is bigger than “we didn’t check the box.” If a protect-surface-specific requirement can’t be met, that exception should be tracked by GRC with even more weight, because it represents an acknowledged gap against the risk the business is actually exposed to.

·         All exceptions are time-bound. No “forever exceptions.” Set an expiration date that forces a revisit.

·         All exceptions have an owner. A named person accountable for remediation (not a team name, not a mailbox).

·         All exceptions require a remediation plan before approval. What will be done, by when, and what the interim risk treatment is until then.

·         GRC tracks and reports them as risk. Not as paperwork, but as an explicit, monitored decision the business made.

When you do this well, the conversation stops being “Did we meet the standard?” and becomes “Did we reduce risk for this protect surface to a level the business knowingly accepts, and can we prove it over time?”

So what does this look like in practice?

If we were sitting down with coffee and you asked, “Okay, how do I actually apply this without boiling the ocean?” I’d start here:

·         Name the protect surface. Be concrete. “Customer PII in SaaS CRM,” “build pipeline for product X,” “plant-floor historian,” not “the cloud.”

·         Write the failure story. If this gets compromised, what actually happens financially, operationally, legally, reputationally?

·         Start with the standard, then pressure test it. Ask, “If we meet the corporate requirement, what’s still exploitable?” That’s where you find the gap between compliant and resilient.

·         Tailor controls to the surface. Maybe that means stronger identity assurance, tighter segmentation, more aggressive monitoring, different data protections, or stricter change control. The goal is to reduce risk for that thing.

·         Assume the controls will age. Build in review triggers: material architecture changes, new integrations, new threat intel, new business workflows, and yes—time. Security controls should have a half-life.

The leadership move here is subtle: you keep standards as guardrails, but you stop pretending they’re a GPS. Standards tell teams what can’t be skipped; Zero Trust asks teams to prove that what they built actually fits the risk of the protect surface.

Closing thought

If your security program still treats corporate standards as “the roadmap,” you’ll probably feel organized, and you might even be able to demonstrate maturity on paper. But Zero Trust is a reminder that paper maturity is not the same as operational resilience. Standards (corporate, industry, regulatory) are the baseline we should expect to exceed, because the threats do not care what version of the standard you published last quarter. The win is when each protect surface gets the protection it actually needs, even when that means going beyond the checkbox.

One last nudge, from one practitioner to another. If we need a quarterly committee meeting to decide how we respond to what is happening this week, we are already behind. Zero Trust is urgent on purpose. It pushes us toward controls we can adjust and defend quickly, with confidence, while the attacker is still moving.

If you want, tell me one protect surface you’re wrestling with right now. I’ll happily brainstorm what “exceeding the baseline” could look like there.

And if there’s a Zero Trust question, a war story, or a “does this actually work in the real world?” topic you’d like me to write about next, send it my way at hello@cletustaylor.com. I read them, and I’m always looking for the next good coffee-chat conversation.