Compute used to be all about speed and cost. Now it’s about proof of compliance. Here’s what that means for regulated industries.
I've focused this post on compute where codes and applications are being run. But the same principles apply to storage, networking, databases, and AI workloads. The tools change. The logic stays the same.
The Situation: Compute Is Now An Externally Audited Footprint
For a long time, compute was simple. You either bought a BareMetal server, or spun up a virtual machine.
If it was fast enough for the application you wanted to run and the cost didn’t exceed your budget, you could pat yourself on the back and move on to the next thing.
But here is what I’ve been noticing: These days, speed and cost are no longer good enough.
Because if you work in a regulated industry like banking, you’re not just being asked: “Can your compute handle peak transaction volumes during the Christmas shopping period?” You’re being asked, “What happens (not if) when your compute fails? Can you recover within your RTO? Can you prove it?”
If you work in healthcare, you’re not just being asked, “Who has access to your compute resources?” You’re being asked, “Who accessed it? When did that happen, and for what purpose? Show me the logs.”
And if your company are ramping up AI deployments, you’re not just being asked, “Does your compute have enough capacity for AI workloads?” You’re being asked, “Do you have the compute you need for AI? Can you govern it?”
Your job description may not have changed much. But the expectations around you have gone up a notch.
Compute used to be an internal engineering concern. Now, it’s becoming an external audit matter.
Regulators aren’t just asking what you’re doing. They are asking you to show them the proof.
And that’s a very different conversation that may catch you off guard if you’re not prepared for it.
If you’re an IT manager who’s been dreading the next audit, this post is for you.
The Problem: “Translation Gap” between Compliance and Implementation
There is a problem that I keep running into or witnessing someone else cursing about.
Regulators and auditors are very good at giving you a laundry list of what keeps them happy.
You may already know the drill but here are a few examples of what they ask for.
Maintain its critical operations within tolerance levels through severe disruptions — APRA CPS 230 Operational Risk Management
Have robust mechanisms in place to detect and respond to information security incidents in a timely manner — APRA CPS 234 Information Security
Implement hardware, software, and/or procedural mechanisms to record and examine activity in information systems that contain or use electronic protected health information — HIPAA Security Rule
At first glance, all of these requirements are clear. They are essential. They make sense.
But among hundreds of settings and configurations within your hybrid cloud or multi-cloud environment, what do you do? How do you prove to regulatory authorities which ones show compliance?
It’s like being told, “Hey, you must bake a cake for a lovely lady. Make sure she loves it.”
And you sit there, scratching your head.
You don’t know if it’s for her birthday. You haven’t gotten a single clue whether she is gluten-free, allergic to nuts, or hates strawberries with a passion.
You’ve got the flour, sugar, egg, and your fan-forced oven is ready to bake. But you don’t know what she actually wants.
That’s what I call the “translation gap” between compliance and implementation.
It’s a real headache. And like it or not, it’s a puzzle you have to figure out.
The Solution: Compliance Evidence Pipeline
Across all readings and research, I found myself coming back to the idea of a Compliance Evidence Pipeline.
The core idea is simple: you build a system that automatically collects telemetry data, logs, configuration changes, timestamps and exception approvals.
Whenever a regulator asks for the proof, you already have the evidence ready to supply. No panic, no last-minute scrambling.
But here’s the honest truth.
I don’t have all the answers. I’m not a compliance expert. I’m not a security architect.
I’m just someone who’s spent years deploying infrastructure in regulated environments and is trying to make sense of how to bridge this gap.
Here is what I’ve learned.
What Does a Compliance Evidence Pipeline Look Like in Practice?
No matter how your cloud environment is structured, a compliance evidence pipeline has the same key components.
Recording what happened
Logging – Records every action
Access Tracking – Records who logged in, where, and when
Configuration Monitoring – Tracks what changed, when, and by whom
Protecting what matters
Encryption – Protects data at rest and in transit
Network – Controls traffic and protects perimeters
Vulnerability Scanning – Identifies security gaps
Collecting evidence across environments
Multi-cloud & Automated Evidence Collection – Collects evidence across environments
If you are interested in knowing more about the available tools for each component, here is a tool reference card for you.
Seven components. One pipeline. Audit-ready evidence on demand.
Key Takeaways for Implementing a Compliance Evidence Pipeline
Here are 3 key lessons I’ve picked up when implementing a compliance evidence pipeline.
Lesson 1: Logs aren’t proof
Logs record what was executed and when. Proof indicates what did or did not happened when it matters.
They’re not the same thing.
You may think of it like this. Your company can install security cameras everywhere to record everything in the office. That’s logging.
But if you want to prove that only authorised people access the server room, you don’t just need cameras.
You need a camera installed at the server room door, pointed at the badge reader, capturing who swiped in and when.
If the cameras is in the wrong place, you might have hours of footage, but still have nothing to show when your management asks, “Who accessed the server room at 3 AM last Tuesday?”
Your compute logs are no different. They may record everything under the sun and show its systems were running.
But to prove compliance, you need to know which logs are required to answer which questions from regulators.
Otherwise, you’re wasting time and money capturing data without being able to show anything with it.
The practical takeaway: proof has to be designed, not blindly collected.
Instead of asking “What logs should we collect?”, a better question is “What would regulators need to see to be satisfied?”
Then design & configure the logging tool to capture that as the system runs.
Lesson 2: Your cloud provider’s compliance isn’t your compliance
Ever notice a security sign at building entrances that says, “This building is under 24-hour surveillance”?
It means the building owner has installed CCTVs covering common areas such as the lobby, the hallways and the parking lot to deter potential intruders from breaking in or trespassing.
But your server room? Your highly protected data? Your customer database?
Not covered, unfortunately.
Your building owner can provide the best security system in the world with cameras everywhere. But if you do not lock the server room door or misconfigure access, then none of that matters.
When the server room is compromised, the auditor won’t ask the building owner about their CCTVs.
They’re going to ask you: “Why was the server room door not locked?”
The building’s CCTV is like those SOC 2 attestations or ISO 27001 certifications that your cloud providers publish on their websites as full compliance coverage.
But those are full coverage for them, not for you.
That’s the shared responsibility model. The cloud provider secures the building. You secure the rooms and everyone working inside it.
And the statistics back this up. 57% of organizations reported cloud-related compliance failures in 2025, with half of those failures traced directly to customer-side configuration errors.
When regulators come knocking, they couldn’t care less about what was stated by AWS, Azure or GCP. They are not going to ask the cloud provider why your virtual machine was misconfigured.
They’re going to ask you.
If your answer is the cloud provider’s SOC 2 attestations, they may pass the audit. You might not.
Your cloud provider’s compliance isn’t your compliance.
Lesson 3: Observability is the new compliance proof
So if logs aren’t proof, and outsourcing your accountability isn’t an option, what’s the answer?
The financial industry has given us a big hint. 61% of companies now use observability platforms for real-time compliance monitoring and audit trail generation.
The 2026 State of Observability in Financial Services research report reveals that observability no longer just for troubleshooting. It’s now essential for governance, risk management and security.
Telemetry data is now the shared source of truth across the enterprise and being actively used by internal auditors, cybersecurity teams and compliance officers.
But here is the harsh reality.
Regulatory requirements are becoming more complex. Regulators increasingly expect continuous proof across hybrid and multi-cloud environments. More teams rely on telemetry data for their daily work. Expectations from observability are higher than ever.
Yet 99% of organisations are seeking to cut the observability spend.
Do more with less. That’s the mandate.
So how do you actually do it?
Below are a few ideas to get started.
Remove redundant tools:
Most organisations have overlapping monitoring systems, duplicate logging and fragmented telemetry.
Consolidate them and eliminate what doesn’t add value. Every tool you remove is a cost you don’t have to justify.
Prioritise open frameworks: Standardise data collection through OpenTelemetry (OTel) as the industry standard framework to avoid vendor lock-in and maintain flexibility
Consolidate into a unified data store: Bring telemetry logs, metrics and traces into a unified long-term data platform that can be queried, analysed and presented to regulators on demand
Establish secure data & insight capabilities across teams: Create a single source of truth of telemetry data that is secure by design, with role-based access, immutable logs, and audit trails that satisfy both internal governance and external regulators.
The Action
Here's the thing about building a Compliance Evidence Pipeline.
It doesn't need to be perfect. It just needs to exist.
You don't need to map every regulation, configure every log, and audit every resource on day one. That's how you get overwhelmed and give up.
Start with one thing.
Pick a single compute resource—a VM, a serverless function, a container cluster. Audit it.
Ask yourself:
Who can access it?
What logs are we capturing?
If a regulator asked for evidence on this resource, what would I show them?
If you can't answer that last question, you know exactly where to start.
Because here's the truth: a small, imperfect pipeline that exists is infinitely more valuable than a perfect one that doesn't.
You don't need to boil the ocean. You just need to start.
Start with one resource. One log. One question.
The rest will follow.
What’s Coming Next
This post focused on compute—the oven of a bakery, the kitchen of a restaurant, the place where your applications run inside your cloud environment.
But compute doesn't exist in isolation.
Your applications need somewhere to store their data. They need to talk to each other. They need to be monitored, secured, and governed. And increasingly, they need to be augmented with AI.
So here's what I'm planning to cover next:
Storage in Regulated Industries
What happens when data sovereignty, immutability, and retention requirements meet the reality of hybrid and multi-cloud storage? I'll walk through what I'm learning about compliant storage—object, block, and file—and how to design for auditability.
Network in Regulated Industries
Segmentation. Monitoring. Encryption. The network is the invisible boundary between your regulated workloads and the rest of the world. I'll share what I'm learning about keeping it secure—and proving it.
AI Governance in Regulated Industries
This is where compute, storage, and network converge. When your models are making decisions that impact customers, you need to be able to explain why. I'll explore the governance frameworks emerging for AI in regulated environments.
If any of these topics keep you up at night—or if you're just trying to figure out where to start—stick around and I will see you in the next post.
References
Elastic – State of Observability in Financial Services 2026
https://www.elastic.co/blog/state-of-observability-2026-financial-services
Compliance Seminars – What Is Cloud Audit Risk for Auditors and Executives
https://www.compliance-seminars.com/post/what-is-cloud-audit-risk-for-auditors-and-executives
TechInnocens – AI Audit Trail vs Logging: Why Logs Aren't Evidence
https://techinnocens.com/insights/ai-audit-trail-vs-logging
NHI Mgmt Group – What Is a Compliance Evidence Pipeline?
https://nhimg.org/glossary/compliance-evidence-pipeline/
APRA – Prudential Standard CPS 230 Operational Risk Management
https://www.apra.gov.au/standards/cps-230
U.S. Department of Health & Human Services – Summary of the HIPAA Security Rule
https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
Anecdotes – 18 Examples of Automated Evidence Collection for Compliance
https://www.anecdotes.ai/learn/18-examples-of-automated-evidence-collection-for-compliance
