Proving It: Auditability and Evidence for Multi-Cloud Workload Decisions

The usual answer to "show me" is a folder of artefacts assembled after the request lands: screenshots of a provider console, an exported spreadsheet of resource locations, a billing report, a few configuration exports. These feel like proof. Under audit, they tend not to hold.

Three weaknesses recur. First, they are point-in-time. A screenshot shows a setting on the day it was taken, not that the setting held continuously across the review period. Second, they are provider-specific. Each cloud exposes location, configuration, and access differently, so evidence pulled from three consoles is three incompatible formats that no one stitches into a single defensible picture. Third, they are reconstructed. The artefacts are produced in response to the question, which means they describe the present and infer the past, rather than recording it as it happened.

This is not a new observation about cloud platforms. More than a decade ago, IBM Research noted plainly that default IaaS clouds "do not provide any evidence of compliance with customer-specified integrity policies," and that the prevailing mechanism was simply to trust the provider's statements that workloads stayed where they were meant to [S10]. The same work made the deeper point: proving compliance requires automated audit trails of integrity verification, monitoring, and geo-location, produced as workloads run, not assembled afterward to satisfy a regulator or a customer [S10].

The following reading is Atomity's analysis rather than a claim from any single source. Put the three weaknesses together with the multi-cloud reality, where each provider speaks its own dialect [S32] and a sovereignty or isolation claim is itself hard to verify independently [S62], and hand-assembled artefacts cannot amount to durable, cross-provider proof of a decision. They are a snapshot, not a trail.

If the artefacts fail, what would succeed? The research literature points to four properties that durable evidence needs. Useful to define the terms first, because they are often used loosely.

Jurisdiction enforcement, not just a location label. Geo-fencing is the process of restricting the residence and movement of data in cleartext, and the computation on it, to specified geographic regions, and enforcing that during initial placement and any later migration [S10]. The word *movement* matters. A workload can be created in-region and later migrated out of it by routine platform operations such as load balancing or maintenance. Evidence that a workload was in-region at launch says nothing about whether it stayed there. Durable evidence has to track the boundary continuously, including across migrations.

Attestation of integrity. Attestation is a verifiable statement, ideally hardware-rooted, that a system's software stack is known-good and unmodified, and that an independent party can check. Hardware-rooted attestation lets a customer independently verify the integrity and the geo-location of the servers running a workload, which reduces the trust that must be placed in the provider [S10]. The principle generalises to sensitive workloads: confidential computing processes data inside hardware enclaves that isolate it from the host operating system, the hypervisor, and provider personnel, so that trust is established and checked rather than assumed [S03]. The common thread is independence. Evidence you have to take on faith is not evidence.

Immutability, so the record cannot quietly change. Evidence is only as good as its resistance to tampering. The measurement model behind hardware attestation is instructive: it is extend-only, so any change to measured code or configuration produces a different value and the alteration is detectable [S10]. The general requirement is tamper-evidence. An audit record that can be edited after the fact, with no trace, proves nothing.

Lineage and accountability. Finally, evidence has to connect to a chain of where things came from and who was responsible. Work on multi-cloud data governance points toward centralized policy with decentralized enforcement, automated data lineage, and accountability across providers as the way to keep control coherent when no single provider spans the whole estate [S32]. Lineage answers "how did this come to be," which is exactly what an auditor reconstructs by hand when the trail is missing.

There is a trap between a claim and proof, and it deserves its own name. A vendor-affiliated analysis describes it as a verification gap: a sovereignty or isolation claim is hard for an enterprise to verify independently [S62]. The author is affiliated with a security vendor, so treat this as an attributed position rather than neutral fact, but the mechanism it describes is concrete. Standard availability zones can ensure data residency, the data sits in the right region, while still leaving the control plane accessible to administrators in another jurisdiction [S62]. Residency is satisfied; operational control is not.

This is why sovereignty should never be equated with residency alone. Residency is the foundational layer, where the bytes rest. Operational control concerns who can reach and administer the workload, which is a separate question and often the one that decides whether a claim survives scrutiny. An audit that checks only the storage region can pass a workload that an auditor with the full picture would fail. Closing the verification gap means producing evidence that an independent party can check, not a claim they are asked to accept.

For regulated organisations, this stopped being optional. Analysis of public-cloud transformation in banking, financial services, and insurance describes the pressures directly: data-localization rules, the need to provide audit access, and regulatory oversight of cloud arrangements [S61]. That is a consulting source and is attributed as such, but it is consistent with the direction of European law.

On the law itself, one instrument is worth stating precisely and keeping separate from interpretation. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025. It requires ICT risk management across the EU financial sector, including the oversight of third-party ICT providers and attention to concentration risk [W1]. That is the legal text. How a given organisation must respond to it is a matter for qualified interpretation and is not legal advice. The relevant point here is narrow: a regulated entity is increasingly expected to *demonstrate* how its cloud arrangements are governed, which is an evidence obligation over decisions, not only a matter of having a policy on file.

Generic assurance frameworks point the same way. Where an organisation relies on the likes of ISAE 3402, SOC 2, or ISO 27001, the underlying expectation is evidence that controls operated over a period, not that they existed on one day . No specific clause is asserted here.

Pulling the requirements together gives a system model rather than a tool. It has four moving parts.

A policy states what a decision must satisfy: which workloads may run where, on what stack, under which access rules. Enforcement applies that policy at the moments that matter, at placement and at migration, so the boundary is held continuously rather than checked once [S10]. Attestation produces independently verifiable statements that the stack and location are what they should be [S10][S03]. And an evidence record captures all of it, as it happens, in a form that is tamper-evident [S10] and carries lineage and accountability across providers [S32].

The shift this represents is from periodic to continuous, and from artefact to trail. The following is Atomity's analysis: the layer most organisations are missing is not evidence over the *data*, which storage and security tools address, nor evidence over the *spend*, which cost tools address, but evidence over the *decision*, why a workload runs where it does, against which policy, and whether that held over time. That decision-level trail is the one auditors increasingly ask for and the one hand-assembled artefacts cannot supply.

These requirements describe a function that sits above any single cloud, security, or audit tool: a control layer whose job is to make, enforce, monitor, and prove workload decisions across environments, and to keep the evidence coherent when no one provider spans the whole estate. The concept is general, and an organisation could approach it in more than one way.

This is the function Atomity is built to serve. Atomity helps regulated enterprises and public-sector organisations make, enforce, monitor, and prove cloud workload decisions across sovereign, hybrid, and multi-cloud environments. In the auditability context specifically, that means applying defined policy to a workload decision, supporting policy enforcement and attestation, generating and recording evidence of how a decision was reached and whether it held, and supporting continuous auditability so the decision can be reviewed later, with visibility across multiple cloud environments rather than one console at a time. It evaluates the decision against sovereignty, compliance, operational, and cost criteria together, since an audit rarely cares about only one of them. The aim is narrow and deliberate: to give cloud decisions the durable, reviewable evidence layer that ad-hoc artefacts cannot.

Precision matters here, because it is easy to overstate. A control layer of this kind does not replace an auditor, who reaches an independent conclusion. It does not replace a SIEM, which collects and correlates security telemetry, nor a CSPM, which assesses configuration posture; those tools do their own jobs and the evidence layer is complementary to them. It does not replace a legal team, and nothing here is legal advice. And it does not, on its own, guarantee compliance. What it adds is specific: a durable, attestable record of the decisions, so that a regulated organisation can show its work rather than assert it.

Two honest caveats. The strongest source here, on geo-fencing and attestation, dates from 2014 and is used for its durable principles, not as a claim about what any current provider does or does not offer today [S10]; some gaps it named have since been partly addressed by managed sovereign-cloud offerings. And the verification-gap and regulated-sector framing comes from a vendor-affiliated source and a consulting source respectively [S62][S61], attributed as such; the legal obligation is stated from the primary text [W1], while its application to any specific organisation is left to qualified interpretation.

The question an auditor asks is not "do you have a policy." It is "can you prove the workload obeyed it, everywhere, over time." Screenshots, spreadsheets, and provider dashboards answer the first question and quietly fail the second. Durable evidence requires jurisdiction enforcement, attestation, immutability, and lineage, produced continuously and kept coherent across providers.

List the cloud decisions you would need to prove in your next audit. For each one, ask whether you could produce a durable, independently verifiable record today, or whether you would be reconstructing it after the request arrives. The difference between those two answers is where the work begins.