Technical debt is normally discussed as ageing code, legacy infrastructure, delayed upgrades or architectural complexity. But beneath these visible issues may sit another form of debt: the growing distance between what management believes exists and what the technology environment has actually become.
McKinsey's research on technical debt and data readiness points to a familiar enterprise problem.
Technology environments rarely remain static.
Applications are upgraded. Virtual machines are repurposed. Cloud workloads move. New integrations are added. Vendors receive temporary access. SaaS platforms expand into additional departments. Data volumes increase. Backup policies continue. Ownership changes. Teams reorganise.
Each change may be perfectly legitimate.
The difficulty begins when the organisation's understanding of the environment does not change at the same speed.
McKinsey has argued that a serious effort to understand technical debt starts with an accurate and detailed view of current assets, data and their links to business value.
Its more recent work on data readiness similarly emphasises governed, traceable and reusable foundations as organisations scale increasingly complex data environments.
What if the technology is technically healthy, but the management understanding surrounding it is no longer current?
An infrastructure component can be available.
A SaaS platform can be functioning.
Backups can be successful.
A vendor connection can be operational.
None of these facts independently establish that ownership, dependency, access, data treatment and supporting evidence are still understood correctly.
Technical Debt Already Tells Us Something Important
Technical debt is more than an ageing-technology issue. It is accumulated complexity created through decisions that often made sense when they were taken, but which create additional cost and constraint as the environment evolves.
McKinsey's work is particularly relevant because its approach moves beyond broad descriptions such as "legacy technology." It discusses applications, infrastructure, databases, deployment types and related metadata at a much more granular level.
That distinction is important from an Infrastructure Governance point of view.
An organisation cannot meaningfully understand accumulated technology complexity only through a policy document, a high-level architecture presentation or an asset register that has not been reconnected with the current environment.
The present state has to be understood.
McKinsey's June 2026 work on data readiness reaches a similar conclusion from the data side: data needs to remain reliable, clearly understood, traceable and reusable across the environments consuming it.
This Is Where the Foundation Layer Becomes Important
Our Foundation Layer research does not begin with an assumption that enterprise technology teams are failing to operate their environments.
In many cases, the opposite may be true.
Systems continue running because experienced teams constantly adapt them. Engineers create workarounds. Infrastructure teams extend capacity. Security teams add controls. Business functions introduce new applications. Vendors resolve technical issues. Operations teams keep critical services available.
That ability to adapt is one of the strengths of enterprise IT.
But it creates a deeper governance question:
The Distance We Are Trying to Understand
The problem can be represented through a simple management chain:
The greater the distance between these stages, the greater the possibility that management may be relying on an incomplete representation.
We refer to this emerging condition as Governance Debt.
Governance debt does not necessarily mean that controls are absent.
It can mean that the relationship between a control and the current operating environment has become less demonstrable.
Four Areas Where the Gap Can Quietly Grow
The person who originally owned a system may have moved. The application may now support several functions. Infrastructure ownership, business ownership, data ownership and risk ownership may no longer sit with the same people.
A service that once operated independently may now depend on APIs, SaaS platforms, shared databases, identity services, cloud components, telecom links or providers that were not part of the original design.
Administrators, OEM engineers, MSP personnel, application vendors, consultants and service accounts may accumulate access as environments change.
Management may possess policies, diagrams, registers and reports. The deeper question is whether that evidence is current enough to demonstrate the actual present state.
The Gap Is Often Created Through Ordinary Operational Change
It does not require a major transformation programme.
Small changes accumulating over time may be enough.
A VM may have been created three years ago for one application. The original application remains, but another workload is later added because spare capacity exists. A reporting process then begins reading from the second workload. The VM is still healthy. Monitoring is green. But the original asset description may no longer represent its current business importance or dependency chain.
A SaaS service may begin with one department. Other teams gradually adopt it. New integrations are introduced. Customer information is added. A third party supports configuration. Over time, the service becomes operationally important to several functions even though its original classification, ownership and exit assumptions remain unchanged.
An OEM engineer may receive elevated access during implementation. Six months later the implementation is complete, but the account remains because occasional support is still required. Another engineer is added. A shared support method develops. Individually these changes may appear minor. Together they may materially alter the privileged-access position.
A backup schedule may continue successfully for years. But the underlying dataset may have changed materially. New personal data may now be present. Retention requirements may have changed. Copies may exist in additional environments. The backup control may still work exactly as designed while the assumption behind the design has become outdated.
This Is Not Necessarily Technology Failure
This distinction is central to our hypothesis.
A system can perform within its availability target and still have an unresolved ownership question.
A firewall rule can be technically correct while the business dependency behind that rule is no longer understood.
A vendor account can be secure from an authentication perspective while the continuing business justification for that access is unclear.
A backup can complete successfully while the organisation cannot confidently explain everything now contained within it.
An asset register can exist while material relationships among those assets remain undocumented.
The technology may be healthy.
The governance representation may still be ageing.
Why This Matters to Management
Management cannot personally inspect every server, application, API, identity, vendor connection or data repository.
Nor should it.
Management operates through representations of reality.
Dashboards, asset inventories, architecture diagrams, security reports, risk registers, audit observations, business continuity plans, vendor registers, compliance assessments and management certifications all help senior leaders understand an environment too complex to observe directly.
The quality of governance therefore depends partly on the continuing connection between those representations and the environment they describe.
When that connection weakens, a subtle risk appears.
Decision-makers may receive technically correct information about an incomplete picture.
The purpose of deeper infrastructure governance is not to generate more information. It is to identify which management assumptions deserve evidence and which evidence deserves attention.
Technical Debt and Governance Debt Are Related, but Not Identical
| Dimension | Technical Debt | Foundation Layer Governance Debt |
|---|---|---|
| Primary concern | Cost and complexity accumulated in the technology estate | Distance between actual operating reality and management's current understanding |
| Typical signal | Legacy systems, delayed upgrades, complex code, ageing infrastructure | Unclear ownership, undocumented dependencies, stale access, incomplete evidence |
| Main question | What needs to be modernised or remediated? | Does our current representation still describe what actually exists? |
| Management impact | Cost, speed, reliability and modernisation capacity | Confidence in governance, risk, security, resilience and compliance positions |
A Simple Way to Think About Governance Distance
This is not intended as a formal risk formula. It is a research illustration.
Assume one important application has five material governance relationships:
If only three of those five relationships have been recently validated:
This does not mean the application is "60% governed."
It means management has a reason to ask about the remaining 40% of the relationship picture before relying on the representation as complete.
The calculation illustrates why evidence completeness and technology health are different concepts.
A Generic Multi-Site Enterprise Example
Consider a large enterprise operating multiple regional sites.
A central business application was implemented several years ago. At implementation, the organisation documented the application owner, database, infrastructure, backup requirement, network connectivity, vendor support and disaster-recovery arrangement.
Over the following years:
Nothing necessarily failed.
Every individual change may have been properly implemented.
That is the Foundation Layer question.
Why Periodic Review Alone May Not Answer the Problem
Most organisations already have review mechanisms.
Internal audits are performed. Access reviews take place. Asset inventories are updated. Business continuity exercises are conducted. Vendor assessments occur. Architecture teams review technology. Security functions monitor events.
These activities are necessary.
The research question is whether their review cycles are aligned with the rate of change in the environment.
An annual review may accurately validate an environment on the date of review.
But if ownership changes two months later, a vendor is onboarded in month four and a new integration is introduced in month seven, the continuing validity of that earlier assurance becomes a different question.
The Deeper Issue May Be Continuity
During our practitioner discussions, one idea continues to become more important.
Management assurance cannot depend only on the existence of evidence.
It also depends on whether a demonstrable chain of continuity remains intact:
If one of those links materially changes, the previous evidence may still be genuine but may no longer be sufficient to support the same conclusion.
What Should a Board or Senior Management Ask?
Senior management does not need another detailed technical checklist.
A smaller set of management questions may be more useful.
Which critical technology assets have materially changed since their ownership and dependency position was last validated?
Where are we depending on third parties or privileged access arrangements that are not visible in normal management reporting?
Which systems now support more business processes, data or users than they did when originally approved?
Which management representations depend mainly on declarations rather than independently validated operating evidence?
What has changed since our last assurance exercise that could alter the conclusion we reached at that time?
Can we demonstrate who currently owns each material technology risk, dependency and exception?
Our Current Research Position
Our working hypothesis is that some organisations may be carrying more governance debt than their traditional risk reporting makes visible.
Not because controls do not exist.
Not because technology teams are not working.
And not necessarily because systems are insecure or unavailable.
The debt develops when operating reality continues to evolve but the relationships surrounding that technology are not repeatedly reconnected.
Ownership becomes historical.
Dependency maps become partial.
Access accumulates.
Data changes.
Third-party involvement expands.
Evidence remains available, but the environment it originally proved has moved.
Open Research Questions
At what point does normal technology change become a governance visibility problem?
How frequently should critical ownership and dependency relationships be revalidated in a continuously changing environment?
Can a traditional CMDB or asset register establish operating reality without relationship and evidence validation?
How should management determine when previous assurance evidence is no longer sufficient to support a current conclusion?
Should governance debt be measured separately from technical debt?
Primary Research References
1. McKinsey & Company
“Breaking technical debt's vicious cycle to modernize your business,” April 25, 2023.
Read the source →
2. McKinsey & Company
“Demystifying digital dark matter: A new standard to tame technical debt,” June 23, 2022.
Read the source →
3. McKinsey & Company
“AI data readiness: The key to scaling impact,” June 23, 2026.
Read the source →
Research Note
This article forms part of the InfraVeritas360 Research Stream examining the relationship between declared governance positions and actual operating reality across enterprise technology and infrastructure.
Our research sequence is: Declared → Discovered → Connected → Owned → Validated → Evidenced.
The examples in this article are generic and are intended to illustrate research hypotheses. They do not refer to any specific organisation, technology incident or customer environment.
The illustrative calculation is not a risk score, compliance score or industry benchmark. It is used only to demonstrate the difference between technology health and completeness of the governance relationship picture.
Research grows through questions, discussions and different perspectives.
We acknowledge McKinsey & Company's publicly available work on technical debt and data readiness, which helped trigger this line of thinking. The Foundation Layer interpretation and research conclusions presented here are our own.
Contribute to the Research
We are continuing to validate this hypothesis with CIOs, CISOs, infrastructure leaders, auditors, governance professionals and technology practitioners.
We would particularly value practitioner views on one question:
Practitioner responses may challenge, refine or reject parts of our current hypothesis. That challenge is an important part of the research process.
Suggested Citation
Research Integrity
InfraVeritas360 distinguishes external published research, practitioner observations, working hypotheses and our own research interpretation. Reference to an external organisation or publication does not imply that the organisation has reviewed, endorsed or validated InfraVeritas360, the Foundation Layer hypothesis or the conclusions presented in this article.