Cloud spend is attack surface

A cloud invoice is the most complete inventory of running systems that most institutions possess. It is itemised, it is produced monthly without anyone being asked, and unlike every asset register maintained by hand it cannot omit a resource, because the provider is charging for it. That document is delivered to finance and procurement, where it is read for a single purpose: is the number larger than last month, and can it be made smaller.

The consequences of what is on that list land somewhere else. An instance nobody owns is not a budget variance, it is an unpatched host. A storage bucket created for a migration that finished two years ago is not a rounding error, it is data with no reviewer. The costs are read by one function and the risks are carried by another, and the two functions are looking at the same list.

The mismatch is structural rather than anybody's failure. Finance has the document and no mandate to ask who owns line item four hundred and twelve. Security has the mandate and works from an asset register that was assembled by asking teams what they run, which is to say a register that is complete only where people remembered. Meanwhile the platform made creating resources a self-service action, correctly, because that is most of the value of moving. Nobody made forgetting them cost anything. The rest of this document is about reading the bill as the control artefact it already is.

The claim is narrow and mechanical. Patching, configuration review, log review and decommissioning are all activities that require somebody to decide to do them. When no owner exists, no such decision is taken, and the resource continues running in the configuration it had on the day it was created. Nothing has to go wrong for this to happen; it is the default state of an unowned system, and drift is the only thing operating.

This is not a FinOps argument dressed up as a security one. Established security doctrine already puts inventory first. Inventory and Control of Enterprise Assets is CIS Critical Security Control 1, ahead of anything about patching, logging or monitoring. It asks organisations to actively manage all enterprise assets connected to the infrastructure "physically, virtually, remotely, and those within cloud environments, to accurately know the totality of assets that need to be monitored and protected". It also asks explicitly for the identification of "unauthorized and unmanaged assets to remove or remediate". Asset management sits in the Identify function of the NIST Cybersecurity Framework 2.0, upstream of Protect. The doctrine has always been that you cannot defend what you have not enumerated.

So the argument in this document is not that people who manage cost should care about security. It is narrower and harder to dismiss: the enumeration that Control 1 asks for already exists, it is produced monthly by the cloud provider, and it is being read by the wrong function for the wrong purpose. Cost allocation and asset inventory are the same exercise conducted with different intent, and only one of the two has an unavoidable, complete, monthly data source.

One boundary, because the claim is easy to overstate and this is where a sceptical reader should push. An owned resource is not automatically a patched resource. Ownership creates an accountable party; it does not perform maintenance, and a resource with a nominal owner who does nothing is no better patched than an orphan. What ownership changes is that the omission becomes attributable and can therefore be measured, reported and escalated. That is the entire claim. It is smaller than "FinOps improves security" and it is defensible, which is worth more.

The survey behind this section was titled Malaysia's Cloud Survey 2020. The slide presenting it records that it was led by Alphaus Cloud in collaboration with Hitachi Sunway, and supported by the MDEC Cloud Department, MAJECA, MASSA, UUM, PIKOM and Integra. Mohd Atasha presented the findings at the inaugural KL Cloud Maestro Series on 2 October 2020. Two results have been carried on the public record since then and are repeated here unchanged: half of respondents cited missing skill sets as the largest gap after adoption, and four in five named scalability as the principal benefit they sought.

Read together those two numbers describe a specific and predictable failure. Organisations adopted the cloud for scalability, which is a capability for creating resources quickly, while identifying their own largest post-adoption gap as skills. Rapid creation and thin operational capacity is the condition under which unowned resources accumulate, and it accumulates fastest in exactly the organisations that got the most value from adopting. This is not an argument against scalability. It is an argument that the skills gap the respondents named themselves has a security consequence they were not describing at the time, because it was being discussed as a cost and capability question.

The method can now be stated, and it matters more than the percentages do. It was an online survey, undertaken because the industry data the organisers wanted did not exist: in the presenter's own words, "we don't get the data", so the survey was run rather than the gap assumed. There were 105 respondents. The average size of a participating organisation was about 1,200 people, and the respondents held senior technology and executive roles. The slide names a selection of the participating organisations, among them Hitachi, Etiqa, Celcom, TIME, Schlumberger, Boost, AT&T, Gamuda, TM and Sunway Medical Centre, which places the sample among large Malaysian enterprises rather than among small businesses. A stated n of 105 in that population is a modest but real sample, and it is worth considerably more than a percentage with no denominator behind it.

The same slide carries three findings that are not the two quoted above and are stated here because they are legible on the record: 77 per cent of respondents had adopted cloud in some form, 45 per cent used public cloud and 37 per cent used a hybrid arrangement. Those figures describe the shape of adoption rather than its consequences, which is why the two results at the head of this section remain the ones the argument rests on.

Three limits, because the point of publishing a method is that a reader can find its weaknesses. The duration is recorded inconsistently in the source itself: the slide states three weeks and the presenter says about two, and rather than choose the more convenient number, both are noted here. The question wording and the sampling frame, meaning how participants were approached and who could have answered but did not, are still not published, so this remains a survey of those who chose to respond. And the surviving recording is a short extract that shows only the summary slide, so it establishes the method above but does not itself display the skills and scalability figures; those rest on the presenter's own record of the survey rather than on the recording. Each of those is a reason to treat the two headline results as an indication rather than a measurement, and saying so is cheaper than being corrected later.

Tagging is usually implemented to answer the question "which cost centre does this belong to", and the answer is a code. It could as easily answer "who is accountable for the security state of this resource", and the answer would be a person. The instrumentation is identical; only the intent differs, and the intent determines whether the output is usable as a control.

Four properties separate ownership that functions as a control from a spreadsheet column. It names a person or a defined role, not a cost centre, because a cost centre cannot patch anything. It is enforced at creation, so that an untagged resource is either refused or quarantined, since retrospective tagging campaigns are how organisations discover that nobody remembers. It is validated against a live source, because the most common failure is not the absent tag but the tag naming somebody who left in March, and an owner who no longer exists reads as ownership while providing none. And unallocated spend is treated as a finding with an assignee and a date rather than a residual percentage, which is the single highest-value change available: in most estates the unallocated line is where the orphans are, and it is currently a rounding note in a monthly report rather than a security queue.

The reason to reuse the cost mechanism rather than build a parallel one is that the cost mechanism is the only one with an unavoidable and complete monthly refresh. A security asset register decays the moment people stop updating it. The bill does not decay, because the provider has a commercial interest in its completeness. Attaching accountability to that artefact means the control is refreshed by somebody else's billing system, which is a considerably more reliable arrangement than depending on institutional memory.

The FinOps Framework is a competent instrument for what it was built to do, and this document has been leaning on its machinery throughout. Its capabilities include allocation, tagging and showback, which are precisely the mechanisms the previous section reuses. It is worth being exact about where it stops, because overstating it would undermine the argument.

It optimises cost. Its purpose is to make spend visible, attributable and defensible, and the questions it is designed to answer are whether a resource is worth what it costs and who should carry the charge. It does not ask whether a resource is patched, whether its configuration has been reviewed, or whether the person named against it is still employed. A mature FinOps practice will happily allocate one hundred per cent of the spend on an unpatched instance to the correct cost centre and report that as success, because by its own terms it is.

The seam is therefore precise. FinOps produces the enumeration and the attribution; it does not produce the security decision that follows from them, and nothing in the framework requires anybody to make it. Closing that seam is an organisational act rather than a tooling one, and it is small: the allocation report has a second reader, unallocated spend has an assignee and a due date, and the ownership field is validated against the identity directory rather than a spreadsheet. None of that is in the framework. All of it is available to anyone already doing the framework.

Two limits belong in the open. This discipline addresses the resources you are billed for, which excludes anything running in an unbilled account, on premises, or under a personal payment card, and shadow IT of that kind is exactly the case where the bill is not the inventory. And enumeration plus ownership is where security work starts rather than where it concludes: the vulnerability management, configuration and log review still have to happen. The claim here is only that they cannot happen on a resource nobody has enumerated, and that the enumeration already exists.

Mohd Atasha, Cloud spend is attack surface, version 1.1, revised 2026-08-09. Available at mohdatasha.com/doctrine/finops-as-control/