Disciplines
Discipline Focus: A rule that holds only if it holds without exception.
There was one rule on the trading floor that nobody argued with, not because it was popular, but because it was absolute. Moves, adds, and changes (MACs) to the trading floor environment never happened on a weekday night. Not a system update, not a configuration change, not a hardware swap. If it touched the floor, it waited for the weekend.
There was exactly one exception, and it was named in advance: a genuine emergency, a security patch that could not wait, or an active risk exposure. Nothing else qualified. Nobody got to decide in the moment that their change was important enough to be the exception. The exception already existed, on paper, before anyone needed it.
That is the difference between discipline and rigidity. Rigidity has no exceptions. Discipline has exceptions, but they are decided in advance, not negotiated under pressure.
Thirty Minutes, Because the Parts Were Already There
The floor also ran under a thirty-minute response time for break-fix issues. A failed terminal, a dead connection, a piece of hardware that stopped working mid-session, all of it had to be resolved inside thirty minutes.
That number only worked because of a decision made long before anything ever broke. Spare parts sat in lockers on or near the floor itself. Nobody drove to a warehouse when something failed. Nobody waited on a shipment. The part that would be needed was already staged, already there, before the failure happened.
This is the same discipline that shows up everywhere else in this series: the response looks fast because the preparation happened early. A thirty-minute fix is not a talent. It is the visible result of an invisible decision made weeks or months earlier to stock the parts before they were needed.
Then and Now
Trading floors today are quieter than they were. Most of what used to require a person standing at a terminal now happens electronically, routed through systems that never sleep and rarely need a human hand on the floor itself.
The discipline did not disappear when the floor got quiet. It moved. The same principle, no unscheduled changes to a live production environment, spare capability staged before it is needed, now lives inside change management windows, deployment pipelines, and failover systems instead of physical lockers and weekend-only cutovers. The technology changed completely. The discipline underneath it did not move an inch.
A Federal Environment That Recommends Discipline Instead of Demanding It
The federal government has spent the better part of a decade trying to build exactly this kind of discipline into how agencies secure the software and systems they run. Executive Order 14028, in 2021, set the intent. Executive Order 14144, in January 2025, tried to centralize the mechanism, a common attestation form, a single CISA-run validation repository, one place where every agency could point to prove a vendor's security posture had been checked.
Executive Order 14306, in June 2025, and OMB Memorandum M-26-05 that followed it, took that centralized mechanism apart. The standardized attestation requirement was rescinded. In its place, each agency was directed to build its own risk-based assurance process.
On its face, that sounds reasonable. Different agencies have different missions and different risk tolerances. But the guidance never separated mission-specific systems from common, enterprise-wide products. A specialized application built for one agency's unique mission genuinely may need a tailored risk approach. A common productivity suite, a standard operating system build, a commercial email platform, used identically across dozens of agencies, does not.
There are more than four hundred federal departments, agencies, and sub-agencies. Under the current approach, a vendor selling one of these common products into the federal government is not facing twenty variations of an attestation requirement. It is facing the possibility of four hundred, each one potentially different, each one defined independently by an agency CIO and Contracting Officer with no obligation to align with what the agency next door decided. And it does not stop at the vendor. The same fragmentation cascades down through every third-party supplier and subcontractor feeding into that vendor's product, since the underlying supply chain guidance was never limited to prime vendors in the first place.
No vendor, however large, can sustainably comply with four hundred different interpretations of the same underlying security posture for the same product. Either vendors quietly standardize on their own interpretation and hope it satisfies everyone, which defeats the purpose of individualized risk review, or agencies get inconsistent, difficult-to-verify assurances because no vendor can keep pace with hundreds of bespoke demands. Either way, the discipline the policy was meant to create does not survive contact with its own scale.
It gets worse over time, not just at a single point in time. A common product does not stay static. Vendors ship version updates, patches, and feature changes constantly, and under the current approach, each of those changes potentially triggers the need for a new attestation. Whether it does is left to each individual agency CIO to decide. One agency may determine a minor version update requires re-attestation. Another may decide it does not. There is no shared standard for what counts as a material change, only four hundred separate judgment calls, repeated every time the product changes. The fragmentation problem does not happen once and settle. It compounds with every release cycle, across every agency, indefinitely.
This is not just a security problem. It is a cost problem and an administration problem, and the two compound each other. Four hundred agencies negotiating the same common product four hundred separate ways means nobody is buying at the volume that would earn real pricing leverage, the discounts a single federal-wide agreement could command disappear into fragmented, agency-by-agency purchasing. And every one of those four hundred separate arrangements carries its own contract vehicle, its own security review, its own vendor relationship, its own renewal cycle. The administrative burden scales with the fragmentation, not with the actual risk being managed. None of this is complexity in service of better security. It is complexity that exists purely because nobody enforced a standard.
I saw this exact failure play out from the inside, years before any of these executive orders existed. Different sub-agencies within the same department ran separate contracts for the same common productivity suite, and maintained four different email systems, because nothing forced standardization from the top. Nobody drove a common standard, so fragmentation grew in the vacuum, at real cost, for years, with no security benefit to show for it.
What Demanded Discipline Would Actually Look Like
The fix is not complicated, and it does not require inventing anything new. Common, enterprise-wide products, the software and platforms used identically across the federal government, should be governed by a single standard, set by the Federal CIO's office and whoever holds authority over Contracting Officer requirements, and communicated as an expectation to all four hundred-plus agency CIOs. Change management for those common products belongs in the same place.
This does not mean the Federal CIO's office does the infrastructure work. Agencies still own their own execution, their own environments, their own operational realities. What agencies should not own is the right to redefine the security standard for a product that is identical whether it is running at one agency or all of them.
That is precisely the model the trading floor ran on. There was not a different MACs rule for every trading floor. There was one rule, and every floor executed against it. The federal government's common-product problem is the same failure at an entirely different scale: no single owner insisting on one standard, so four hundred interpretations grew where one should have existed.
Discipline, In Three Sentences
Strip away the trading floor and the federal agencies, and this is what discipline actually is.
Discipline is not rigidity. Rigidity has no exceptions. Discipline has exceptions, but they are decided in advance, not negotiated under pressure.
A fast response is not a talent. It is the visible result of an invisible decision made long before anything failed.
And discipline does not erode gradually. It ends the first time an exception gets made without having been named in advance.
Everything else in this article, the MACs rule, the lockers, the four hundred agencies, is proof. This is the definition.
The Failure Mode
That is true on a trading floor and it is true across four hundred federal agencies. A standard that exists on paper but bends under budget pressure, schedule pressure, or the argument that this agency's situation is different, is not a standard. It is a recommendation wearing a standard's name.
The AI-Era Parallel
Every organization racing to deploy AI right now is under exactly the kind of pressure that breaks discipline. Timelines are short, competitors are moving, and the easiest thing in the world is to make an undocumented exception, skip a review this once, waive a control just for this deployment, because the schedule cannot absorb the delay.
That is the precise moment discipline is supposed to hold, not the moment it is convenient to hold. An organization that cannot say no to an undocumented AI exception today will not be able to say no to the next one either, and the one after that stops being an exception at all.
Where This Leads
Discipline is the fifth pillar in the IT Risk and Cybersecurity Governance Framework because it is what makes Governance, Authority & Relationships mean something day to day. Authority can assign the rule. Only discipline makes the rule survive the four hundredth ordinary Tuesday, not just the first Friday it was written.
It started with a rule that could not be broken on a weekday night, and parts staged in lockers before anything failed. It shows up today in four hundred-plus federal agencies deciding, one at a time, whether a security standard means what it says. And it will show up tomorrow in whether an organization can hold the line on an AI system the same way it held the line on a trading floor, before the pressure arrives, not during it.
This is Pillar 5 of 8 in the IT Risk and Cybersecurity Governance Framework series. Read the full Framework at MVWConsultants.com/framework.