This isn’t going to be your typical article on AI governance—or governance in general, for that matter.
And Its Impact on Operational Resilience, Cybersecurity, and AI Governance
Over the past 18 months, I have spent a great deal of time studying security, operational resilience, and AI governance frameworks—an alphabet soup of standards, regulations, and best practices.
My original goal was straightforward. I wanted to understand how these frameworks relate to one another, where they overlap, and whether they could be unified through a common operational model.
As I explored frameworks such as the NIST Cybersecurity Framework, ISO/IEC 27001, the NIST AI Risk Management Framework, DORA, NIS2, and many others, I developed a hypothesis.
Could an organization’s adherence to these frameworks be inferred by assessing the capability of its underlying IT Service Management (ITSM) processes?
So why would this matter? The reason was simple.
I have come to believe that governance doesn’t live in frameworks, policies, controls, or risk registers. It lives in the operational processes that organizations execute every day. Frameworks explain why governance matters. They describe what organizations should do. They define principles, controls, and desired outcomes. What they rarely explain is how those outcomes are achieved operationally.
This is what I have previously referred to as the Execution Gap—the gap between what governance frameworks expect organizations to achieve and what their operational processes consistently deliver. I have come to believe that one of the primary reasons this gap exists is increasing Process Debt. Organizations don’t intentionally fail to operationalize governance. Rather, years of disconnected processes, inconsistent execution, weak governance, and poor integration gradually erode their ability to consistently deliver the outcomes their frameworks require.
The proof is in the pudding.
Organizations continue to experience major operational failures, cybersecurity breaches, project failures, compliance issues, and an increasing number of AI governance failures. Yet many of these same organizations have policies, governance committees, controls, audits, extensive documentation, and are actively pursuing compliance with multiple frameworks.
If the frameworks are sound—and I believe most of them are—why do organizations continue to fail?
The more I looked at these frameworks, the more my original hypothesis was reinforced. Every control, governance activity, resilience objective, cybersecurity safeguard, and AI governance principle is ultimately enacted through operational processes.
Frameworks do not perform work. People executing well-designed operational processes do. It also became evident to me that modern governance is built upon a largely overlooked foundation: an organization’s Process Management System.
A Process Management System is the enterprise capability responsible for designing, governing, integrating, measuring, and continually improving the operational processes that deliver business outcomes. It transforms a collection of individual processes into a coordinated operational system.
When that system is weak, governance becomes inconsistent regardless of how many frameworks an organization adopts.
Fortunately, organizations are not starting from scratch. IT Service Management has spent more than 35 years developing practical guidance for managing operational processes.
- ITIL, introduced in 1989, aligned IT services with the needs of the business and continues to evolve today.
- COBIT, released in 1996, provided governance guidance for enterprise IT
- IBM introduced the IT Process Model during the late 1990s to improve operational resilience.
- Microsoft released the Microsoft Operations Framework in 1999 to provide operational guidance for Microsoft environments.
- ISO/IEC 20000 became the international standard for IT Service Management in 2005.
- Additional guidance such as FitSM, USM, USMBOK, VeriSM, SIAM, and IT4IT has continued to expand the discipline and demonstrate that there is no shortage of guidance on how operational processes should be managed.
Collectively, these bodies of knowledge provide extensive guidance on how operational processes should function.
The problem is not that IT Service Management failed to explain how. Quite the opposite. ITSM provides extensive guidance on how individual operational processes should operate.
The problem is that many organizations never fully implement, integrate, govern, measure, and continually improve those processes as a complete management system.
Instead, they accumulate a collection of disconnected processes—some mature, others immature; some well governed, others neglected; some continually improved, others virtually abandoned.
Over time these deficiencies accumulate. Like technical debt in software engineering, organizations incur a hidden operational liability that quietly grows until it begins affecting operational resilience, cybersecurity, governance, compliance, cost, and ultimately business outcomes.
I call this Process Debt.
What is Process Debt?
Process Debt is the accumulation of deficiencies within an organization’s Process Management System and its operational processes that reduce their ability to consistently deliver intended business outcomes. Like technical debt, Process Debt accumulates over time, increasing operational risk, reducing resilience, raising operating costs, hindering regulatory compliance, and limiting organizational performance.
Process Debt exists at two levels.
Systemic Process Debt
Systemic Process Debt consists of deficiencies within the organization’s Process Management System that prevent its operational processes from functioning as a coordinated enterprise capability. Examples include weak process architecture, inadequate governance, poor integration between processes, inconsistent standards, fragmented ownership, and unmanaged cross-process dependencies. Organizations with significant Systemic Process Debt may have many individual processes, but they operate as disconnected silos rather than as an integrated operational system.
Operational Process Debt
Operational Process Debt consists of deficiencies within an individual operational process that reduce its ability to consistently achieve its intended business outcome.
A process accumulates Operational Process Debt whenever there are shortcomings in the capabilities required to operationalize it effectively. These may include unclear ownership, poor identification within the process architecture, inadequate design or documentation, inconsistent execution, insufficient role definition or training, ineffective governance, limited automation where appropriate, lack of measurement, or the absence of continual improvement.
In other words, Operational Process Debt is not defined by a single weakness. It is the growing number of deficiencies that reduces a process’s ability to perform reliably, consistently, and repeatedly.
This distinction between Systemic Process Debt and Operational Process Debt forms the foundation for the remainder of this article.
Why Do Organizations Accumulate Process Debt?
Treating processes as silos, and failing to truly operationalize them, is the primary reason organizations create Process Debt.
Ultimately, it comes down to the fact that very few organizations view Process Management as an enterprise discipline. Instead, responsibility for processes is delegated to individual business units, departments, or teams.
Of course, that’s where the processes operate. But there also needs to be an enterprise perspective that recognizes each process as part of a larger, interconnected management system. The overall system is only as strong as its weakest process.
Most organizations understand their business risks and regulatory obligations, but they hand those responsibilities off to Governance, Risk, and Compliance (GRC) teams without making the connection to operational process execution.
GRC may verify that the organization has a Patch Management Policy, but that doesn’t necessarily mean patches are being implemented consistently or within required timeframes. The policy exists, the audit box is checked, but the operational process has failed.
This is one of the biggest disconnects I see.
GRC owns the frameworks, but the operational processes live within the business. Too often those processes are never fully operationalized, governed, measured, or continually improved.
How often have you heard that there is no owner for a process? Or perhaps even worse, that there are multiple owners, leaving everyone wondering who is actually accountable?
Processes are frequently documented to varying degrees, executed inconsistently, measured sporadically, and improved only when something goes wrong.
Some processes may be world-class, but organizations don’t succeed because they have a few excellent processes. They succeed because those processes work together as an integrated system.
Imagine a sales organization with an outstanding sales process that consistently generates accurate forecasts. If those forecasts never effectively feed Manufacturing, Supply Chain, or Procurement, the overall system breaks down. Individual process excellence cannot compensate for a disconnected management system.
Without an enterprise Process Management System overseeing how processes are designed, governed, integrated, measured, and continually improved, organizations gradually lose sight of the interconnections between processes. Over time, those disconnects accumulate into Systemic and Operational Process Debt, increasing risk and reducing the organization’s ability to consistently deliver desired business outcomes.
What Are the Sources of Systemic and Operational Process Debt?
Systemic Process Debt is the result of poor Process Architecture, weak enterprise process governance, and a failure to recognize the importance of cross-process integration and dependencies.
It is compounded by a lack of enterprise standards for process identification, documentation, execution, and measurement, along with unclear ownership of the overall process portfolio. Just as important is the disconnect that often develops between business strategy and the operational processes that are intended to support it.
Don’t just take my word for it. Numerous studies by organizations such as Gartner and McKinsey continue to report that digital transformation initiatives have failure rates approaching 70 percent. Many of these transformation projects are, at their core, about digitizing business processes. If the underlying processes are poorly designed, poorly integrated, or carrying significant Process Debt, simply automating them is unlikely to deliver the expected business outcomes.
Operational Process Debt stems from a lack of accountability and clear process ownership, poor process discovery, inconsistent process mapping and documentation, unclear roles and responsibilities, inconsistent execution, ineffective operational oversight, a lack of meaningful metrics and KPIs, and the absence of a systematic approach to continual improvement.
There is also, quite often, a disconnect between the documented process and what is actually implemented in workflow and automation platforms.
Take ServiceNow implementations as an example. If I had a dollar for every time I was told that process documentation wasn’t used as part of the requirements gathering process, I’d be a lot wealthier than I am today. Organizations spend millions implementing workflow automation, yet many never fully understand or document the processes they are trying to automate.
The rapid adoption of AI, particularly agentic AI and intelligent process automation, will only compound the challenges organizations already face. If organizations don’t first address their existing Process Debt—and establish the discipline to prevent new debt from accumulating—they risk automating inconsistency, embedding inefficiency, and scaling poor operational practices faster than ever before.
What Is the Organizational Impact of Process Debt?
The key organizational impact of Process Debt is a lack of operational resilience—the ability to anticipate, prepare for, respond to, and recover from failures. As Process Debt grows, organizations become less flexible and less agile. They also increase their exposure to regulatory findings, financial penalties, and reputational damage.
In addition, Process Debt degrades service quality and customer experience, increases operating costs, limits effective decision-making, and reduces an organization’s ability to adopt and take advantage of new technologies such as AI.
You can see the impact every day through failed digital transformation initiatives and ineffective AI implementations. In many cases, these are not technology failures at all. The underlying business processes are poorly understood, inconsistently executed, and supported by poor-quality data. Organizations spend millions implementing new technology while giving relatively little attention to the operational processes those technologies are intended to support.
I presented at the CRC Conference last year and reviewed a number of operational resilience and cybersecurity case studies. What struck me was that many of the largest operational and security failures of 2025 could ultimately be attributed to process failures rather than technology failures. Technology may have been involved, but the underlying operational processes had not been effectively designed, governed, integrated, or executed. The organizations involved suffered immense financial losses, operational disruption, regulatory scrutiny, and reputational damage.
To me, that is the hidden cost of Process Debt. It quietly accumulates over time until an organization is placed under stress. It is only then that the weaknesses in its operational processes become visible, and by that point the cost of addressing them is far greater than if the debt had been managed from the outset.
How can you measure Operational and Systemic Process debt
Operational and Systemic Process Debt can be measured by assessing the health of an organization’s Process Management System and the capability of its individual operational processes. The greater the number of deficiencies that exist, the greater the organization’s Process Debt.
Systemic Process Debt is measured by looking at the health of the Process Management System itself. Are processes owned? Are they aligned to business objectives? Are they integrated with upstream and downstream processes? Are common standards being followed? Are critical processes governed, measured, and continually improved? Viewed collectively, these indicators provide a picture of the organization’s overall Process Management capability and the amount of Systemic Process Debt it has accumulated.
Operational Process Debt is measured by examining the capability of each operational process. Is the process clearly defined? Is ownership established? Is it consistently executed? Is it measured? Is it producing the business outcomes it was designed to achieve? Answering these questions provides an indication of the amount of Operational Process Debt within the process itself. The challenge, of course, is performing those assessments consistently and objectively. That is the focus of the next section.
How Do You Assess the Underlying Processes?
Assessing the underlying operational processes should begin with a baseline assessment to establish the organization’s current Process Debt and Process Management capability. That baseline provides an objective view of where the organization is today and creates a foundation against which future improvements can be measured. Process Debt isn’t static—it changes as the organization evolves, implements new technologies, introduces new regulations, and continually modifies its operational processes.
A meaningful assessment should follow a structured and repeatable methodology. It should examine both the capability of individual operational processes and the health of the Process Management System that governs them. In my experience, the most effective assessments combine standardized interviews, workshops, questionnaires, and a review of supporting documentation while involving stakeholders from across the organization. Looking at a process from only one department rarely tells the whole story. Good assessments capture multiple perspectives because Process Debt often exists at the handoffs between teams rather than within the individual processes themselves.
Once the information has been gathered, it should be validated with the participants to ensure the findings accurately reflect how the organization actually operates rather than how people believe it operates. The findings can then be organized into common themes such as governance, ownership, documentation, communication, measurement, automation, or continual improvement. Those findings become the foundation for practical recommendations and a prioritized improvement roadmap.
The capability of both the Process Management System and individual operational processes can then be evaluated using an established capability scale such as ISO/IEC 33020 or the Capability Maturity Model. The objective, however, is not simply to assign a maturity level. It is to understand where Process Debt exists, how significant it is, and what impact it is having on operational resilience, cybersecurity, AI governance, regulatory compliance, and overall business performance.
A baseline assessment is only the beginning. Organizations should establish an ongoing capability to assess both their Process Management System and their operational processes on a regular basis. Effective process design should also identify the metrics and KPIs needed to monitor process performance over time. By reassessing processes periodically, organizations can measure the effectiveness of improvement initiatives, identify new Process Debt as it emerges, and ensure their operational processes continue to support the business outcomes they were designed to achieve.
What Are Some Practical Approaches for Identifying, Prioritizing, and Reducing Process Debt?
The first step in reducing Process Debt is recognizing that it exists. Like Technical Debt, Process Debt accumulates gradually over time and is often invisible until something goes wrong. Organizations should establish regular assessments of both their Process Management System and their operational processes, define meaningful metrics and KPIs for each, and monitor them over time. Just as importantly, there needs to be executive accountability for reviewing those results, prioritizing improvement initiatives, and ensuring Process Debt is reduced rather than simply carried forward into the next project.
In the IT Service Management world, we’ve long talked about the Service Management Office (SMO). The most effective SMOs I’ve worked with weren’t simply governance bodies. They were hybrid organizations consisting of process owners, process analysts, architects, and automation specialists. Process owners remained accountable for the processes within their business units, while the specialists provided the expertise, standards, and support needed across the enterprise. I’ve seen organizations achieve remarkable improvements with well-run SMOs. Unfortunately, I’ve also seen many dismantled when management changed or priorities shifted, only for Process Debt to begin accumulating once again.
I believe the concept of the Service Management Office should be extended beyond IT into an Enterprise Process Office with a clear mandate and executive sponsorship. Its responsibility shouldn’t be to own every process. Rather, it should own the Process Management System itself by establishing enterprise standards, maintaining the process architecture, overseeing process governance, measuring Process Debt, facilitating continual improvement, and ensuring operational processes remain aligned with business strategy. Individual departments would continue to own and operate their processes, but they would do so within a common enterprise framework.
Reducing Process Debt is not a one-time initiative. It is an ongoing management discipline. Organizations will continue to introduce new technologies, implement new regulations, redesign business models, and adopt innovations such as AI. Each of these changes has the potential to either reduce Process Debt or add to it. The organizations that will be most successful are those that treat Process Management as a permanent enterprise capability rather than a series of departmental responsibilities or project activities.
Ultimately, I believe this is the real opportunity. We have spent decades improving individual operational processes. The next step is to manage those processes as an integrated enterprise system. When organizations do that, they don’t just reduce Process Debt—they improve operational resilience, strengthen cybersecurity, support AI governance, increase organizational agility, and create a stronger foundation for whatever comes next.
Summary
Organizations have invested decades developing governance frameworks, strengthening cybersecurity, improving operational resilience, and, more recently, establishing AI governance. These frameworks provide valuable guidance on what organizations should achieve, but they do not execute themselves. Governance ultimately lives in the operational processes people perform every day. When those processes are not effectively designed, governed, integrated, measured, and continually improved, organizations accumulate Process Debt—a hidden operational liability that quietly erodes resilience, increases risk, drives up costs, and limits their ability to respond to change.
My experience has led me to believe that organizations should stop thinking about operational processes as isolated activities owned by individual departments and instead begin managing them as an integrated enterprise capability. By understanding, measuring, and systematically reducing both Systemic and Operational Process Debt, organizations can strengthen operational resilience, improve cybersecurity, better support AI governance, and create a stronger foundation for future transformation. In the end, the organizations that will be most successful won’t necessarily be those with the most frameworks, policies, or controls—they will be the ones with the operational discipline to consistently turn those frameworks into business outcomes.
