Operate
Cloud operations and FinOps
Patching, backup with tested restores, monitoring and cost attribution — the unglamorous work that determines whether an estate is defensible and affordable. Including the two numbers most organisations cannot produce: patch compliance and what each team actually spends.
Duration
Baseline 3 weeks, then continuous
Built on
ISO/IEC 27001 Annex A · FinOps Framework
Who this is for
Infrastructure lead
Knows patching has slipped and cannot prove by how much.
CFO
Has a cloud bill that grows and cannot be attributed to anyone.
CISO
Needs patch compliance as evidence, not as an assurance.
Auditor
Wants a restore test, not a backup policy.
The patch level and the bill are the two things nobody owns
Exploitation of known, already-patched vulnerabilities remains one of the most common root causes of serious incidents. Not novel attacks — things with a published fix that was not applied, because patching is everyone's responsibility in principle and nobody's job in practice.
The honest question is not whether you patch. It is what your compliance percentage is this week, which systems are the exceptions, who decided they could be exceptions, and when that decision expires. Most organisations cannot answer any of the four.
Backups have the same shape. Almost everyone has them. Far fewer have tested a restore within the last year, and an untested backup is a belief rather than a control. The moment you discover the restore does not work is always the worst possible moment.
Cost has become a security-adjacent problem too, because unattributed spend hides things. A subscription nobody owns is also a subscription nobody patches, monitors or reviews. FinOps is often sold as cost cutting; the more useful framing is attribution — making every euro belong to a team who can act on it. The savings follow from that, and they are usually substantial because the first pass finds resources nobody has thought about in years.
None of this is interesting work, which is precisely why it is unowned and why it is where incidents start.
How we do it
- 01
Baseline
2–3 weeks
Current patch position, backup coverage, monitoring coverage and cost attribution. All four are usually worse than expected, and the first report is the most valuable one.
- 02
Patch cadence
1 week
An agreed schedule by system criticality, with an exception process that requires an owner and an expiry date rather than a shrug.
- 03
Backup and restore testing
ongoing
Coverage corrected where it is missing, and a restore test schedule that actually runs. Evidence retained for your auditor.
- 04
Cost attribution
2 weeks
Tagging standard applied, spend attributed to teams and services, and reporting that goes to the people who can change it rather than only to finance.
- 05
Optimisation cycle
quarterly
Right-sizing, commitment and reservation decisions, retirement of orphaned resources, and the savings tracked as realised rather than identified.
- 06
Reporting
monthly
Patch compliance, backup and restore status, incidents, spend against forecast, and the exceptions still open.
Named artefacts
What you receive
- Patch compliance reporting, by system criticality
- Exception register with owners and expiry dates
- Backup coverage assessment and corrections
- Restore test schedule and the evidence from each test
- Tagging standard and cost attribution by team and service
- Right-sizing recommendations, with savings tracked to realisation
- Orphaned resource register
- Monthly operations report and quarterly capacity and cost review
What we need from you
- Agreement on maintenance windows, and a realistic number of them.
- An owner for each exception. An exception without a name is a permanent gap.
- Finance's cost data, so attribution can be reconciled to what you are actually billed.
- Authority to retire orphaned resources, with an agreed grace period before anything is deleted.
What changes
- 01You can state your patch compliance percentage this week, with evidence.
- 02Every exception has a name and an expiry date.
- 03Restores have been tested, so recovery is a known quantity rather than an assumption.
- 04Every euro of spend belongs to a team who can act on it.
- 05Savings are tracked as realised, not as identified in a slide.
What it costs
On request
All prices exclude VAT.
Questions
Does FinOps just mean cost cutting?
No, and treating it that way produces one round of savings and no lasting change. The point is attribution — once a team can see its own spend, most optimisation happens without anyone being asked. The reductions in the first quarter are usually large, because the first pass finds resources nobody has thought about in years.
How often should restores be tested?
Critical systems quarterly, everything else annually, and always after a significant change to the backup configuration. The test has to be a real restore to a usable state — verifying that a backup job reported success is not a test.
What patch compliance should we aim for?
Set it by criticality rather than as a single number, and make the exception process the real control. An organisation at 95% with every exception named, owned and expiring is in far better shape than one claiming 99% with no exception register at all.
Can you do this if someone else runs the platform?
Yes, and it is a common arrangement. We need read access, agreed change windows and a route to whoever executes changes.
Leave with your top three risks documented
Thirty minutes with a senior practitioner. No slideware, no sales engineer.