Infrastructure audits used to have a fairly stable object to inspect. A server existed in a known location. A network had defined boundaries. A configuration could be recorded, checked against policy and revisited later without expecting the entire environment to have changed in the meantime. Modern infrastructure doesn't behave like that.
Cloud resources appear and disappear. Applications move between environments. Security policies change through automated workflows. Software communicates through APIs. Third-party services sit inside critical business processes. Increasingly, AI systems can also recommend or make operational changes without somebody manually carrying out each step.
None of this means modern infrastructure is inherently less controllable. But it does change what an infrastructure audit has to prove. Knowing what's running now is only part of the problem. Organisations may also need to establish what was running three weeks ago, which configuration applied, what changed, who or what authorised the change and whether the controls surrounding it worked as intended.
That starts to look less like taking a snapshot and more like maintaining a history. The distinction is becoming important because responsibility hasn't disappeared as infrastructure has become more dynamic. CIOs, infrastructure teams, security leaders and risk functions are still accountable for the systems their organisations depend on.
They just have more moving parts to account for.
Modern Infrastructure Rarely Stays Still Long Enough To Audit
An audit works best when the thing being examined stays reasonably consistent while the evidence is collected. Modern hybrid infrastructure can change between one deployment and the next. A cloud resource might be created automatically to meet demand, then removed again when it's no longer needed.
A security rule may change because a new application has been deployed. Infrastructure-as-code can alter configurations across multiple environments at once. Teams can make changes independently through their own tools and workflows. The difficulty isn't simply that there are more changes.
It's that the environment an auditor examines today may not accurately represent the one that existed when a particular decision, incident or control failure happened. Research from the Cloud Security Alliance gives some idea of the scale of that gap. Its August 2026 State of Hybrid and Multi-Cloud Security Policy Management report surveyed 515 IT and security professionals.
Only nine per cent said security policy management was fully integrated into development and deployment workflows, while 48 per cent described policy changes as mostly or completely manual. A quarter of respondents had also experienced a failed compliance audit or audit finding during the previous 12 months.
Meanwhile, 92 per cent reported at least some difficulty getting one accurate view of security policies across their environments. Those findings point to a problem that goes beyond cloud complexity. The infrastructure keeps changing, but some of the processes used to document, review and prove its state still work at a much slower pace.
That creates a gap between infrastructure compliance as it exists on paper and the actual environment operating underneath it.
Visibility And Auditability Aren't The Same Thing
The obvious answer might seem to be better visibility. If an organisation can see its infrastructure clearly enough, surely it can audit it too. Not quite. Infrastructure visibility tells teams what their environment is doing. Monitoring platforms can show which workloads are running, where errors are happening, how systems are performing and whether something has changed.
Auditability asks a different question. Can the organisation prove what happened? That requires historical context. It means being able to connect an event with the infrastructure state at the time, the identity that initiated it, the control that applied and the change that followed. Logs are part of that evidence, but simply collecting more logs doesn't automatically create a useful audit trail.
Dynatrace's State of Log Management in 2026 report found that AI workloads had driven a 93 per cent increase in telemetry volume among the 450 global IT leaders surveyed. Half of the organisations were excluding an average of 86 per cent of their logs to manage costs. That doesn't mean organisations are throwing away evidence they legally need to retain.
The research doesn't establish that. It does show the practical pressure created when systems generate more operational data than teams can reasonably store and analyse without making choices about what to keep. More data doesn't necessarily mean a better record. For an audit, the useful question isn't whether a monitoring platform captured millions of events.
It's whether the organisation can connect the right evidence well enough to explain a particular one. That makes audit evidence a design problem as much as a storage problem.
Automation Creates An Accountability Gap
There was a time when infrastructure changes usually had a fairly obvious human trail. Someone logged in. Someone changed a configuration. Someone approved a request. Someone deployed the update.
Automation has made that chain less straightforward. Infrastructure now changes through deployment pipelines, orchestration platforms, scheduled workflows, scripts and policy engines. The person responsible for the environment may approve the rules behind an automated process without directly performing every action that follows.
That separation between responsibility and action isn't necessarily a weakness. Automation can make infrastructure more consistent and reduce the mistakes that come with repetitive manual work. But it does change what infrastructure accountability needs to capture. Broadcom's June 2026 Orchestration Accountability Gap research makes that problem unusually clear.
The survey of 501 enterprise professionals found that 97 per cent of organisations used multiple orchestration tools, while 60 per cent used four or more. Eighty per cent said those tools made clear end-to-end visibility harder rather than easier. The audit findings were even more striking.
Eighty-nine per cent had experienced audit issues connected to orchestration, yet only 54 per cent said they had proper audit trails for complex automation and orchestration processes. That gap gets to the centre of the problem. If a workflow changed a firewall rule, moved data, provisioned a resource or triggered another process, knowing that something changed isn't enough.
The organisation also needs to know which workflow acted, which configuration it was following and what authority allowed the action to happen. Otherwise, automation can leave organisations responsible for outcomes they struggle to reconstruct afterwards.
Infrastructure Ownership Now Extends Beyond The Enterprise
The evidence becomes harder to assemble again when part of the infrastructure belongs to somebody else. Most enterprise environments now contain services that the organisation depends on without directly operating. Public cloud providers are the obvious example, but the same problem applies to Software-as-a-Service platforms, managed services and other external technology providers.
An organisation can outsource the infrastructure. It can't automatically outsource responsibility for what happens to the business when that infrastructure fails. That distinction has become increasingly visible in regulation.
The EU's Digital Operational Resilience Act (DORA), which became applicable on 17 January 2025, requires financial organisations within its scope to maintain comprehensive registers of contractual arrangements with information and communication technology (ICT) third-party providers.
The registers are intended to support both the organisations' own third-party risk management and regulatory oversight. The principle behind that requirement reaches beyond financial services. If a critical process depends on an external provider, leaders need enough evidence to understand where that dependency sits and what responsibility remains inside the organisation.
That doesn't mean every enterprise needs a DORA-style register. It does suggest that third-party infrastructure can no longer be treated as somebody else's technical detail once business operations depend on it. Auditability increasingly has to cross organisational boundaries.
AI Adds Another Layer To Infrastructure Accountability
AI complicates the picture again because it isn't only becoming another workload that infrastructure teams need to support. It's also beginning to participate in infrastructure operations. Puppet's State of DevOps Report: Platform Engineering Edition 2026 found that 66 per cent of surveyed organisations were applying AI within infrastructure workflows.
Fully autonomous operations were much less common at 31 per cent, but the direction is already clear. Infrastructure isn't suddenly running itself. It is, however, becoming more likely that an AI system will recommend an operational action, help generate a configuration, analyse an incident or play some role in a workflow that eventually changes the environment.
That introduces another actor into the evidence chain. IBM's June 2026 global study of 2,000 C-level technology executives found that two-thirds were being held accountable for AI systems they didn't fully control. Seventy per cent also said teams across their organisations were deploying technology faster than IT could track, while 77 per cent said AI adoption was already outpacing their governance capabilities.
We've spent plenty of time asking whether organisations understand the AI systems they're adopting. The AI accountability question inside infrastructure is slightly different. If an AI-supported process contributes to an operational change, can the organisation establish what role it played?
- Who authorised the system to act?
- What information influenced the recommendation?
- Did a human approve the change?
- Which controls applied?
- Where does responsibility sit if the outcome creates a problem?
Those questions become harder to answer if auditability is added after the automation is already running.
Point-In-Time Audits Are Giving Way To Continuous Evidence
This is where the traditional model starts to strain. A periodic audit still has a purpose. Organisations will continue to carry out scheduled reviews, regulatory assessments and internal checks. But the evidence supporting those audits increasingly needs to exist before somebody asks for it.
If infrastructure changes continuously, continuous compliance becomes less about auditing every second and more about keeping the record current as changes happen. We're already seeing infrastructure platforms move in that direction. VMware Cloud Foundation 9.1, announced by Broadcom in May 2026, introduced a centralised audit trail across platform components.
Audit records are standardised and brought together so operators can follow chains of activity across the stack rather than manually reconstructing them from separate systems. Broadcom has also expanded VMware Advanced Cyber Compliance around continuous monitoring, configuration drift detection and remediation.
The aim is to compare infrastructure against a desired security state while the environment is operating, rather than relying entirely on periodic checks. Puppet's research points in a similar direction. Seventy-nine per cent of platform-mature organisations in its 2026 study reported mature governance, compared with 14 per cent of less mature organisations.
Among organisations with internal developer platforms, 52 per cent reported fully automated governance capabilities. These are vendor findings, so they shouldn't be treated as proof that every organisation needs the same platform model. What they do show is a broader shift in how infrastructure governance is being approached. Evidence is moving closer to the systems creating it.
Auditability Needs To Be Designed Into Infrastructure
If audit evidence has to be reconstructed manually every time somebody asks a difficult question, the organisation doesn't really have an audit trail. It has an investigation waiting to happen. Infrastructure auditability works better when evidence is created alongside the activity it describes.
The goal isn't to capture every possible piece of operational data forever. That would be expensive, difficult to manage and unlikely to help anyone when they actually need an answer. Instead, organisations need enough connected evidence to establish four things reliably: what existed, what changed, what authorised the change and what supports that account.
Those requirements take different forms across the infrastructure estate.
Preserve infrastructure state
A current inventory tells you what exists today. An audit may need to know what existed at a specific moment in the past. That means configuration management needs some form of history. Resources can disappear. Configurations can be overwritten. Applications can move. Policies can change.
A current configuration management database (CMDB) or cloud inventory may therefore be accurate now while telling you very little about the state that existed when an earlier event occurred. Preserving infrastructure state doesn't mean retaining a perfect copy of every environment indefinitely.
It means deciding which configuration and asset records need enough history to support investigation, compliance and operational accountability later. Without that, teams can end up comparing an old event with a new environment and wondering why the pieces don't quite fit.
Preserve change provenance
Knowing that a configuration changed is useful. Knowing why it changed is better. Change provenance is the history behind an infrastructure change. It connects the action to the identity, process or automated system responsible for it and, where relevant, the approval or policy that allowed it. That identity may belong to a person.
Increasingly, it may belong to a service account, machine identity, deployment pipeline or orchestration platform. The distinction becomes more important as automation grows. If a machine carried out the action, the audit trail still needs to lead back to the authority that allowed the machine to act. Otherwise, organisations know what happened but lose the chain of responsibility behind it.
Preserve control evidence
Policies describe what should happen. Auditors often need evidence of what actually happened. There is a significant difference between having an infrastructure control and being able to demonstrate that the control operated when it was supposed to. This is where policy as code and compliance automation can become useful.
When controls are expressed and enforced through the same systems that configure infrastructure, the organisation has more opportunity to capture evidence while those controls operate. It also makes configuration drift easier to detect. If the approved state and the actual state stop matching, teams don't have to wait until the next formal review to discover it.
The value isn't simply faster compliance reporting. It's a more reliable connection between the organisation's governance rules and the infrastructure those rules are supposed to govern.
Preserve dependency evidence
Infrastructure rarely fails in neat isolation. A business service may rely on an internal application, a cloud platform, an identity provider, a data service and several external APIs before a user sees the final result. For audit purposes, the organisation doesn't necessarily need a permanent diagram of every possible connection.
It does need enough dependency evidence to establish which systems and providers were involved when something important happened. That could mean knowing which external provider supported a critical service, which infrastructure component depended on another, or which business process was exposed when a particular resource failed.
The point isn't to understand every dependency at all times. It's to avoid discovering after an incident that the evidence needed to reconstruct the important ones no longer exists.
The Real Test Comes When Someone Asks You To Prove It
Most infrastructure looks manageable when everything is working. Auditability becomes visible when somebody asks a question that can't be answered from the dashboard currently open on the operations team's screen. A regulator wants evidence that a control operated correctly. An incident team needs to reconstruct a change.
A customer asks how a service was affected. An executive wants to know who authorised an automated action. Suddenly, the difference between visibility and evidence becomes very practical. A useful test of audit readiness is whether the organisation can answer a small set of questions without launching a week-long archaeology project:
- Can we establish what the relevant infrastructure looked like at the time?
- Can we identify what changed and when?
- Can we trace the change back to the person, machine or workflow that made it?
- Can we show what authority or policy allowed the action?
- Can we demonstrate whether the expected control actually applied?
- Can we identify the internal and external dependencies involved?
- Can we produce evidence that another team, auditor or regulator could reasonably verify?
A "no" doesn't automatically mean the organisation has poor infrastructure governance. It tells leaders where accountability depends on memory, manual reconstruction or disconnected records. And those gaps become harder to manage as infrastructure becomes faster, more distributed and more autonomous.
Final Thoughts: Accountability Depends On Evidence
Complex infrastructure isn't new. Enterprises have been operating systems that no single person understands in complete detail for years. That alone doesn't make those systems unmanageable. The more interesting threshold appears when an organisation can no longer produce a reliable account of what its infrastructure did.
At that point, infrastructure governance starts to lose something important. Policies may still exist. Monitoring may still work. Teams may still understand their individual platforms. But when somebody needs to reconstruct an event across those systems, responsibility becomes much harder to prove.
That's why auditability is beginning to look less like a compliance task and more like an infrastructure property. The strongest environments won't necessarily be the easiest to understand. Modern infrastructure is unlikely to become simpler just because organisations would prefer it that way.
What they can do is preserve enough evidence as infrastructure changes to keep accountability intact. That means knowing what existed. Knowing what changed. Knowing what authorised the change. And being able to support those answers without rebuilding the past from whatever records happen to remain.
As automation, cloud platforms and AI take a larger role in enterprise operations, that capability will only become more important. EM360Tech will continue following how infrastructure leaders are adapting governance, resilience and operational control as the systems underneath the business become increasingly dynamic.
Comments ( 0 )