Summary
A SaaS company skipped a security check two days before Black Friday. A hard-coded test bank account number shipped with the release. Transactions routed to the wrong accounts for a week. The company lost $1 million.
Every control designed to prevent it existed. None failed technically. They were not applied, because the company had trained its people to treat the deadline as the real constraint and security as the variable to defer.
The standard response is: fix the culture. We think that is the wrong question. Security culture will fail under pressure. The question is what your architecture does when it does.
When the exemption list becomes the strategy
Sina Yazdanmehr, CEO of IT security consultancy Aplite GmbH, describes a corporate that had built a reasonable risk-exemption process. Projects that needed to go live before a security issue was resolved could file a form, get sign-off, and proceed with a one-year exception. Remediation was expected to follow.
After five or six years, the register ran to hundreds of items: architectural gaps, missing firewalls, unpatched systems, each renewed annually without scrutiny. Senior leadership read the list as evidence the process was functioning. What it represented was years of accumulated risk with no realistic plan to clear it.
Shortening the validity window and making the legal weight of a signed exception explicit helped. A signed risk exemption establishes who knew about a specific risk and when, and making that accountability visible changed how managers engaged with it. But this is still a culture fix. It relies on the next manager reading the form differently than the last one did. Under sustained pressure, the culture reverts. The list grows again.
Architecture is a different answer to the same problem. An exempted system that sits inside a Protect Surface™, segmented, with limited reach into other systems, monitored continuously, is still an exempted system. But the question of whether the exception gets remediated this quarter matters less, because the radius of what an unpatched system can touch is constrained before the exception was ever filed.
Hero culture: the wrong intervention
Lieuwe Jan Koning, Co-founder and CTO at ON2IT, calls the Black Friday pattern the prevention paradox: the loss avoided creates no organizational credit, while the loss that occurs generates a full post-mortem. The engineer who ships by the deadline gets the bonus. The engineer who flags a missing compliance check gets called the bottleneck.
Most organizations respond to this by trying to change those incentives. That is the wrong intervention. Under real deadline pressure in a real company, incentives are basically immovable. The engineering team shipping for Black Friday will not stop because the CISO tightened the exemption form. They will find another path, because the business depends on it.
The right question is not how to stop the hero from cutting corners. It is how to make sure the corner they cut does not expose your payment infrastructure, your customer data, or your core systems. That is the Zero Trust argument applied to organizational reality: assume the developer will skip the check, and design so the blast radius of that decision is contained by architecture, not by trust in a process they just bypassed.
Saying no removes control, not risk
There is a failure mode on the security team’s side of this dynamic. When the primary response to a request is refusal, the work continues outside the security team’s visibility.
Yazdanmehr describes a machine learning team that needed production data to train a model. Synthetic data was inadequate. The security team declined with no discussion of alternatives. So the team found a contact in operations, walked away with a full database export via SharePoint, and distributed copies across developer workstations and a contractor’s personal laptop. The situation ran for over a year.
When the CISO raised it, the team’s response was: “Did you expect us to just not work because you said it’s not secure?”
A refusal is not a control. The work continues without audit trail or oversight, and consistently less securely than a constrained version of the original request would have been. This is the same structural failure as the Black Friday case, from the other direction. Both happen because the security model relies on a human, the engineer in one case, the CISO in the other, making the right call under competing pressures. When they do not, there is no fallback.
Make Zero Trust Feel Clear, Not Complicated
Step into a world where cybersecurity finally makes sense. Our Dictionary helps you cut through the noise, understand the language, and feel confident in every conversation—no matter your expertise level.
The trust gap that empties your rollout
An 800-person company bought an enterprise ChatGPT contract with zero data retention. Thirty seats were active. Most employees were still using personal accounts, pasting source code and contract drafts into a model that trained on everything submitted.
Two groups drove this. The first had never had the difference between enterprise and consumer accounts explained in terms relevant to their work. The second distrusted the explanation, assuming the company account was a monitoring tool. The personal account felt private. The company account felt like surveillance.
The organization had solved the technical problem. It had not solved the human one. This is the pattern: technical controls designed correctly, rendered ineffective because the humans they depend on either do not understand them or do not trust them. Awareness campaigns treat this as a communication problem. It is actually an architecture problem. The control should not require trust to function.
What we see in the GSOC
The four cases above came from outside ON2IT. The pattern they describe shows up in our own data.
In the GSOC, the alerts that correlate most reliably with major release windows are not sophisticated attacks. They are insiders, contractors, and engineers under pressure accessing systems outside their normal radius, moving laterally because they needed something and found a path to it. Not malicious, typically. Just fast. The architecture was not designed to stop fast.
The same pattern shows up around mergers, end-of-quarter pushes, and the week after a major hire onboards a team that has not yet absorbed the existing controls. The trigger differs. The signature does not. People doing legitimate work under time pressure, taking the path the architecture leaves open.
This is the design principle behind how we run MDR Prevent™ for our customers. We map Protect Surfaces™ around the assets that actually matter, like the payment infrastructure, the customer database, the IP repository, and constrain reach into each one independently. When a deadline-pressured engineer ships without running a check, the question is no longer whether the check would have caught the issue. The question is what the change can reach on the other side. For a Protect Surface™ that has been properly defined, the answer is: not the things that would have made this a million-dollar story.
When containment fails, MDR Detect™ surfaces the lateral movement in our GSOC before it becomes the incident. The two services answer the two halves of the same question. MDR Prevent™ constrains what the wrong call can reach. MDR Detect™ catches it when it happens anyway.
The architecture that assumes culture will fail
Zero Trust is an architectural answer to the question this article has been asking. It does not assume culture will hold. It assumes the user will make the wrong call, the developer will skip the check, the team will find a route around the policy. Protect Surfaces™ are designed so that when those things happen, the damage is contained. The hero who ships without running the security check can still ship. What they can reach on the other side of that decision is constrained by architecture, not by confidence in a process they just bypassed.
That is a different answer from “fix the culture.” Culture work asks how to get people to make the right call. Architecture work asks what happens when they do not. Most of the industry’s energy goes into the first question. The four cases in this piece, and the patterns we see in our own data, are an argument for taking the second one seriously.
Key Takeaways
- Security culture fails under pressure in predictable ways. The signals to watch for in your own organization: an exemption list that gets renewed without scrutiny, an engineer rewarded for shipping past a missing check, a sanctioned tool with low adoption against an unsanctioned alternative.
- Trying to change hero culture incentives is the wrong intervention. The right question is what the hero can reach when they cut the corner, not whether they will cut it.
- A security refusal is not a control. It removes visibility and produces a less secure outcome than a constrained version of the original request.
- Technical controls rendered ineffective by trust deficits are architecture problems, not communication problems. The control should not require trust to function.
Conclusion
The four cases in this piece are not unusual. They are what security culture failure looks like in organizations that have already invested in security. The exemption process exists. The review gates exist. The enterprise tool was purchased. The CISO is in the room.
The pattern is the same one. A control that depends on a human making the right call under competing pressure. When the pressure wins, the control is not there.
Architecture is a different answer. It does not ask people to make the right call. It limits what the wrong call can reach. The hero who ships without running the check can still ship. The exempted system that has not been patched is still exempted. The engineer who pasted source code into a personal AI account still did it. In each case, the reach of that decision is constrained before the decision is made.
That is what taking the second question seriously looks like.
Call to Action
If the patterns in this piece are familiar in your own organization, MDR Prevent™ is how we operationalize the architectural answer for our customers. We map Protect Surfaces™ around the assets that actually matter and constrain reach into each one independently. Contact us to see what your version of containment looks like.
FAQ
Security culture refers to the collective attitudes, behaviors, and norms that determine how an organization’s people engage with security requirements in practice. It covers whether employees understand the purpose of controls, trust the guidance they receive, and treat security as a shared responsibility. Organizations with strong security culture maintain practices under pressure; those without it route around controls when compliance creates friction. The question Zero Trust raises is whether security architecture should depend on that culture holding.Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua
Risk exemption processes become a liability when filing an exemption is consistently easier than fixing the underlying issue. One-year validity windows with no enforcement mechanism, combined with delivery pressure, turn a short-term relief valve into a permanent operating model. The register grows, the backlog becomes unworkable, and the exception list gets treated as evidence the security function is doing its job, when it is a record of deferred risk that architecture was not designed to contain.Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua
The prevention paradox describes the asymmetry between the visibility of a security failure and the invisibility of a security success. An incident produces measurable, attributable loss. A functioning security program produces an absence of incidents, which generates no dashboard entry and no organizational credit. This skews incentives away from prevention. The architectural answer to the prevention paradox is to make the damage from a bypassed control structurally limited, so the question of whether the control was followed matters less.
Zero Trust does not solve security culture problems. It reduces the consequence of them. By defining Protect Surfaces™, limiting what any user or system can reach by default, and verifying continuously rather than trusting once, Zero Trust contains the blast radius of a wrong call. The developer who skips the security check, the engineer who uses a personal account, the team that routes around a policy: in a Zero Trust architecture, the reach of those decisions is constrained by design. The culture failure still happens. Its impact is bounded.
Enterprise security tool rollouts fail primarily because of trust deficits and unexplained rationale, not technical adoption friction. When employees assume a sanctioned tool is a monitoring mechanism, they use personal alternatives instead. The organization has addressed the technical risk and created a different one. The structural fix is an architecture that does not depend on employees choosing the correct tool: controls that apply regardless of whether the enterprise or personal version was used, and access restrictions that limit what can be exposed through either.
