Sorry, Cyber: You Aren't the Only Ones Saving the Company from Itself

There’s still a bit of a tone in some security circles that we’re somehow unique in constantly having to push back against ill-advised moves, or even outright craziness, from our business, operations, or technology colleagues. 

But, when you pause and think about all the many functions in your or other organizations you realize this is not so. You quickly see that while great security teams are true enablers of business and reducers of friction, most teams still have to (and are expected to by their leadership) counterbalance excessively risky actions in their companies. This is also expected of many other functions managing many other risks in the enterprise.  

To pick one example, from the world of banking, is mark to market accounting. This is where trading, loans or other positions are valued at what they are currently worth in the market vs. what a model or person’s opinion of that value might be. Many financial woes have a root cause of not marking to the market. Before the financial crisis of 2008 a lot of companies had over optimistic financial positions that came crashing down when they were eventually forced to confront reality. Conversely, when I worked at Goldman Sachs, trading positions were strictly marked to market and the financial controllers held the line on that despite some traders wanting to keep positions marked higher. When there were disputes between the revenue generating and the control function, leadership insisted traders sold a small proportion of positions to discover the actual market price. Indeed, this aspect is covered in this post from a former Goldman Sachs financial controller who illustrates well that governance means business. In particular, the tension with control functions can be made a trusted partnership that delivers excellent levels of support to business activities. 

So, looking through the lens of there being lots of potential friction between all functions inside an organization you realize that security is by no means unique and that all of us have lessons to apply to hold the line on important matters while still, nevertheless, reducing friction and enabling outcomes in the service of our organization’s goals. 

Let’s look at some more examples that control and other teams have to push back on occasionally or regularly:

• Revenue Mirage: A sales VP pressures an accountant to recognize revenue from a massive contract in Q4, even though the contract won’t be finalized or delivered until Q1, just to hit the annual bonus threshold. 

• The Capitalization Trick: Operations pressures corporate finance to classify routine, everyday maintenance expenses as “capital investments” to artificially inflate this quarter’s net income.

• The Rogue Vendor: A regional manager demands an accounts payable team member bypass standard anti-fraud vendor verification to pay an overseas supplier immediately, claiming “the deal will fall through if we wait.”

• The 4-Hour Shortcut: A plant manager asks a safety supervisor to bypass a mandatory safety valve inspection because shutting down the line for the test will cost the factory $50k in lost afternoon production.

• The Weather Gamble: A commercial airline dispatcher pressures a pilot to take off into marginal weather conditions to avoid a costly cascading delay across three hub airports.

• The Uncured Concrete: A real estate developer pressures a construction site superintendent to pour the next floor of a high-rise before the lower level's concrete has fully cured, aiming to beat the winter weather deadline.

• The Sign it Anyway Contract: The sales team pressures the corporate legal counsel to sign a vendor agreement containing an unlimited liability clause just to close a “whale” account before the weekend.

• The Convenient Layoff: Executive leadership pressures an HR director to include an internal whistleblower in a routine restructuring layoff to quietly eliminate a compliance headache.

• The Slightly Dirty Water: A manufacturing director asks an environmental compliance officer to overlook a temporary spike in chemical runoff because fixing the filtration system requires stopping production for two weeks.

• The Unvetted Steel: A purchasing manager pressures a civil engineer to approve a cheaper, unvetted grade of structural steel from a new supplier because the approved steel is backed up by three months in the supply chain.

• The Beta Deployment: A product manager pressures a software engineering lead to push an app update to production with known critical data leakage issues, arguing "we can patch it in the next sprint, but we need the feature live today."

• The Glitchy Sensor: An automotive quality engineer is pressured by the launch director to sign off on a vehicle's braking sensor that occasionally errors during extreme cold, because delaying the vehicle launch will drop the stock price.

• The Bought Email List: A marketing director pressures a data privacy officer to upload a scraped third-party email list into the CRM for an aggressive campaign, ignoring regulations.

• The Missing Ingredient: A cosmetics brand manager pressures a regulatory affairs specialist to omit a controversial chemical from the public packaging ingredient list because it “ruins the clean-beauty aesthetic.”

• The Delayed Recall: Corporate PR pressures a product safety board to delay announcing a minor product defect until after the holiday shopping season to avoid a public relations nightmare.

• The Tired Driver: A logistics dispatcher pressures a freight truck driver to fudge their electronic logging device hours to deliver a shipment of perishable goods on time.

• The Warm Refrigerator: A grocery store manager pressures a food safety inspector to keep a dairy walk-in cooler running that is hovering at 45°F (above the safe 40°F threshold), because discarding the inventory will destroy the store's monthly margin.

• The Uncertified Factory: Sourcing pressures a procurement compliance officer to look the other way on a factory overseas that failed a labor exploitation audit, because they are the only factory capable of manufacturing a specific garment at scale.

• The Aesthetic Fire Risk: An architect pressures a fire safety engineer to approve a grand open-atrium design that lacks proper smoke containment zones because the required fire doors “ruin the visual flow of the building.”

• The Rapid Discharge: A hospital administrator pressures a head nurse to discharge elderly patients faster than clinically recommended to improve the hospital's bed turnover rate metrics.

Security, and all the other control functions have well developed techniques for holding the line on necessary risk management and compliance obligations. This includes embedding the right practices into systems and processes, for example making accounting and sales booking systems enforce the right treatments with overrides only possible at a CFO level. This in turn can be supported by surrounding policies and procedures to back-stop automated processes. But ultimately the holding of the line needs both an effective security (or other control) team that has the stature and governance apparatus to stand up to individuals, perhaps senior leaders, who for often genuine, but misguided, reasons want to bend or break the rules. 

Additionally, as I’ve covered extensively in this blog over the years, it’s important for the security team to achieve those control goals while also removing friction. This requires looking at the root cause of why people and teams are pushing up against the hard-rails and guardrails in your environment. For example, it might be that regular requests to bypass production controls are because of a mismatch between a team's natural production cadence vs. wider change windows causing them to always request emergency changes. Going to that team and getting them more in sync reduces friction and takes the pressure of needing to constantly push back on them. 

In some of our broader examples, the sales or accounting policy pressure is often caused by misaligned financial targets or the classic problem that when metrics become targets they cease to be effective metrics. The answer to this is looking for possible second order effects when setting targets. The broader answer is again to look at the root cause of the root cause. Like a business unit financial controller having to constantly push back on the sales team trying to book revenue into a quarter before it can truly be recognized is an obvious sign of a sales team struggling to make the numbers. If this happens constantly, quarter upon quarter, or even year upon year, then it’s a sign of either a weak team or deeper strategic problem for the company. In either case, escalation to the CEO and CFO is a must to address this. 

To further help with this we can usefully take a systems view of the organization to remedy those root causes of root causes to take the pressure of enforcement at the team level. This can help us see where bad goal alignment, organization dysfunction, or other issues are causing the pressure. 

To do this we need to recognize that there is another system operating inside every enterprise that we rarely map, yet it routinely breaks our best-engineered controls, that is the system of organizational power.

One way to do this is to think of an organization as being made up of many “circuits of power”. This concept was pioneered by sociologist Steward Clegg in 1989. Clegg argued that organizational power isn't just a top-down sledgehammer used by leadership to force everyone into submission. Instead, power functions exactly like an electrical grid. It flows through an organization along three distinct, intersecting "circuits". When you try to enforce any policy goal you need to pay attention to all of these circuits.

When a software development team bypasses a mandatory security review to hit a release deadline, that isn't just a technical bypass. It's an exercise of power. When an executive demands an exception to a multi-factor authentication (MFA) policy because it “disrupts their workflow,” that is power in action. To understand why security initiatives succeed or fail, we have to look past standard hierarchical org charts and look at how power actually flows. 

In classical organizational theory, power was historically treated as something mechanical and top-down. The prevailing view boiled down to: A has power over B to the extent that A can get B to do something that B would not otherwise do. Clegg realized this view was fundamentally flawed for modern organizations. He saw that treating power as a localized, conscious transaction between two people completely missed the invisible structures shaping their choices before they even spoke. Rather, organizations are continuous configurations of power relations. Power is most efficient when it operates silently through routine or automated processes. It becomes visible only when the system experiences friction or resistance. 

If you want to change an organization, you can't just issue a decree from the top, you have to alter the tracks upon which these circuits of power run.

These circuits operate simultaneously at the micro (interpersonal) and macro (systemic) levels. The three levels are not isolated, they continuously influence and reinforce one another, intersecting at critical bottlenecks known as Obligatory Passage Points (OPPs). Let’s look at the circuits. 

The Episodic Circuit (Micro Level / Causal Power)

This is the most visible layer. It encompasses day-to-day interactions, tasks, conflicts, and exercises of direct authority. The episodic circuit is the ground-level, face-to-face exercise of power. It’s localized and driven by humans exerting various types of authority over others to achieve a goal or prevent a bad or excessively risky outcome. For example, a product manager standing over the security person’s desk on a Friday afternoon, demanding an exception for an unpatched vulnerability so they can hit their launch deadline and that security person pushing back or escalating for other leaders to debate. It’s a direct clash of wills where one person tries to make another person do something right now.

The Dispositional Circuit (Macro Level / Rules of Practice)

This circuit is made of the written and unwritten rules, cultural norms, professional identities, and shared meanings within a company. It’s the “rules of the game” that determines what the organization considers legitimate behavior. For example, this is where security frameworks and compliance mandates live. The dispositional circuit is what gives teams the right to say “no” in the first place. 

The Facilitative Circuit (Macro Level / Systemic Power)

The facilitative circuit is embedded in the actual infrastructure, technology, resources, and rewards of the system. It doesn’t argue, cajole, or send angry emails, it simply enforces conformance through the environment itself - ambient control. For example, this is your automated CI/CD pipeline that physically blocks a developer from pushing code to production if it fails a security scan. It’s an Identity and Access Management (IAM) system that strictly revokes access on certain role changes. This is not just the circuit of auto-denial, better it’s the circuit that makes the secure and controlled path the easiest path. The best facilitative circuits deliver “happy paths”. 

Cybersecurity professionals often burn out because they try to fight Episodic battles (an angry leader demanding a shortcut) using only Dispositional arguments (“but our policy manual says no”). When you realize that every necessary gatekeeper in every organization, from the tax accountant to the aviation safety manager has to navigate these exact same three circuits, the burden changes. The resistance you face isn't a personal insult, and it isn't a unique security problem. It is simply the predictable result of operational speed hitting structural limits. 

The correct shift is to reduce Episodic and Dispositional tension by creating better Faciliative Circuits. 

A Core Concept: Obligatory Passage Points

Clegg's model is most useful in looking at where the three circuits intersect at the, so called, Obligatory Passage Points (OPPs). An OPP is a mandatory channel, protocol, or gatekeeper that actors must pass through (in automated or procedural ways) to achieve their goals. Power in an organization is ultimately the ability to establish, control, and defend these Obligatory Passage Points. If you control (or stipulate the properties of) the OPP, you control the flow of all three circuits.

For example, in healthcare administration, when hospitals introduce Electronic Health Record (EHR) systems, it isn't just an IT upgrade. The EHR becomes a new OPP. Doctors (who previously held massive episodic power) suddenly find their clinical autonomy constrained, rightly or wrongly, by software workflows (facilitative circuit), altering what it means to be an efficient physician (dispositional circuit). In corporate acquisitions, when two companies merge, conflicts rarely stem from purely financial issues. They happen because the two legacy organizations have different dispositional circuits (meanings and norms) clashing over who controls the combined entities' new OPPs (budgets, approvals).

For cybersecurity, Clegg’s framework is a good lens for diagnosing why security controls succeed or fail. Let’s look at three cases.

Case A: Zero Trust Architecture as the Ultimate OPP

In legacy network architectures, power was loosely distributed. Once a user cleared the perimeter, they had broad access. Implementing a zero trust architecture is an example of restructuring an organization's circuits of power. 

The deployment of micro-segmentation, continuous adaptive risk and trust assessment, and robust Identity Providers (IdP) is the main facilitative circuit. The IdP and other connected policy enforcement points become the Obligatory Passage Point. No network traffic, user, or device can achieve its goal without continuous validation at this point. The unwritten cultural norm shifts from “we trust our insiders” to “we verify everything explicitly.” A user's identity is no longer tied to their physical presence in an office.This is a change in the dispositional circuit. The episodic circuit also changes as day-to-day friction drops because access is dynamic and automated, eliminating manual access request friction between infrastructure teams and security 

Case B: The DevSecOps Friction and Shadow IT

The existence of shadow IT can be explained in the context of Clegg's circuits. For example, a security team introduces an engineering gate: a mandatory, manual static application security testing (SAST) review before code deployment. The security team has tried to establish an OPP. However, the development team’s dispositional circuit rewards them for deployment velocity, and their facilitative circuit (CI/CD pipelines) allows them to spin up unofficial and unmonitored AWS instances. Because the facilitative circuit provides a workaround, the developers bypass the security OPP entirely. This triggers an episodic conflict. Security calls them reckless, development calls security a blocker. The solution, of course, is to improve the facilitative circuits to take the pressure of the other circuits. In other words, exhibit some technical empathy and have security partner with DevOps to make the developer tooling usefully embed security objectives, to in turn reduce other friction. 

Case C: Incident Response War Rooms

During a major active breach (e.g. a widespread ransomware deployment), external factors radically disrupt the organization's normal power structures. The Incident Response (IR) Commander suddenly steps into a position of absolute power. Normal corporate hierarchies dissolve. The IR Commander establishes a temporary, high-velocity OPP: every system shutdown, press release, and remediation effort must be funneled through the process they are running. The facilitative circuit shifts to emergency out-of-band communication channels, and the dispositional circuit temporarily shifts from profitability to organizational survival.

_______________________________________________________

CISOs and security leaders frequently fail when they try to solve structural problems using only the Episodic Circuit, relying on mandates or punishments. To build a resilient security program, you should design controls that leverage all three circuits.

Step 1: Review Your Obligatory Passage Points (OPPs)

Map out your current security gates. Are they manual, frustrating, and easy to bypass? If your security OPPs cause too much friction, people will leverage the facilitative circuit (alternative tools, personal devices) to circumvent them. Make your security OPPs the path of least resistance through automation. 

Step 2: Rewrite the Dispositional Circuit (Align the Incentives)

You cannot enhance a security culture if organizational rules “penalize” safe behavior. If product managers are only judged on feature delivery speed, they will likely view security as friction. So, work with executive leadership to embed security metrics into the wider definitions of operational excellence in other teams. Reward engineering teams that maintain clean security scorecards. Shift the meaning of a “great engineer” from someone who codes fast to someone who builds resilient systems.

Step 3: Harness the Facilitative Circuit

Stop relying on human willpower to keep the organization safe. Humans get tired, distracted, and manipulated. Use technology and material design to make insecure actions systematically harder. For example, implement secure-by-default architectures, shift from training people not to click phishing links (an episodic “patch”) and deploy robust email authentication protocols and hardware-backed, phishing-resistant FIDO2 keys, and so on. Let the technology as much as possible handle the discipline in the background.

Bottom line: security is not the only team that has to hold the line every day to ensure the organization remains on the right track. Other functions, like finance, operations, and others do the same. The need to explicitly hold the line is a problem to be solved in itself. The best teams look at the root cause of the root cause and eliminate that to avoid having to constantly push back. By architecting your security program across all three circuits of power, you move away from being an external force trying to police the organization. Instead, security becomes woven directly into the structural fabric of how the enterprise naturally thinks, works, and flows.