Trust Was the Product
There are controlled IT environments, and then there is commercial Public Key Infrastructure. For several years, I served as the system architect for a commercial certificate authority built early in the history of commercial PKI, when relatively few organizations in the world were doing this work at scale. Trust was not an abstraction for us. It was the product.
The certificates issued by that system were useful precisely because people, businesses, software vendors, and other organizations could trust the infrastructure behind them. Compromise that trust and you did not simply have an outage to explain. You potentially undermined the thing you existed to provide. Accordingly, the controls surrounding the environment were extraordinary.
I have worked in security and governance for much of my career, and I have encountered few commercial IT environments with comparable physical controls. The closest analogues are probably facilities protecting considerably more dramatic things than servers. Even as the architect of the system, I could not enter the space containing it alone. Physical access required two authorized individuals, and before those two people could enter the secured cage containing the PKI infrastructure, we contacted the Security Operations Center and obtained verbal authorization from the CISO.
That only got us to the cage. Access involved physical keys and biometric authentication, and moving deeper into the environment meant encountering additional layers of control. Individual server cages and enclosures were separately protected by mechanisms that included magnetic spin locks and vascular biometric sensors. Getting into the room was not getting into the system. Getting through the cage was not getting to the servers. Being the system architect did not mean I could do any of it alone.
This was not bureaucratic theater. The architecture was deliberately designed around separation of duties and resistance to collusion. No individual was supposed to possess enough authority, access, or knowledge to compromise the system independently. Administrative controls reinforced physical controls; physical controls reinforced technical controls. The system did not merely instruct people to behave securely. Wherever practical, it was designed so that they had to.
On paper, it was formidable. In practice, it was formidable too. That distinction matters, because this is not a story about an organization with beautiful policies nobody followed or employees casually circumventing security controls because they were inconvenient. The people operating the environment understood exactly what we were protecting and why the controls existed. We followed them. We also had work to do.
The People Inside the System
For all of that infrastructure, only about eight people in the company had the authorization necessary to access the PKI systems physically. On paper, that was plenty. Three were C-suite executives. Another was the director responsible for the PKI operation itself. Two had responsibilities for adjacent infrastructure and support functions. That left two of us who routinely performed hands-on engineering work inside the environment.
There is a consequential difference between being authorized to perform work and being someone who actually performs that work on an ordinary Tuesday. If one of us was unavailable, there were technically other authorized people in the organization. But calling a senior executive and asking whether they could swing by the data center because a piece of infrastructure needed attention was not much of an operating model. Still, we made it work.
Then one of the locks started getting fussy. Of all the sophisticated controls protecting this extraordinarily sensitive environment, the problem came from something remarkably mundane: a magnetic spin lock that was beginning to degrade. Two distinct combinations were required, and increasingly one of them simply would not work. You could have the correct combination, enter it correctly, and try again. Nothing.
When that happened, all of the other controls became almost irrelevant. We could have two properly authorized people standing there. We could have approval to enter and have passed every preceding physical and biometric control. But if that lock decided not to cooperate, we were not getting to the equipment. The designed system had met a very ordinary physical reality, and reality was winning.
The Small Adaptation That Changed the Architecture
So we adapted. Each of us gained access to an additional combination held by another authorized individual. If one combination refused to work, there was another available. We had not simply decided to ignore the rules: sharing physical access keys was not prohibited, nor was there an explicit provision governing individual knowledge of the lock combinations. The controls still required authorized personnel, multiple people, multiple factors, and multiple combinations. Operationally, the change made sense.
Security was not meaningfully compromised in the way we encountered the system day to day. Nobody could wander into the data center and start opening PKI servers. Every preceding layer remained in place, and two authorized individuals still had to be present to reach the point where the combination mattered at all. We continued to observe two-person integrity. We never used the additional knowledge to enter a server enclosure alone.
But we could have.
That is where the story becomes interesting. Nothing dramatic happened. There was no breach, incident, malicious act, or decision that security had become inconvenient and therefore optional. As far as I can recall, we had not even violated an explicit rule. We encountered a degrading component in a complicated system and made a small, reasonable adaptation that allowed us to continue doing our jobs.
Yet the system had changed. The physical security architecture had been designed around an assumption: no single individual would possess sufficient knowledge to open that enclosure independently. That assumption was no longer true. The documentation, access-control model, list of authorized personnel, and policies had not changed. The organization had not consciously accepted a different risk. Nevertheless, the system that existed on Tuesday was no longer quite the system everyone thought existed.
Nobody had redesigned it. We had simply adapted it. The difference between those two things is where some of the most important work in governance begins.
Observation
A control can remain intact in policy, procedure, and evidence while a reasonable operational adaptation quietly changes the assumption that made the control effective.
Nothing Stays Still
It would be easy to dismiss this as an interesting edge case from an unusually complicated security environment. I think the opposite is true. If operational drift can emerge inside a commercial PKI system—an environment deliberately engineered to constrain change, distribute authority, document behavior, and prevent individuals from acting independently—it can happen almost anywhere. In fact, it does.
There is an old joke in IT that documentation is 100 percent accurate for approximately five minutes after you finish writing it. Then a server is replaced, a vendor releases an update, or a customer needs something the original design did not anticipate. A process that made sense when twelve people used it becomes cumbersome when two hundred people do. A piece of equipment begins to fail. Someone discovers that three steps can safely be accomplished in one. An employee leaves with a small piece of institutional knowledge nobody realized was unwritten.
The system adapts, because that is what systems do—and not only technical systems. A warehouse worker changes where a frequently used tool is stored because walking across the building fifty times a day makes no sense. An accounting team creates a spreadsheet because the ERP system does not produce the report leadership needs. A project manager adds an informal approval step after being burned twice by the formal process. A customer service representative develops a clearer explanation for a confusing policy and teaches it to the person sitting beside them.
None of these adaptations necessarily represents failure. Some are improvements, some are harmless, and some expose flaws in the original design. Others create risks nobody recognizes until much later. A few are the only reason the designed system continues functioning at all. That last category is particularly important because governance tends to imagine the documented process as reality and deviations from it as defects: if people would simply follow the process, the thinking goes, the system would operate as intended.
That gets the relationship backward. The process exists to support the work. The work does not exist to validate the process. When reality changes, people adapt because customers still need answers, orders still have to ship, payroll still has to run, systems still fail, and deadlines still arrive. The people closest to the work encounter those realities first, so they make adjustments—usually small ones, which is precisely why they can be so difficult to see.
There is rarely a meeting in which someone announces that the organization will now operate differently from its documented design. There is no ribbon cutting for the unofficial process and no organizational-chart update because someone created a spreadsheet that makes Tuesday afternoon possible. People solve the problem in front of them. Then they solve it again on Wednesday. Eventually the workaround is no longer a workaround. It is simply how the work gets done.
This is how documentation becomes an imperfect record of organizational reality—not because anyone is dishonest or incompetent, but because documentation is necessarily a snapshot of something that keeps moving after the shutter closes. Policies describe intent. Procedures describe a designed method. Architecture diagrams describe an understood system. Organizational charts describe formal relationships. All are useful. None can guarantee that the organization still behaves that way.
Pattern
Reasonable adaptations become operational drift when they accumulate without visibility, ownership, or a deliberate decision about whether the design should change.
The Gap Is Information
Governance, risk, compliance, and security functions often reach for judgment the moment reality diverges from design. Someone is performing a control differently than documented. An unofficial tool has entered the workflow. A team has developed a workaround. Something has changed, and the instinctive first question is, Is this compliant?
I think that is usually the wrong first question. The better question is simpler: Why did the system adapt? Asking why does not excuse bad behavior, lower standards, or mean every workaround should be blessed because someone found it convenient. It means only that we have observed something about the system and have not yet decided what it means. The adaptation itself is value neutral. It is information.
In the PKI environment, sharing access to an additional combination changed an assumption embedded in the physical security architecture. That deserved attention and analysis. Perhaps, after analysis, it deserved corrective action. But the most useful question was not whether two experienced engineers were good or bad for doing it. The useful question was why two engineers, working inside an extraordinarily controlled environment and taking those controls seriously, found it necessary to adapt the system in the first place.
We already know the answer: a lock was failing. That simple fact changes the conversation. If the only objective had been to restore procedural conformity, the response might have been straightforward—stop sharing the additional combination and return to the intended access model. The deviation would have been corrected, but the condition that produced it would remain. The lock would still be failing, and another adaptation would almost certainly follow.
This is why I am wary of treating noncompliance as synonymous with failure. A finding, deviation, workaround, or exception is information about the relationship between the system we designed and the environment in which it is actually operating. Sometimes that information tells us people need better training. Sometimes it reveals an ineffective control, a process that no longer matches the work, or a risk requiring immediate correction. Sometimes it shows that the people closest to the work have quietly designed a better way to accomplish it.
We cannot know which one we are looking at until we become curious enough to investigate. Correcting the visible deviation before understanding its cause may create conformity for the assessment and preserve the condition that guarantees the deviation will return. Governance becomes more capable when it can hold two ideas at once: the organization may need to bring reality back toward the design, and the design may need to catch up with reality.
Why Organizations Stop Seeing
Curiosity requires something surprisingly difficult: the people doing the work have to feel safe enough to tell us the truth. This may be one of the great ironies of compliance programs. The more severely an organization reacts to deviations, the less likely it becomes that the organization will learn about them. If admitting that you adapted a process means being reprimanded, blamed for an audit finding, or dragged into an uncomfortable meeting with senior management, the rational response is not mysterious. You stop volunteering information.
The workaround does not disappear; the organization merely loses visibility into it. Now the documented organization and the operating organization can continue to separate while the mechanisms intended to provide governance can no longer see the distance growing between them. Leadership may believe the documented process is being followed. Auditors may sample evidence against that process. Dashboards may report perfectly respectable numbers. Everyone may be telling the truth, and the organization may still be drifting.
Operational drift does not require negligence, incompetence, or even noncompliance. It requires only a system operating over time, and reality. Reality supplies failing hardware, staff turnover, unusual customers, new technology, aging technology, growth, shortages, deadlines, regulations, budget constraints, and thousands of circumstances nobody anticipated when the process was designed. People respond, and the accumulation of those responses gradually changes how the system actually operates.
Some changes make the system better, some make it worse, and most probably do a little of both. The job of governance is not to prevent adaptation. It could not if it tried. The job is to see adaptation early enough that the organization can understand it and choose what to do.
Question
What would your people show you if they knew the first response would be curiosity rather than correction?
The Tuesday Assessment
Seeing operational reality is harder than it sounds because the moment you announce that you are coming to assess a process, the process changes. Documentation gets reviewed. Old procedures get updated. Managers remind people how things are supposed to work. Questions get anticipated. Everyone becomes slightly more careful about what they say and considerably more careful about what they show you. The organization begins performing.
This is not necessarily deception. It is human behavior. People understand when they are being evaluated and respond accordingly, which creates an uncomfortable problem for anyone trying to understand an organization: the more formally you ask the organization to demonstrate how it operates, the greater the risk that you observe the demonstration rather than the operation.
I call the alternative the Tuesday Assessment. The name is intentionally ordinary. Tuesday is not audit day, the quarterly business review, or the executive walkthrough. Tuesday is just Tuesday. The objective is not to catch people doing something wrong. It is to understand the organization while it is busy being itself. That requires three things above all else: proximity, curiosity, and safety.
Proximity
Operational reality lives close to the work. Dashboards, policies, process maps, and leadership interviews all have value, but they describe the system from some distance. Eventually, you have to get closer—close enough to see the difference between the process as represented and the process as experienced, and close enough to notice adaptations that have become so ordinary the people performing them may no longer think to mention them. Close enough to see Tuesday.
Curiosity
Observation without curiosity quickly becomes inspection. The purpose of discovering a deviation is not merely to prove that it exists but to understand what the system is telling you. Why did this adaptation emerge? What changed? What need is being satisfied? What assumption no longer holds? Those questions come before judgment. The organization may eventually determine that reality must move back toward the design, that the design must catch up with reality, or that both need to change. First, it has to understand what it is looking at.
Safety
None of this works unless people are willing to show you what actually happens. Operational truth cannot be extracted reliably from people who believe honesty will be punished. If every disclosed workaround becomes a finding, every deviation a reprimand, and every uncomfortable observation an escalation, people will learn to perform the documented process whenever someone comes looking. The underlying adaptation will remain. You simply will not see it.
Psychological safety, then, is not merely a cultural aspiration in an operational assessment. It is an information requirement. If people cannot safely describe reality, you cannot reliably observe the system; if you cannot observe the system, you cannot meaningfully govern it. That is the value of the Tuesday Assessment. It is not another audit, checklist, or opportunity to demonstrate how closely reality resembles the binder on the shelf. It is an attempt to see the distance between what we believe happens and what actually happens.
The Danger Is Not Drift
Organizations will adapt because they have to. The world changes too quickly, and human systems are too complicated, for any operating model to remain perfectly synchronized with reality. The danger is not that adaptation occurs. The danger is allowing adaptations to accumulate without becoming visible, because small differences compound.
One workaround becomes standard practice. The person who invented it trains the next person, who assumes it is official. A manager builds another process around it. A technology change makes the original rationale irrelevant, but the workaround remains. Years later, nobody remembers why the organization operates that way. It simply does. By then, the distance between documented intent and operational reality may be enormous, even though every individual step that created the distance was reasonable.
That is operational drift: yesterday’s reasonable adaptation becoming today’s operating model without anyone consciously deciding that it should. The controls you believe exist may not be the controls actually governing behavior. The dependencies you believe matter may no longer be the dependencies keeping the system running. The risks you formally accepted may not be the risks you are carrying, and the resilience you believe you possess may depend on undocumented adaptations known to only a handful of people.
Which brings us back to the server cage: two engineers, a failing magnetic lock, and an additional combination. Nothing happened. That may be the most important part of the story. There was no breach to force an investigation, no outage to trigger a root-cause analysis, and no audit finding demanding corrective action. The system continued operating, and systems that continue operating are remarkably easy to assume are operating correctly.
Reflection
The absence of failure is not evidence that a system still works as designed. It may only mean its adaptations have not failed yet.
That assumption is dangerous. The absence of failure tells you only that the system has not failed yet; it tells you very little about how the system is actually working. A resilient organization cannot wait for an incident to reveal the operating model it already depends upon. It has to become interested in the quiet adaptations that make ordinary work possible long before one of them becomes a headline.
So every once in a while, leave the dashboard behind. Put down the policy and step away from the process map. Go find the people doing the work—not to catch them, correct them, or ask them to perform the system you expect to see. Ask what changed. Ask what gets in the way. Ask where the documented route stops working and what they do next.
Ask them to show you Tuesday.
