The friction budget

A platform team requires a new subnet. The sanctioned path runs through a network change ticket, a security review and a change board slot, at a median turnaround of nineteen days. The launch date is six days out.

The team places the service in an existing subnet named legacy-billing-dmz. That subnet carries a security group written in 2019 for a system decommissioned two years earlier. No exception is filed. No rule was broken and no exception process covers the case.

Three years on, nine services occupy that subnet under the same 2019 security group. Renaming requires the sanctioned path nine times over, against a name that is the least urgent item on any backlog.

An auditor then asks why a customer-facing API sits in a DMZ named for billing, behind rules written for a decommissioned system. The finding is recorded against the platform team. The sanctioned path cost nineteen days against a six day deadline. The control's output was a workaround that now spans nine services.

Every control has a cost

A security team operates as a cost center whose success condition is invisible. A prevented breach does not produce anything to show for it. A blocked deploy produces a ticket, a thread and a missed date. The only visible output of a security team is friction.

What the organization loses as friction rises. Every scenario below is scored against these.

• Time. Delivery lost to review queues, exception requests and repeated prompts. Lost again when a control ships with no documented path and leaves people to guess. The guessed first attempt is wrong and gets redone. Lost again to changes that arrive with no notice and no training.
• Money. The same work bought twice, at a premium, from outside. Posts created to route around the blockers. Architecture that stays wrong because moving to a better design costs more than tolerating the current one.
• Morale. The motivation of the people living under the control. It does not return when the control is lifted. Its durable form is a population that has learned a standard costs them and resists the next one on sight.
• Observability. What the organization can still see of its own estate. Resources reused under names that stopped describing them. Separation of concerns dropped because the correct resource was unobtainable. Technology chosen because it was what was available. Documentation nobody wrote.
• Communication. Channels the organization stops trusting and stops using. Problems reported late, or never. The reason behind a change never travels with the change.
• Security. The posture itself.

What the team spends to impose it. Every scenario below draws on at least one of these.

• Goodwill. With leadership. Headcount, tooling budget, the benefit of the doubt in a planning meeting.
• Trust. With the people who work under the control. Whether they bring you a problem early, or at all.
• Authority. The team's own standing to decide. Every route around a control takes a little of it. It eventually costs less to onboard something that bypasses the security team than to work through it.

A cost is not the same as a net loss. A policy that explains itself and points at a working template is documentation the engineer wanted anyway. A reporting program with a visible reward attached adds engagement to a channel the organization needs working. Both still cost engineering time. A barrier draws these accounts down. A feature carrying the same intent can add to them.

Adam Beautement, Angela Sasse and Mike Wonham published The Compliance Budget at the New Security Paradigms Workshop in 2008.

The key insight from our study was that the amount of compliance effort employees are willing to expend is finite, this is what we call the compliance budget.

Their four principles put a limit on individual effort and note that effort accumulates.

The rate at which the budget is spent matters: the more rapidly they approach their limit, the less likely they are to comply.

Jerome H. Saltzer and Michael D. Schroeder published The Protection of Information in Computer Systems in Communications of the ACM in July 1974, revised April 1975. It lists eight design principles for protection mechanisms.

Psychological acceptability: It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly.

A control has to be designed around the people it is applied to. The attitude both papers argue against is still the default, where usability is a nice-to-have traded against security whenever the two conflict. A protection mechanism works when the people under it apply it correctly without having to think about it. One they route around protects nothing, whatever it scores on paper.

Trust is the cheapest coordination an organization has

An organization moves because its people extend each other trust without verifying every request. That trust is the mechanism that makes a firm cheaper than a market. The economics of it have a primary source.

Ronald Coase published The Nature of the Firm in Economica in 1937. The paper asks why any firm exists at all. If prices allocate resources efficiently, every job in the economy could be contracted on the open market. No company would need a boundary drawn around it. Coase's answer is that using the market is itself expensive. Finding a counterparty, learning the going price, negotiating terms and writing a contract all cost something before any work happens. A firm is the region where directing the work internally comes in cheaper than buying it. That argument founded transaction cost economics. Coase received the Nobel Memorial Prize in Economic Sciences in 1991 for the work on transaction costs and property rights that began with this paper.

On why firms exist at all.

the operation of a market costs something and by forming an organisation and allowing some authority (an "entrepreneur") to direct the resources, certain marketing costs are saved

And on why a firm has a finite size.

a point must be reached where the costs of organising an extra transaction within the firm are equal to the costs involved in carrying out the transaction in the open market

Coase was writing about the cost of using the price mechanism. He made no claim about interpersonal trust. Verifying every internal request raises the cost of organising a transaction inside the firm. Raise it far enough and the open market becomes the cheaper place for work the firm used to do itself.

What a trustless system actually costs

A proof-of-work chain is engineered so that a stranger's cooperation is unnecessary. It buys that property with continuous physical work, for as long as the chain runs.

The framework many security teams build around their own internal users is an attempt at the same design. Verify every request. Trust no participant. Assume the counterparty is hostile. It is a trustless system assembled out of colleagues.

Trust is not a setting. Nothing in a console grants it. It accrues from time, where bringing you a problem does not create more problems. From training, where a person is shown the path before they are measured against it. From communication, where a change arrives with its reason, early enough for the affected team to act.

Teaching people that effort does not change the outcome

NIST researchers Stanton, Prettyman, Theofanos and Furman conducted semi-structured interviews with forty participants about online activity and security perceptions. They published the results as Security Fatigue in IEEE IT Professional, volume 18, issue 5, September 2016, pages 26 to 32. Fatigue was absent from the interview protocol. More than half of the participants raised it anyway. The manifestations they report are resignation, loss of control, fatalism, risk minimization and decision avoidance. Friction teaches people that effort does not change the outcome. They stop caring.

Reporting is a decision. So is asking whether something is allowed before doing it.

The disengagement runs wider than security. The person does the minimum the role requires and stops there. They stop volunteering anything. They stop raising the thing they noticed on the way past. They stop taking the extra hour to do it properly. The extra hour never bought them anything.

A consequence works on somebody who cares. Nothing in a security team's enforcement model reaches a person who has stopped caring. Every gate, every mandatory training, every retraining invitation and every audit finding assumes the person on the other end cares what happens next.

An organization whose people have stopped caring is a weaker security proposition than it was before any of the controls shipped.

The governance had already slowed the organization down. The people living under it have now stopped caring.

What replaces the caring is competence at avoidance. People who still have something to deliver spend their own standing to brute-force an exception. People without that standing find the loophole and build an undocumented solution behind it. Everyone else reuses whatever resource already carries the permissions. Requesting a correct one costs more than misusing an existing one. The security team has no record of any of this.

Architecture becomes the path of least resistance. How secure the design is stops entering the decision. The people choosing are already being shouted at about delivery dates. They want the thing delivered by whatever means are available. The security team's concerns are not on the list they are working from.

An outside firm delivers faster because it sits outside your control surface

An internal team working under a heavy control surface delivers slowly. The slowness has more than one cause. Sometimes the control blocks the work outright. The rest of the time the team has stopped pushing, having already learned that pushing changes nothing. The delivery record looks identical either way.

The team looks incapable of the work. The response is to bring in an outside firm at several times the internal rate. That firm delivers quickly. The speed is read as proof that the problem was the team. The outside firm is working under different conditions. It holds a vendor contract. The control surface was built for employees on managed laptops. The firm has standing to get an exception on the controls that do reach it. It often has a sponsor senior enough to grant one. The internal engineer with the same blocker files a ticket. The firm has also not been there long enough to stop caring.

Sometimes nobody at the top connects the two things. The control surface and the vendor contract arrive on different slides, in different meetings, owned by different people.

Sometimes the connection is the reason. An executive works out that the vendor contract buys delivery the governed estate will not produce. Routing around the security team is the mechanism by which it works. It is also the security team losing the argument without ever being told the argument happened.

What the team spent. Authority, in full, since the work left the governed estate for a firm the governance does not reach. Goodwill, since the consultant premium lands on a budget line and the control surface that produced it does not appear anywhere. Trust, with a team that was delivering correctly and got read as incapable. The team judged incapable is the team trusted with less next year.

The role created to override the CISO

The same move happens without a contract. Delivery stalls where leadership can see it. The CTO hires somebody they trust, gives them a title senior enough to matter, and attaches to that title the authority to override the CISO. The new hire is effective immediately.

What the role does is route around the security model. The organization stops asking the security team for exceptions. It creates a post whose job is to grant them.

Sometimes the intention is stated out loud. An executive runs out of patience for the argument. They cannot remove the person holding the other side of it. So they build a post around them. The CISO role is often contractual, often board-visible, and in some sectors a regulator expects somebody to hold it. The person stays. The authority moves. Either way the security team keeps its headcount (for now) and loses the authority to be in the argument.

What the team spent. Authority, all of it, since the exception path now runs through a post created for the purpose. Trust was spent years before the role existed, one exception request at a time.

What the standards actually say

Zero trust, NIST SP 800-207

NIST Special Publication 800-207, Zero Trust Architecture, was published in August 2020 by Scott Rose, Oliver Borchert, Stu Mitchell and Sean Connelly. Its abstract defines the term in one sentence.

Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (i.e., local area networks versus the internet) or based on asset ownership (enterprise or personally owned).

The definition covers physical location, network location and device ownership. Each of those describes where a request came from and what hardware carried it. None of them describes a person.

The document is not silent on insiders. Section 5.3 is headed Stolen Credentials/Insider Threat. SP 800-207 states elsewhere that an enterprise-owned environment should not be treated as more trustworthy than a non-enterprise one. What section 5.3 says the adversary does is specific.

The ZT principle of no implicit trust based on network location means attackers need to compromise an existing account or device to gain a foothold in an enterprise.

The adversary in that sentence is a party who has taken an account. The controls the document describes act on sessions, credentials and resource requests. A colleague's trustworthiness never appears as a design input.

The misreading. Zero trust means trust nobody, including the people you work with.

Nothing in the document supports a control aimed at a colleague's trustworthiness. A team that builds one has decided that by itself. Citing SP 800-207 for it borrows authority the document does not extend.

Generic error messages, OWASP and NIST SP 800-63B

A rule of thumb in this field is that a response should not explain itself. The rule is real and it has a documented scope. OWASP's Authentication Cheat Sheet states the problem it solves.

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration.

It requires a generic response and supplies the wording.

Login failed; Invalid user ID or password

If that email address is in our database, we will send you an email

The threat it names is one actor doing one thing.

the creation of a discrepancy factor, allowing an attacker to mount a user enumeration action

The three surfaces it governs are login, password recovery and account creation. A requester at any of those has not authenticated. The adversary is an anonymous party probing to learn which accounts exist. Withholding the reason is correct there.

NIST's authentication standard does not carry the rule at all. SP 800-63B-4 superseded revision 3 in July 2025. Revision 3 is now marked withdrawn. The word enumeration does not appear anywhere in the current revision. Section 8.1 points the other way, in text the document marks informative.

Provide clear, meaningful, and actionable feedback on entry errors to reduce user confusion and frustration.

Provide clear, meaningful feedback on the number of remaining allowed attempts. For rate limiting (i.e., throttling), inform users how long they have to wait until the next attempt.

The same section treats friction as a security problem in its own right.

Evaluating the usability of authentication is critical, as poor usability often results in coping mechanisms and unintended workarounds that can ultimately degrade the effectiveness of security controls.

It also names the goal.

The overarching authentication usability goal is to minimize user burden and authentication friction (e.g., the number of times a user has to authenticate, the steps involved, the amount of information they have to track).

On repeated prompting it is specific. It describes pattern two below before that pattern arrives.

Session management is preferable to the continual presentation of credentials, as the poor usability of continual presentation often creates incentives for workarounds (e.g., caching activation factors), thereby negating authentication intent and obscuring the freshness of the authentication event.

The wrapper that caches a long-lived token on disk is the caching of an activation factor. NIST wrote the mechanism down.

The misreading. Never tell anybody why a request was refused. Any information in a response helps an attacker.

The rule covers requests from people who have not signed in. A denial shown to a signed-in employee is a different thing. Tell them which policy applied and how to request access. No attacker is reading it. Applying the rule there treats a colleague as an adversary.

CIS Benchmarks and the Implementation Groups

A CIS Benchmark is a set of configuration recommendations for one technology. Every recommendation inside it carries a profile. The profile is what decides whether that recommendation applies to a given machine. CIS's knowledge base defines the mechanism.

A profile definition describes the configurations assigned to benchmark recommendations.

Every recommendation within each CIS Benchmark is associated with at least one profile.

Level 1 is the floor.

The Level 1 profile is considered a base recommendation that can be implemented fairly promptly and is designed to not have an extensive performance impact. The intent of the Level 1 profile benchmark is to lower the attack surface of your organization while keeping machines usable and not hindering business functionality.

Level 2 is the hardened one. It ships with a warning attached.

The Level 2 profile is considered to be "defense in depth" and is intended for environments where security is paramount. The recommendations associated with the Level 2 profile can have an adverse effect on your organization if not implemented appropriately or without due care.

The STIG profile covers a separate requirement and absorbed what used to be a third level.

The STIG profile replaces the previous Level 3. The STIG profile provides all recommendations that are STIG specific. Overlap of recommendations from other profiles, i.e. Level 1 and Level 2, are present in the STIG profile as applicable.

A benchmark therefore arrives with its recommendations already sorted by how much damage they do to the machine they land on. The Implementation Groups sort the enterprise. CIS sets them based on the risk profile and resources an enterprise has available. It defines IG1 as

"essential cyber hygiene," the foundational set of cyber defense Safeguards that every enterprise should apply to guard against the most common attacks

The guidance on that page is that every enterprise should start with IG1.

The misreading. The benchmark is the standard. All of it therefore applies everywhere.

The benchmark sorts itself before anybody adopts it. Applying Level 2 across a fleet contradicts the page the profile is defined on. So does an IG3 control set at a company that can staff IG1.

NIST Cybersecurity Framework 2.0, the GOVERN function

NIST published Cybersecurity Framework 2.0 as CSWP 29 on 26 February 2024. It added a sixth function, GOVERN. Three of its outcomes place risk appetite outside the security function.

GV.OC-01: The organizational mission is understood and informs cybersecurity risk management

GV.RM-02: Risk appetite and risk tolerance statements are established, communicated, and maintained

GV.RM-03: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes

The misreading. Risk appetite is a security decision. The security team therefore sets it.

The framework puts appetite with executives. It puts cybersecurity risk inside enterprise risk management. A team that accepts a control on somebody else's behalf, with no signature outside the team, is running outside the framework it is audited against.

ISO/IEC 27001, the Statement of Applicability

ISO/IEC 27001:2022 specifies the requirements for an information security management system. Clause 6.1.3 sets the order of the work. The organization determines its own controls first.

b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen;

NOTE 1 Organizations can design controls as required, or identify them from any source.

Annex A arrives after that, as a check for omissions.

c) compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted;

NOTE 3 The information security controls listed in Annex A are not exhaustive and additional information security controls can be included if needed.

Item d) is the Statement of Applicability. It records the necessary controls, the justification for including each one, whether each is implemented, and the justification for excluding any Annex A control. The clause sets no test for what makes an exclusion valid. It requires the reasoning to exist in writing.

Item f) names who signs.

f) obtain risk owners' approval of the information security risk treatment plan and acceptance of the residual information security risks.

Clause 6.1.2 c) 2) requires the organization to identify those risk owners before any of this happens.

The misreading. Annex A is a checklist. Everything on it must be applied. Any missing control is a failure.

A control can be excluded. The requirement is a documented reason for the exclusion. A control excluded with its reasoning recorded is a conforming outcome.

Necessary is a word the standard never defines

Clause 6.1.3 b) turns on the word necessary. Nothing in the standard says what makes a control necessary. The organization supplies that definition. Leaving it unsupplied is how a control catalogue grows without anybody deciding to grow it.

Requirement arrives from outside the organization.

Clients. The standards you have to meet to do business with them. They turn up in contracts, security questionnaires and audit rights.

Insurers. The standards you have to meet to stay covered. The policy language says what it says. Read it before claiming it.

Regulators. The standards that keep you compliant in the jurisdictions you operate in.

Those three produce requirements. Everything past them is above and beyond. An elective control is a legitimate thing to build. It answers a different question. A required control has to be implemented. An elective one competes against every other use of the same engineering time and the same goodwill. Most of them lose that comparison once somebody runs it.

A certification does not define necessary either. SOC 2, ISO 27001 certification and every other attestation in that family become requirements at the point a client contract, an insurer's policy or a regulator names one. Until then, pursuing one is elective. It is frequently a sound elective choice. A client will ask next year and the certificate shortens the sales cycle. It belongs in the ledger as elective, with the commercial case written beside it.

ISO/IEC 27001 says as much about itself, in clause 1.

Excluding any of the requirements specified in Clauses 4 to 10 is not acceptable when an organization claims conformity to this document.

The requirements bind an organization that claims conformity. Making that claim is the elective decision. The control exists because a certification scheme lists it. No client asked for it. No insurer named it. No regulator requires it. If none of the three care about it, neither should you.

DORA and Accelerate, on change approval

DORA is the research program behind the State of DevOps reports. Its capability page on streamlining change approval, citing the 2019 report, states what the research found about formal external review.

no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates

Accelerate, by Nicole Forsgren, Jez Humble and Gene Kim, reports the fuller result from the same research program. External approvals were negatively correlated with lead time, deployment frequency and restore time, and uncorrelated with change fail rate.

The misreading. An approval step makes a change safer. More approval makes it safer still.

The 2019 State of DevOps research measured change fail rate against the review process a change went through. A formal external review process showed no association with a lower change fail rate. Approval boards and change advisory boards bought no measurable reduction in failed changes.

Six patterns

Every story here is a composite, assembled from more than one organization.

Pattern one, unilateral risk transfer

A quarterly access review flags a shared service credential with no rotation in eighteen months. The security team rotates it on a Friday afternoon to close the finding before quarter end. Three production integrations authenticate with that credential, none of them documented against it. Payment reconciliation, the warehouse label printer service, and the nightly export to the third-party logistics provider.

Labels stop printing at six in the evening. The on-call engineer identifies the cause at 7:40 and holds no permission to read the secret store. Security's on-call is unreachable. Shipping resumes late on Saturday night.

The audit finding closes as remediated. The outage was filed as an application incident. The quarterly security report therefore records one finding closed and zero security incidents. Against every measure the security team is held to, that week scores well.

That filing also places the lost day on the application team's record, as slipped delivery and a raised incident count. The explanation available to them involves a credential rotation they did not know was scheduled and could not have stopped. The security team's own numbers carry no mark from the episode.

The transfer is the finding. A team accepted an availability risk on behalf of a department that never saw the decision. The cost landed on a different budget and a different scorecard. The team's own metrics improved while the organization lost a day of shipping.

NIST CSF 2.0 places that decision outside a security team's unilateral authority. GV.OC-01 states that the organizational mission is understood and informs cybersecurity risk management. GV.RM-02 states that risk appetite and risk tolerance statements are established, communicated and maintained. GV.RM-03 puts cybersecurity risk management activities and outcomes inside enterprise risk management processes. And on who sets appetite, from section 4,

As executives establish cybersecurity priorities and objectives based on those needs, they communicate expectations about risk appetite, accountability, and resources.

ISO/IEC 27001 puts the same requirement in auditable form. Clause 6.1.2 c) 2) has the organization identify the risk owners. Clause 6.1.3 f) then requires it to

obtain risk owners' approval of the information security risk treatment plan and acceptance of the residual information security risks.

Nobody outside the security team approved the Friday rotation. Nobody accepted the availability risk it carried.

What it cost. Time, a day of shipping. Communication, since the warehouse team now routes around security review for anything touching their printers. Observability, since no report will ever put the rotation and the outage on the same page. That change in the warehouse team is permanent. It was bought with one afternoon's convenience.

What the team spent. Trust, with a team that found out about the decision from the outage. Authority, in the same move, since a team that routes around you has stopped bringing you the decision at all. The scorecard reported a closed finding.

The mitigation. A destructive action pre-mortem, completed in writing before the action. What authenticates with this, how was that list built, what does it miss, who finds out first, what is the rollback, whose budget absorbs an outage. Then name the owner of the risk being accepted on somebody else's behalf. It is not the security team.

Pattern two, the single persona

An organization requires step-up authentication for every database connection. The policy was written for the production finance database, where it is correct. It applies by resource type. Its scope therefore includes the containerized Postgres a developer runs on a laptop for unit tests.

The test suite opens one hundred and forty connections, each raising a browser prompt. Within a week a developer writes a wrapper that caches a long-lived token on disk and shares it in the team channel. That restores the suite for the whole team.

One control, one assumed population, applied by resource class across every environment. CIS publishes more than one profile precisely because that does not work. It states the intent of the lower one directly.

The intent of the Level 1 profile benchmark is to lower the attack surface of your organization while keeping machines usable and not hindering business functionality.

What it cost. Security, since a shared long-lived credential now sits on four machines and the posture is worse than before the control. Time, one hundred and forty prompts per test run. Observability, since no instrument in the organization was pointed at the outcome.

What the team spent. Trust, since the wrapper and the shared token live in a channel the security team is not in. Authority, since the control is formally in force and actually bypassed, with no exception filed to record it. The policy reads as implemented everywhere it is reported.

The mitigation. A persona and environment matrix. Personas down the side, environment tiers across the top, control intensity and approver in each cell. Define the tiers first by what is actually in them. A tier holding no customer data and no production credential does not get a production control.

The developer is the only party in the sequence who closed a problem. The artifact they produced is worse than the control it replaced, since a shared long-lived token on four machines is a worse credential posture than a browser prompt.

The policy author solved a real problem on the production finance database, then applied that answer by resource type. The scope rule carried it to a container on a laptop. The resulting control is formally in force and actually bypassed, with no instrument in the organization pointed at the outcome.

The developer was handed a test suite that would not run and a delivery date, against a single available lever. They pulled it, the suite ran, and the team resumed shipping.

Prompt volume is also an attack surface in its own right. The agency that publishes on it says so. CISA describes push bombing in its number matching fact sheet.

MFA fatigue, also known as "push bombing," occurs when a cyber threat actor bombards a user with mobile application push notifications until the user either approves the request by accident or out of annoyance with the nonstop notifications.

The same fact sheet treats the user's reaction as reasonable.

This activity understandably annoys the user, who may, accidentally or from MFA fatigue, press accept to stop the prompts.

An adversary generates the prompts in that description. A control generating a hundred and forty of them per test run is the training program for the same reflex. A federal cybersecurity agency has written down that annoyance at repeated prompts produces an approval reflex. A control built to raise prompts at that volume manufactures the reflex in advance, free of charge, with no adversary involved.

A competent person takes the unsanctioned path whenever it costs less than the sanctioned one. Removing this developer changes nothing. The next person in the seat meets the same hundred and forty prompts and reaches the same conclusion inside a week.

Or they reach a worse one. They decide the suite is not worth the fight. Tests stop being part of how the team works. The control removed the testing. The risk it was written for stayed exactly where it was, with one fewer instrument pointed at it.

That outcome never appears in a finding.

Interruption cost lands where no instrument is pointed

Gloria Mark, Daniela Gudith and Ulrich Klocke published The Cost of Interrupted Work at CHI 2008. The experiment put 48 subjects in a simulated office. Each one answered twelve emails as a human resources manager, working from a fact sheet of staff job levels and overtime hours. A supervisor interrupted them every two minutes by telephone or instant message. Subjects were instructed to take the interruption immediately.

The delivery numbers came out clean. Subjects completed the interrupted blocks faster than the uninterrupted one, at 20.3 and 20.6 minutes against 22.8. Error counts held. A politeness score held.

The subjective measures all moved. Stress went from 6.9 to 9.5 on a twenty point scale. Frustration went from 4.7 to 6.6. Effort went from 9.5 to 11.0. Time pressure and mental workload rose with them. Stress, frustration and effort were all significant at p under .01.

After only 20 minutes of interrupted performance people reported significantly higher stress, frustration, workload, effort, and pressure.

A team that shipped this interruption and then checked throughput and quality would find nothing. It landed in accounts nobody reads.

The rest of that paper does not transfer. The task is the reason. Each of the twelve emails was an independent lookup. Nothing carried from one email to the next. A subject interrupted at the two minute mark had no held state to rebuild. The compensation shows up in the authors' own data. Subjects wrote shorter emails. Their quality instrument counted spelling errors and greeting phrases. A thinner answer scored the same as a complete one.

Email triage absorbs interruption. Work that runs on held concentration does not. That second kind is where an organization's product comes from.

Developers report the opposite result. Zahra Shakeri Hossein Abad, Mohammad Noaeen, Didar Zowghi, Behrouz Far and Ken Barker surveyed 141 developers across ten countries for EASE 2018. Two thirds listed their job as programmer. The instrument is self-report. It records what developers say about their own work.

Agreement on the consequences of interruption ran 97% for needing extra time to regain focus, 95% for needing extra time to finish the task and 91% for losing track of the work. A higher error rate drew 46%. Reduced quality drew 39%. Four fifths said a task switch is itself an interruption. More than half reported they cannot hold focus through a normal working day.

Their summary of where that cost goes matches the 2008 result.

the wasted time due to time fragmentation caused by task switching is largely invisible and unnoticed by developers and managers

A security team pricing a prompt will reach for the first population every time. That work is abundant, easy to instrument and easy to survey. The number it returns sits near zero. The same prompt applied to work that holds state costs real output. No instrument in most organizations would show it.

Pattern three, building unmanaged controls

A control arrives from outside the organization. It comes from a published benchmark, a vendor default, an operating model somebody ran at a previous employer, or a framework bought as a product. Nothing about the control considers the current organization it is meant to protect.

The borrowed benchmark

A new hire applies a CIS Level 2 benchmark across the Linux fleet through configuration management. Level 2 includes a restriction on which accounts may use cron. Build agents run scheduled jobs as a service account outside the permitted group. Nightly builds stop producing artifacts. The job continues to exit zero. The failure presents as a flaky pipeline for nine days.

The same organization's zero trust program adds per-request re-authentication to the internal wiki, on the grounds that zero trust means never trust. The wiki holds the onboarding documentation. The documentation stops being written.

The provenance of both changes is a publication or a vendor default. A vendor default encodes that vendor's median customer. Neither change traces to a named threat against a named asset in that organization. CIS says what Level 2 is for and what it can do.

The recommendations associated with the Level 2 profile can have an adverse effect on your organization if not implemented appropriately or without due care.

Many of these tools ship with a template and the claim that the template is all you need. It is not. The vendor has not seen your organization. It has not seen the personas inside it.

A vendor tool also needs tuning, exclusions, upgrades and somebody watching its output, for as long as it runs. An externally managed service does not remove that work. It converts the work into communication with the vendor. That still costs a person on your side.

The borrowed operating model

A security team stands up a control catalogue, a policy engine and a tooling estate built for an organization several times its size. The team cannot operate what it has deployed. Policies have no owner. Findings have nobody to action them. The tooling needs a team the company does not have and will not have for years.

The usual route in is a senior hire. A company entering an existing market hires from the incumbent it intends to displace. That instinct is sound. The hire knows the domain, the regulators and the failure modes. They also bring the operating model they ran at the incumbent. The expertise transfers. The calibration does not.

The mismatch concentrates where the company's advantage lives. A new entrant competes on the speed at which it can change its product. An operating model built to govern a slow-changing company removes that speed and retains its own overhead.

CIS publishes the calibration this ignores. It sets its Implementation Groups based on the risk profile and resources an enterprise has available. It defines IG1 as

"essential cyber hygiene," the foundational set of cyber defense Safeguards that every enterprise should apply to guard against the most common attacks

The guidance on that page is that every enterprise should start with IG1. A model imported whole from a company several times your size contradicts the framework it was taken from.

The organization that shrank

This variant inverts the direction. Nothing arrives from outside. The organization contracts around a control set that stays where it is.

A company reduces headcount and merges teams. The people who stood up the tooling leave or are cut. The control catalogue, the policy engine and the review process survive the reorganization intact, since nothing in a reorganization goes looking for controls to retire. The remaining estate is sized for a company that no longer exists.

No new hire brought it in. No vendor sold it. The mismatch opened underneath a control set nobody touched.

What these produce

The first tell is a control catalogue larger than the engineering organization. Count the policies with a named owner who could be asked about them this week. Count findings closed last quarter against findings opened. A widening gap is the control set telling you it does not fit.

The second tell is stagnating configuration. Capacity to deploy a tooling estate is a different thing from capacity to run one. The deployment is a project with a date on it. The maintenance is a standing cost nobody budgeted. So read the modification dates. The policy set, the tuning, the exclusions, the allowlists, the severity thresholds. A configuration unchanged since rollout has no owner, whatever the org chart says.

The estate underneath it keeps moving. New services, new resource types, a cloud provider renaming a permission, a platform migration. The policy set keeps enforcing the assumptions that were true on the day it shipped. The gap between the rule and the thing it governs widens on its own, with nobody touching either side. That gap is where unsatisfiable findings come from.

The mismatch comes from either side. A policy engine flags a resource as non-compliant. Fixing it needs a permission the application team does not have. The platform team holds that permission and never sees the finding. Or a policy requires a property the cloud provider has deprecated. The API now rejects it. Set the field and the deployment fails. Leave it unset and the resource stays non-compliant. Either way nobody can close it. The control catalogue is now reporting a problem that no one is in a position to fix.

Fill a system with those and the warnings get ignored. The blockers cannot be ignored. They destroy morale. The next real finding arrives and everybody assumes it is another false positive.

What it cost. Time, nine days of builds that produced nothing, plus policies with no owner to answer a question about them. Money, in a tooling estate and a control catalogue nobody can operate. Observability, in onboarding documentation that stopped being written, findings that open faster than they close, and a dashboard whose red items are permanent and therefore unread. Security, in the real finding that arrives and gets read as another false positive.

What the team spent. Authority, since a team visibly unable to operate what it deployed loses the argument about what to deploy next. Goodwill, with everyone who watched nine days disappear into a flaky-pipeline theory, and with the leadership that funded the estate on the strength of the hire. Trust, with engineers answering findings nobody is in a position to close.

The mitigation. A mandate ledger. Every control traced to a contract clause, a cited regulation, an insurer requirement, an internal threat model with a named actor and asset, or the entry "we chose it". If no client, insurer or regulator requires the control, switch it off.

Pattern four, shipping a control without testing it or asking anybody

The control ships. Nobody ran it against the work it governs. Nobody asked the teams who do that work. Both checks are cheap. Neither happened. Sometimes a date gets announced. Sometimes a vendor recommendation lands as a policy and the first anybody hears of it is the thing no longer working.

The base image registry

Security announces that only approved base images may run in production, effective in two weeks. The approved list will live in a registry that is being stood up. At the deadline the registry does not exist. The policy is enforced in CI against a hardcoded list of four images. Teams needing a fifth open a ticket. The queue has no owner. Three teams work out that starting from an allowed tag and installing their dependencies at container start passes the gate. Production begins building packages at boot.

Eighteen months later the organization builds the registry properly. It is self-service, scanned and automatically approved. No announcement accompanies it. Two years on, teams continue to install packages at container start. The workaround functions and nobody has told them it stopped being necessary.

Local administrator rights

A security team removes local admin from development machines, effective on a date. The elevation mechanism that would let a developer install a toolchain, attach a debugger to a service or register a local certificate is procured separately and arrives later. On the day the rights are removed, the only available path is a ticket queue.

Work that took two minutes takes a day per request. The work continues through other routes. A machine held outside the fleet, a build run on a personal laptop, and a shared account that retains rights because nobody audited it.

Private browsing

A security team removes private browsing windows through a GPO, with no announcement. A private window is a critical tool for Frontend Development and QA. They use private windows daily to test with a clean session or multiple personas. All work stops on the morning the policy is applied.

No party asked what the feature was being used for. The capability is also narrower than the control implies. Google states what Incognito does not cover.

While Incognito can help keep your browsing private on your device, it doesn't make you invisible. Websites you visit, including Google sites, and organizations that manage your network, like your school, employer, or internet service provider, may be able to observe your activity in Incognito.

Private browsing suppresses local history and cookies on that machine. Proxy logs, DNS logs, endpoint agents and DLP see what they saw before.

The teams then installed other browsers. A portable build that needs no installer and accepts no policy, a second Chromium outside the GPO's reach, and whatever a search returns that still carries the feature. The GPO reached the managed browser. The testing moved to unmanaged ones. No update channel covers those installs and no inventory lists them.

What these produce

Every route the three stories produced is less governed than the capability that was removed. A shared privileged account. A machine outside the fleet. An unmanaged browser. Packages installed at container start in production.

The ordering is the entire failure. Removing a capability and providing its replacement are one change. A team that ships them as two changes in that order has built the queue. Saltzer and Schroeder's psychological acceptability is the principle this breaks. It is quoted above.

What it cost. Security, since every route listed above is less governed than what was taken away, and since the base image policy produced two years of a worse production posture than the one it was written to prevent. Time, a day per elevation request and test coverage that takes longer or goes unrun. Observability, in machines held outside the fleet, a shared privileged account nobody is auditing, and browsers no inventory knows about. Morale, in teams who were not asked and lost tools they used hourly. Money, in eighteen months of engineering on a platform nobody adopted.

What the team spent. Trust, in two weeks' notice for a mechanism that did not exist on the day it was needed, and in a GPO nobody mentioned. Authority, since the gate is passed by installing packages at boot. The policy's real reach ended at four hardcoded images. Goodwill, in eighteen months of engineering on a platform nobody was told about.

The mitigation. The tool that absorbs the impact has to work before the control goes in. Not procured. Not planned. Working. If there is no elevated access path that completes without a ticket, the admin rights stay.

Removing the capability anyway needs a reason that survives the necessary test. A client contract, an insurer requirement or a regulation, named, with the clause. Without one the control is elective and the organization is paying for it in the routes listed above.

Run the control against the work before it ships. One GPO on one development machine for one afternoon catches the private browsing case. Four base images tested against the real fleet catches the registry case.

Ask the teams who use the capability what they use it for. The conversation is cheaper than the control. Nobody in the browser story had it.

The self-service test gates all of it. Can a competent engineer complete the path alone, in minutes, with no human in the loop, documented where they will look, and were they told it exists. All five, or it does not ship.

The registry was late for a reason. Somebody was waiting on a procurement, an approval, or another team with its own queue.

Pattern five, simulated attacks on your own colleagues

A company runs its first phishing simulation with no prior training. The pretext is an email from HR with the subject "Q4 bonus statement attached". The simulation reports a 31% click rate. Every subject who clicked is enrolled in mandatory retraining with their manager copied. The following quarter's simulation reports 4%. The figure is reported to the board as a success.

Email stops being a channel the organization can use

The payroll team stops sending real benefits email. The last three legitimate HR messages generated a flood of "is this a phish" tickets. Two managers tell their staff to ignore mail from HR.

A click rate measures how convincing the pretext was. The variable that actually moved is the organization's willingness to treat an internal sender as legitimate.

A channel that penalizes engagement receives less engagement. Run the program hard enough and people stop reading internal email at all. A concurrent flood of all-staff leadership mail accelerates that, until the channel carries nothing anybody acts on. A reporting delay on a real incident is the smallest consequence of it.

The replacement arrived a year late

A large employer sends its workforce home. The office had been the communication system and nothing was designed for its absence. Email is the only channel everybody holds. The phishing program and an all-staff mail flood have already trained people not to read it. No centralized chat exists.

A chat platform is proposed. The security team reviews the candidates and objects to each on grounds that trace to no named threat. The rollout becomes a project and lands a year later.

The deployment process had already been decentralized into individual departments. The owner of a given step is therefore reachable only through email nobody reads, in an organization with no chat, in a period when nobody is in a building.

The organization loses the ability to execute. The work requires people to reach each other and no channel does that.

Three patterns produced that together. This one killed the channel. Pattern six delayed the replacement. The decentralization removed the fallback path to a person.

DORA's research measures what the resulting culture does to performance.

a culture of psychological safety is predictive of software delivery performance, organizational performance, and productivity

On the evidence for this one. The channel collapse is an observed outcome and no study cited in this piece measures it. The phishing literature below measures click rates and reporting rates. Nobody has published a measurement of an organization abandoning its own internal mail. Treat the mechanism as reported practice and the research below as covering a narrower question.

What it cost. Communication, in the only channel that reached everybody. The organization lost the ability to tell itself things, then lost a year waiting for a replacement, then could not reach the departments holding its own deployment steps. Time, in every piece of work that needed two people to coordinate. Money, in a workforce drawing salary inside an organization that had stopped being able to act. Security, in a detection delay on a real incident. Morale, in a population that learned reporting carries a penalty.

What the team spent. Trust, directly and by design, since the exercise was deception run against colleagues. Authority, twice over. The organization stopped treating internal mail as real. It then routed its coordination into whatever each department could reach. Goodwill, with the managers who put staff through retraining for opening an email from HR and with the leadership that watched a chat rollout take a year.

The mitigation. Training before testing, with no exceptions. Remove the consequence attached to participation. Then change the instrument. A click rate measures the simulation. Measure reporting rate, time to report, and whether a person can complete the secure path unaided.

Then measure the channel itself. Nobody instruments this part. Volume of legitimate internal mail. Whether the functions that need to reach everybody still can. Whether a message from HR gets opened. An organization that has stopped reading its own email has lost something no phishing program will ever report. The program's numbers improve while it happens.

On the false alarm cost Jensen and colleagues named, the reward structure answers it. Make accuracy the thing the reward tracks. Five consecutive accurate reports is an award that reporting everything cannot earn. A report that turns out to be a real event is the one worth a material prize. Neither design has been measured in the literature cited here. Both aim at the failure mode that literature named.

The direction of the whole program reverses at that point. Gamification exists to produce attention and engagement. That is its purpose in every other field that uses it. A security team running one well has stopped only adding protection. It is adding communication and engagement to the channel the organization needs working. That is organizational health. The security team is contributing to it directly. Pattern five is what happens to the same channel with none of this.

A recurring campaign becomes a game people are playing. The reminder arrives on schedule. A scheduled reminder is the one effect the 2022 field study found the exercise reliably has. People open internal mail looking for it. The accuracy streak rewards careful reading. Deleting on sight earns nothing. Reporting puts somebody in contact with the security team on a good day. That is the one interaction a security team almost never gets.

The artifact is identical in both versions. Its sign on the account is reversed. A maintained policy that doubles as documentation is the other one. Both work the same way. The artifact arrives as something the person wanted anyway.

The engagement framing is a design argument. What has been measured is the nudge effect and the reporting result from public attribution. Nobody has published a measurement of a security program improving an organization's engagement with its own internal mail.

On the carrot and the stick. The instinct is that a consequence suppresses clicking and a reward encourages care. Both halves have been measured. The answer depends on what the reward actually is.

Lain, Kostiainen and Čapkun ran a fifteen month study with more than fourteen thousand employees of a partner company, published at IEEE Symposium on Security and Privacy in 2022. On the standard industry practice of showing training the moment somebody clicks,

embedded training during simulated phishing exercises, as commonly deployed in the industry today, does not make employees more resilient to phishing, but instead it can have unexpected side effects that can make employees even more susceptible to phishing

The same group tested a reward for reporting. Content, Nudges and Incentives, by Lain, Jost, Matetic, Kostiainen and Čapkun, took a Distinguished Paper Award at ACM CCS in 2024. It ran 4,554 employees of a Swiss company across nine groups. One group was told in advance that correctly reporting a phishing email would earn a prize.

H6: Rewards do not increase the rate of reported emails.

We find that the rate of reported emails is not significantly different between the two groups.

The instrument decides what that finding covers. The prize was set by the company as a box of chocolate, sent by IT in weekly batches, distributed at the end of an assessment cycle of roughly three weeks. It was announced once, by email, at the start. Nothing in that design is immediate, visible to colleagues, or a matter of standing.

Gamification is a different intervention. It has its own literature. Improving Phishing Reporting Using Security Gamification, by Matthew L. Jensen, Ryan T. Wright, Alexandra Durcikova and Shamya Karumbaiah, appeared in the Journal of Management Information Systems in 2022. Three experiments in a simulated work setting, separating validation, attribution, incentives and public presentation.

Our findings suggest public attribution with rewards and punishments best balance the competing necessities of accuracy with widespread reporting.

Public attribution is the variable the chocolate box did not have. A visible, attributed standing among peers is the thing that moved reporting, and the authors report a cost attached to it.

However, we also noted that unintended consequences in false alarms might arise from shifts in motivation resulting from public display of incentives.

That cost lands on the security team, as queue volume. It is the correct place for it to land.

One is a field study of a delayed material prize at a real company, with high ecological validity and a null result. The other is a controlled study of visible attribution in a simulated setting, with a positive result on reporting and a named side effect. A box of chocolate three weeks later does nothing. A leaderboard with your name on it does something. Some of what it does is noise.

The gamification result complicates the easy version of this argument on punishment. The balance Jensen and colleagues report came from public attribution with rewards and punishments together, measured against reporting accuracy in a simulated setting.

Every study here measures behaviour inside the reporting channel. Click rate, report rate, report accuracy. None of them measures whether the organization goes on using its email. That is the cost this pattern is about and it sits outside all of this literature. The claim rests on reported practice and on the DORA psychological safety finding.

What is solid across all of it. Enforcing training does not help. The effect the exercise does have comes from the nudge, the periodic reminder that phishing exists. The reporting channel is the capability worth building. The 2022 field study is specific about that.

using the employees as a collective phishing detection mechanism is practical in large organizations

Fourteen thousand people with a reporting button detected new campaigns quickly, at an operational load the organization could absorb, and they kept reporting over fifteen months. With no prize attached at all. That is a detection capability built out of colleagues who were willing to raise a hand. It is also the first thing a punished population stops providing.

Pattern six, review latency sets the price of doing it properly

People optimize against the price they actually face. The control's output is the workaround whenever the sanctioned path costs more than the unsanctioned one. Risk was relocated and hidden. None of it was reduced. The debt arrives on somebody else's quarter.

The misnamed subnet

The subnet named legacy-billing-dmz opened this piece. Nineteen days per request, nine services, three years.

The audit finding is the attributable part. The review process produced the finding. The finding landed on the team that was routing around the review process. No record anywhere names the nineteen day median as a cause.

Schrödinger's sandbox

An infrastructure team builds a sandbox for a development team and provisions it generously, with long-lived privileges inside the environment. That exceeds what most developers are granted anywhere.

The sandbox excludes the ability to manage role assignments, to work with the directory, or to create service accounts. Those capabilities remain with the infrastructure team.

The network is hub and spoke. User machines sit in the hub. Spoke resources are reachable through private endpoints. A resource created in the sandbox is therefore unreachable from any employee laptop until somebody adds an endpoint. Few people hold that permission. The hub carries no infrastructure as code and is treated as production, placing every addition under change management.

Every new resource in the sandbox therefore requires a production change request before anyone can reach it. The environment exists for experimentation. Experimentation produces new resources continuously. No mechanism was ever provided to close that gap.

Most of the development team stopped standing up new resources, since reaching one costs a change request against production. Development narrowed to what could be done inside the resources that already existed.

The teams holding access to an executive spent that access. An escalation of this kind does not resolve once. It produces one of three standing arrangements. The process routes permanently through an executive who did not ask for it and will not sustain it. One team acquires a person with standing to push changes through regardless of their quality. A limited infrastructure or security resource spends several slots a day approving that team's requests by hand.

Other teams constructed their own routes. Those routes are undocumented and held together by whoever built them.

Some teams stood up publicly reachable resources with no private endpoint, since that was the only configuration completable without waiting on another party. A number of those teams did not know what the configuration exposed.

None of it reaches policy enforcement. Some of those people hold no awareness that there is anything to report. The ones who do know withhold it, since reporting costs them the only working path they have.

Teams also introduced their own tooling for problems the sanctioned tools were too restricted to solve. Conversations moved to channels the controls do not cover. For the person moving them, that carried less exposure than the sanctioned route.

What both produce

DORA, citing the 2019 State of DevOps Report, measured whether the slow path buys anything.

no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates

heavyweight approaches tend to slow down the delivery process leading to the release of larger batches less frequently, with an accompanying higher impact on the production system

Accelerate reports the fuller result from the same research program. External approvals were negatively correlated with lead time, deployment frequency and restore time, and uncorrelated with change fail rate.

What it cost. Time, nineteen days per request in one story and a production change request per resource in the other. Money, in engineering salary spent on circumvention and a sandbox that was built, paid for and never used. Observability, in nine services inside a subnet whose name stopped describing it years ago, undocumented routes nobody wrote down, and resources standing outside policy enforcement. Communication, in conversations moved to channels the controls do not cover. Morale, since most of the developers stopped trying and the ones who did not are spending their week on the barrier. Security, in a security group nobody chose and in publicly reachable resources the control existed to prevent.

The organization lost sight of its own estate. It lost it specifically among the people best placed to report what is there.

What the team spent. Authority, nineteen days at a time. A price that high moves the decision to whoever can avoid paying it. The control is now formally in force over an estate containing exactly what it was written to exclude. Trust, with teams that learned the sanctioned path is the expensive one, far enough that their working arrangement depends on the security team not finding out about it. Goodwill, with an auditor who asked a question and got the review queue as the answer, and with a leadership that paid for a sandbox and received an unused one.

The mitigation. A change latency budget, published by the security team as its own number, measured per request class and reported when missed. Name in advance what happens when the budget is blown. Make the answer allow with audit.

Security teams that treat colleagues as the threat

The people on the other side of the control are a risk to contain. That assumption produces the sandbox directly. Privileges go inside a boundary. The capabilities that would let somebody change the boundary stay out. Changing the boundary is the thing being defended against. The developers become a population to manage. The design did what it was built to do. Their inability to work never registered as a failure of it.

A team holding that assumption works against its own organization by construction. The organization is the thing the team was hired to protect. The people in it are the organization.

A cost center costs its salaries. That part is budgeted. This one also costs a share of every other department's budget, in labor nobody books against it.

NIST ran a diary study over a single 24-hour day, published as NISTIR 7983 by Michelle Steves, Dana Chisnell, Angela Sasse, Kat Krol, Mary Theofanos and Hannah Wald. Participants logged 528 authentication events between them.

On average, participants authenticated 23 times during this period, with the lowest number of authentication events being 4 and the highest 40.

The report names what that produces. It connects the result to the same literature.

authentication fatigue, is conceptually related to the compliance budget and compliance threshold: it is a nearly perpetual state of stress and exhaustion experienced by technology users who are overwhelmed by authentication-related demands on their time, energy, and memory

The study counts the events and stops there. Nobody converts them into hours and nobody bills them to the team that created them. A security team that consumes more value than it protects, while declining to measure the consumption, is eroding the business that pays for it.

Why the next standard fails before it ships

Every engineer in that account now carries a generalization. A system that comes under a standard becomes slower to use. Nothing arrives to replace what the standard took away. Nobody read that anywhere. They derived it from this environment, repeatedly.

The next platform the organization tries to centralize meets that generalization. So does the one after it. The resistance is empirical. The organization supplied the evidence.

Circumvention becomes a skill. People get good at it. They teach it to the engineer who joins next, in the first week, as part of how work gets done here.

An organization can build the good self-service platform eighteen months later, ship it properly, and still find nobody moves to it. The population it is offering the platform to has already learned what a standard does to them.

Why all of this is so important now

A nineteen day approval was survivable when the change it gated also took weeks. Review latency was a rounding error against implementation time. The process was designed in a world where that held.

An AI-assisted change now lands in minutes. The approval still runs on human queue time. No tooling has shortened that side of it. The ordering reversed. Implementation is the rounding error now. Review is the schedule.

DORA measured the change advisory board by name

DORA's capability on streamlining change approval defines what it tested.

approval by people external to the team proposing the change: a change advisory board (CAB) or a senior manager

The board is the object of the finding quoted in the standards section above. No evidence supported the hypothesis that a more formal external review process was associated with lower change fail rates. The same page gives the mechanism.

people that far removed from the change might not understand the implications of those changes

The same research found heavyweight approval slows delivery into larger and less frequent batches, with a higher impact on production when those batches land. That measurement predates AI-assisted development by years. The board was already not buying what it claimed. The organizations running it were already paying for it in delivery time. AI did not make the assumption false. It made being wrong expensive.

A security team defending a board on safety grounds is defending a position the industry's own delivery research measured and did not find. It is untenable when the thing on the other side of the gate takes four minutes to produce.

A queue's cost scales with the volume entering it

A review queue costs an organization the number of changes passing through it, multiplied by the time each one waits. Human capacity sets the time per change. How fast a team can produce work sets the number of changes.

One of those terms moved by an order of magnitude. Nobody renegotiated the other. A nineteen day median absorbing several times its previous inbound volume does not stay a nineteen day median. Queues lengthen under load.

So the same process, with nothing touched, is now a different control. It gets more expensive every quarter and nobody decided that. A friction cost that was a few percent of delivery time is now most of it.

The people paying it are working at a speed the approval path has no answer for. The predictable response is the one in pattern six, at a larger scale and across more teams.

Segregation of duties does not require a board

The usual defence is that somebody other than the author has to approve a change. That requirement is real and it appears in contracts and regulations. DORA states it.

changes must be approved by someone other than the author, thus ensuring that no individual has end-to-end control over a process

It also says what satisfies it.

Use peer review to meet the goal of segregation of duties, with reviews, comments, and approvals captured in the team's development platform

A reviewer on the team, in the tool the work already lives in, meets the requirement. The board is one implementation of it. Nothing in the requirement names the board. A team citing segregation of duties to defend a nineteen day queue is defending its own implementation.

DORA does not say to abolish the thing either. The same page keeps a role for it.

In the continuous delivery paradigm the CAB still has a vital role, which includes: Facilitating notification and coordination between teams

The role it keeps is coordination and notification. The role it loses is gatekeeping.

Serial approval costs the sum of its reviewers

Automating a template is easy. Automating the judgement of six disciplines is the part nobody ships. It is also the part that produces the nineteen day queue.

The Stenographic Mediator set out a shape for it. A unit of work goes to every concerned party at once and gathers their requirements, questions, costs and sign-off in a single pass. Each party reads the story in its own professional dialect and sees only the concerns that touch it.

Security is one of the parties on that grid. It writes the threat model into the story as its own contribution, in parallel with every other discipline. That is a different job from approving, at the end, a section somebody else wrote. A serial chain costs the sum of its reviewers. A parallel one costs the slowest.

Storyplane is that pattern built as a product, on the premise this piece has been arguing. Development teams now move at AI speed and the governance around them has not changed. It is pre-launch. It specifies a shape and proves nothing yet.

AI multiplies whatever foundation it finds

This piece is a companion to the practitioner series that began with AI development is a communication problem. That piece argued that intent degrades as it passes between people and that AI executes the inherited misunderstanding faster.

The same degradation runs between a security team and the organization it serves. A control is an intent. It has usually lost the reason it existed by the time it reaches the person it constrains.

AI supplies none of that missing reason. A team that cannot say what it is protecting, from whom, and at what cost to the business now produces controls faster. It produces more of the controls it already has. The tooling never asks whether those controls were right.

What a team starts from decides what that speed produces. A team with a threat model, a named actor and a priced impact produces more of what was already correct. A team with a borrowed benchmark and an unexamined control list produces more of the borrowing. That second team can now do far more damage at the same headcount than it could a year ago.

Four practices

Most of the frameworks quoted here predate the problems they describe. The prescription is where the work is.

Security teams study social engineering more closely than any other function in the business. They publish on it, they run exercises against their own colleagues, and most practitioners can name the techniques and the sequence. Almost none of them point any of it in the other direction.

Make the secure path the easy one and people take it. Make it the fast one and they prefer it. Put the reason beside the request and people comply without being compelled. Show one team succeeding with it and the next team asks for it by name. Those are the same levers, aimed at an outcome the organization actually wants. A security team that understands influence this well asks only whether its colleagues can be fooled. The same techniques would answer whether those colleagues can be incentivised into a better security posture. Nobody runs that exercise. Everything below is that exercise.

Build proper training first

Training precedes testing. The exceptions people propose do not survive contact with a real organization.

Training is enablement. Remove retraining as a visible consequence. A penalty attached to participation produces non-participation. That is the outcome an incident cannot survive.

Make the content specific. A developer and an accounts payable clerk face different threats and need different material. A single annual module for the whole company is the single-persona failure in a different costume.

Teach the governance system itself. What exists, how to reach it, what it answers, how long it takes. This is the cheapest item in the whole prescription. It is the fix for every control that shipped silently.

Change the instrument. Measure whether a person can complete the secure path unaided. Measure reporting rate. Measure time to report. A click rate measures the simulation.

Then build the reward side. This is the one practice here that adds to the three accounts. Gamification is an attention and engagement mechanism by design. A program built that way gives people a reason to read internal mail and a reason to answer it. The security function becomes a source of engagement in an organization that needs it. Pattern five covers what the same program does with none of this.

Build low friction governance as a product

The paved road is the deliverable. Other teams choosing to use it is the success condition.

A check taxes the non-compliant, a barrier taxes everyone

A check that runs in a pipeline costs an engineer nothing when they are doing the right thing. It tells them immediately when they are not. It carries no queue, no ticket and no meeting. The same rule imposed as a barrier costs every engineer every time, including the overwhelming majority who were going to comply anyway.

A barrier taxes the compliant to stop the non-compliant. A check taxes only the non-compliant. The second one is also faster, more consistent and auditable, and it scales without headcount.

Policy can go further than naming a rule. A policy that names a rule leaves every engineer to work out the implementation alone. They will each work out a slightly different one. A policy that points at a worked example, a module, a script that already does the thing correctly, removes that work entirely.

A worked example puts the intent in front of the engineer at the start of the task. It guides the work and never blocks it. A rule that arrives at the end can only reject what somebody already built. The engineer never experiences the worked example as a control.

A policy maintained to that standard has stopped being a barrier. It is documentation on how to accomplish the goal, with the security team's intent and requirements already packaged into it. The engineer opens it to find out how to do the thing. The requirements arrive as part of the answer. The policy adds value to the work.

Maintenance is only half of what decides that. The other half is building the policy out from what you know about your own organization. Its responses then fit the cases that actually exist.

Take a cloud policy requiring every Application Gateway to run the WAF_v2 SKU. Microsoft's Cloud Adoption Framework prescribes an architecture that produces a lot of Application Gateways. Its application delivery guidance sets the placement.

Perform application delivery within landing zones for both internal-facing and external-facing applications.

Treat the Application Gateway as an application component and deploy it in a spoke virtual network not as a shared resource in the hub.

An organization following that has a gateway per application, sitting in a spoke, owned by the application team. Private links and private DNS routes point at the spoke gateway from the hub. Everything in the subscription sits behind it and the subscription's concerns stay isolated. Some of those gateways carry internal traffic and nothing else.

The same page attaches a competence requirement to the control the policy mandates.

To interpret Web Application Firewall alerts, you generally need in-depth knowledge of the application to decide whether the messages that trigger those alerts are legitimate.

The other half of that page has to be said too. It recommends Application Gateway v2 with WAF protection and policies enabled for secure delivery of HTTP/S applications. Microsoft is not telling anybody to skip the firewall.

What it is telling you is where the decision lives. The gateway is an application component in a spoke. Reading its alerts takes somebody who knows the application. A blanket rule supplies neither. It cannot separate a gateway terminating external traffic from one doing intra-subscription routing. It mandates a control whose output the provider says requires in-depth application knowledge to interpret.

So the default is not wrong. It is not granular enough to carry a distinction the provider's own architecture creates. A policy built out against your own landing zones carries it. It knows which spokes terminate external traffic. It states which rule applies where. The team's understanding of its own organization now sits where the engineer meets it.

A stale policy is a barrier again. The reader cannot trust what it says. A policy nobody built out is a barrier too. It answers a question the organization never asked.

Shipping the road itself

Automate the common case so the answer is instant and consistent. Put the secure option in the template people already start from. That is Saltzer and Schroeder's fail-safe defaults, moved from the kernel up to the repository. Express policy as code so a decision is reproducible and reviewable. Pre-approve patterns so a routine change needs no human. Reserve human review for the genuinely novel and the genuinely high-consequence. Provide break-glass with audit wherever a queue would otherwise form. The approval itself is the hard part of that road. Serial approval costs the sum of its reviewers, above, sets out a shape for it.

Then gate yourself. Every new restriction passes a self-service test before it ships. Publish your own response latency as a number you own. Treat a miss as your outage.

This costs engineering time that blocking does not. Blocking does not avoid the cost. It bills the cost to another team at a worse rate, in waiting time that never appears on the security budget.

Ship the control like software

A control has users. It has an interface, a success path, a failure mode and a support burden. Every discipline software development already applies to those applies here. A security team is usually shipping without any of them.

Interface standards. The path has to be discoverable, documented where the user already looks, and consistent with the other paths that user follows. A control nobody can find is a control nobody follows.

User acceptance testing. Put the control in front of the people who will live under it before it ships. Watch somebody complete the path end to end. The sandbox described earlier would not have survived one session of this. Somebody would have tried to reach a resource and failed inside ten minutes.

Time cost accounting. A human-in-the-loop step has a price. The price is computable before the control ships.

Costing a control before it ships

How many people does this apply to. How many times a day does each of them hit it. How long does the step take, including the cost of being interrupted. Multiply.

Worked through for step-up authentication on a database connection in a development environment. The inputs below are illustrative. Measure your own.

Input	Value
Engineers affected	40
Times each per working day	12
Seconds per prompt, including the interruption	25
Cost per day	3 hours 20 minutes
Cost per working year	roughly 830 engineer-hours

That is half an engineer, every year, inside one control. The number is available before anything ships. Producing it costs an afternoon.

Then the second question. What is the risk in this environment, measured against production. The development environment in that example holds no customer data and no production credential. The threat the control addresses is a production threat. The control was copied across without the risk being recompared.

A control costing half an engineer a year to defend a tier with nothing in it has failed the only test that matters. Neither number was ever produced. Nobody was in a position to see it.

Both questions are cheap. Both are answerable before a line of policy is written. Neither is asked in most organizations. Nobody owns the answer.

Communicate and learn the business you serve

Talk to the affected team before the control ships. The conversation is cheaper than the control. It frequently replaces it. Most adversarial controls in most organizations exist because one person did one thing once and nobody had the conversation.

Learn how the organization makes money and how it delivers. Know which systems carry revenue, which carry payroll, and what a day of downtime costs in the units the finance function already uses. An impact cannot be priced in a language the person pricing it does not speak.

Bring the people who carry the risk into the decision that assigns it. A risk decision made for someone, without them, is a transfer.

Announce changes where people already look. This is the same rule that documentation is beating your AI stack applies to code context, pointed at a different audience. Put the information where the reader already is.

A policy response that explains itself and points at a working template is that same model, aimed at a machine as well as a person. An agent reading a rejection that names the rule and links the correct pattern can apply the fix with nobody asked. A rejection that says denied gives it nothing to work with. That makes a well-maintained policy system an accelerant for an AI-assisted team. A terse one slows the same team down.

A gate that returns a usable answer gets satisfied at the speed the team is working at. A gate that returns a refusal becomes the queue in pattern six.

Hawaii Pacific Health asked its staff what to delete

Melinda Ashton published Getting Rid of Stupid Stuff in the New England Journal of Medicine in November 2018. Her health system ran the program this piece has been arguing for, in a different industry, and published the numbers.

Starting in October 2017, we asked all employees to look at their daily documentation experience and nominate anything in the EHR that they thought was poorly designed, unnecessary, or just plain stupid.

Stupid is in the eye of the beholder. Everything that we might now call stupid was thought to be a good idea at some point.

Nobody has to be wrong for something to come out.

One nomination was a single click on a nursing form.

We were surprised to find that making this single click consumed approximately 1700 nursing hours per month at our four hospitals (given the average number of clicks per month and the fact that each nurse or nursing assistant spent 24 seconds per click).

Clicks per month multiplied by 24 seconds. That is the whole instrument. It returned 1700 hours a month from one row in a form. The same arithmetic works on an authentication prompt, an elevation request or a change ticket.

The paper also reports what the nominations revealed about ignored controls.

Although they were not formally submitted as nominations, we have removed 10 of the 12 most frequent alerts for physicians because they were simply being ignored.

Nurses had been burdened with these documentation requirements for years, but they had never been specifically invited to bring their issues to the attention of people who could make changes.

Nominations from nurses outnumbered those from physicians, 146 to 42. Of the nursing requests, 68 were completed and 18 were not possible. On outcomes, the paper says it is too early to have seen any measurable improvement in employee engagement.

Derive controls from your own organization

Security varies by organization and across the personas inside it. Your threat model, your stack, your data, your regulators and your customers set your requirement. A published benchmark and a vendor default are inputs to that derivation.

One persona does not fit an organization. One environment tier does not fit every environment. A sandbox with no real data and no production credential is governed as what it is. A sandbox holding production data is itself the finding.

A control with no named threat and no named asset is not security work yet.

The single question that does the most work here is attribution. For every control aimed at an internal user, name the actor. A control defending against the colleague is an insider threat control. A control defending against someone abusing that colleague's access belongs on the access path. That one leaves the colleague alone.

An insider threat control is a legitimate thing to build. It needs a mandate. The mandate is the part that usually does not exist.

A mandate is the written authority to treat your own employees as a threat surface. It names who approved it, what it covers, the population it applies to, and what happens to a person it flags. Legal reviews it. Monitoring and restricting employees carries employment and privacy obligations that differ by jurisdiction. HR reviews it too. The consequences land on employees and somebody has to administer them. An owner signs it.

So the test is short. Find the document. A team that cannot produce one is running an insider threat program it was never granted. It built that program one control at a time, with nobody deciding to.

Most internal friction is built as though the actor were the colleague. Almost every threat model says otherwise.

Twelve artifacts

Each one is a table completed against a real environment. None of them is a score. Each produces a count of rows that failed. That count is an argument for one conversation.

The order matters. Each question needs the answer to the one above it.

1. What do we actually need to do. Mandate ledger, adversary attribution check, trustless cost test.
2. What are we transferring to other people. What are we deciding that is not ours to decide. Risk decision ownership grid, friction budget, workaround ledger.
3. What people and environments are actually out there. What do they need. Persona and environment matrix.
4. Can anybody use what we built. Does anybody know it exists. Self-service test, change latency budget, awareness check.
5. What runs before anything ships. Training-before-testing sequence, destructive action pre-mortem.

Artifact	What a completed one gives you	What a failing row tells you
Mandate ledger	A named source per control, from a client contract clause, an insurer requirement, a regulation, an internal threat model, or "we chose it"	The first three are requirements. The last two are optional
Adversary attribution check	A named actor for every control aimed at an internal user	A colleague named as the actor is an insider threat control with no insider threat mandate behind it
Trustless cost test	The end-to-end price of removing trust from one interaction	A price nobody will pay. The interaction has to be trusted
Risk decision ownership grid	Who pays, who owns the residual risk, who signs	Your own team in every column is a unilateral risk transfer
Friction budget	Minutes per week per persona, ranked by value bought	The bottom quartile is the deletion queue, with every unattributed row already in it
Workaround ledger	The cheapest route around each control	A workaround cheaper than complying is likely buying a worse outcome
Persona and environment matrix	Control intensity and approver per persona per tier	A production control on a tier holding no production data is applied to the wrong tier
Self-service test	A pass or fail on five named checks, per restriction	Any restriction failing any of the five is a queue
Change latency budget	Your published response time per request class	Any class with no published number is a cost nobody has owned
Awareness check	Whether people can name and reach your governance system	Anybody who cannot is evidence the governance shipped silently
Training-before-testing sequence	The order, the dates, what gets measured	A simulation dated before the training is a trap with your own logo on it
Destructive action pre-mortem	What breaks, who finds out, what the rollback is	Any field blank at the point of action means nobody accepted the risk

A fill-in spreadsheet with one tab per artifact is at friction-budget-worksheets.xlsx.

Run the mandate ledger first. Nothing else has anything to sort on until every control traces to a client contract, an insurer requirement, a cited regulation or a threat model with a named actor and asset. Everything left as "we chose it" is elective. An elective control competes for the same engineering time as everything else. The mandate ledger, the adversary attribution check and the awareness check need no instrumentation and run in an afternoon. The friction budget needs a persona timed through a working week. The change latency budget needs ticket history. Those two are not where to start.

What the job actually is

A security team keeps an organization able to operate safely. An operating organization changes constantly. The job is to let it change as rapidly as possible under the control set that best fits its needs. Trust is what it spends doing that. Trust is also what it exists to protect. The thing it spends and the thing it protects are one resource.

The line usually attributed to Gene Spafford describes the end state.

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards

That system is perfectly secure and it serves nobody. Every control moves some distance toward it. The failure comes from not measuring the impact those controls have on the business and never asking whether they were necessary in the first place.

Source notes

Every quotation above was checked against its primary document. Every source is linked. The note also records where a document is commonly cited for more than it says.

• NIST SP 800-207, Zero Trust Architecture, Rose, Borchert, Mitchell and Connelly, August 2020.

• The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024.

• DORA, on streamlining change approval and on generative organizational culture, both citing the 2019 State of DevOps Report. The four-way correlation result is from Accelerate, Forsgren, Humble and Kim, 2018.

• The Protection of Information in Computer Systems, Saltzer and Schroeder, Communications of the ACM, July 1974, revised 1975.

• Phishing in Organizations: Findings from a Large-Scale and Long-Term Study, Daniele Lain, Kari Kostiainen and Srdjan Čapkun, IEEE Symposium on Security and Privacy, 2022. Fifteen months, more than fourteen thousand employees of a partner company.

• Content, Nudges and Incentives: A Study on the Effectiveness and Perception of Embedded Phishing Training, Daniele Lain, Tarek Jost, Sinisa Matetic, Kari Kostiainen and Srdjan Čapkun. ACM CCS 2024, pages 4182 to 4196, DOI 10.1145/3658644.3690348. Distinguished Paper Award. The reward tested was a box of chocolate distributed after roughly three weeks. That is the scope of the null result.

• Improving Phishing Reporting Using Security Gamification, Matthew L. Jensen, Ryan T. Wright, Alexandra Durcikova and Shamya Karumbaiah. Journal of Management Information Systems, volume 39, issue 3, 2022, pages 793 to 823. Abstract readable at jmis-web.org. Three experiments in a simulated work setting, separating validation, attribution, incentives and public presentation.

• Security Fatigue, Brian C. Stanton, Sandra S. Prettyman, Mary F. Theofanos and Susanne M. Furman. IEEE IT Professional, volume 18, issue 5, September 2016, pages 26 to 32. NIST's own publication record names the journal as IEEE Software and dates it October 2016. The publisher's record behind the DOI names IT Professional, volume 18, issue 5, September 2016. The publisher's record is used here.

• Implementing Number Matching in MFA Applications, CISA fact sheet, October 2022.

• CIS Benchmark profile definitions, Level 1 and Level 2, from the CIS knowledge base.

• ISO/IEC 27001:2022 clauses 6.1.2 c) 2) and 6.1.3 b) through f). Quoted from the standard text. The link goes to the ISO catalogue entry, since ISO sells the document and does not publish it openly.

• The Nature of the Firm, R. H. Coase, Economica, volume 4, issue 16, November 1937, pages 386 to 405. The 1991 prize motivation reads "for his discovery and clarification of the significance of transaction costs and property rights for the institutional structure and functioning of the economy". The prize covers a body of work. This paper began it.

Some anchors were deliberately left out. A proof-of-work energy figure ages within months and needs its method explained before it means anything. Fukuyama on high-trust and low-trust economies carries contested national generalizations. The DORA and Westrum material already makes the same claim with a measurement behind it. No general claim is made here about what insurers require for phishing simulation. Policy language varies by carrier. No authoritative general wording was found. Read your own policy.