An 18% Budget Cut With a Cloud Mandate

Method: start from the top five risk scenarios already accepted in the risk appetite statement - for an insurer that is usually claims data integrity, ransomware halting underwriting, third-party and cloud concentration, privileged access misuse, and regulatory findings. Map every line of spend to the scenario it reduces and the control it evidences. Anything mapping to nothing is a candidate; anything supporting a scenario with no compensating control is protected.

Run versus change: the 18% is a run-rate cut, but cloud migration and the DTC channel are change. Neither should silently consume the other's budget; both get a number.

Trade-off one - SIEM/MSSP: the $2.8m termination fee makes exit value-destructive. Instead, renegotiate at renewal: tiered log ingestion, de-scope low-value sources (guest-network netflow, verbose application logs), keep 24x7 detection content and response SLAs. Saves 15-20% without losing the capability producing evidence for the two open findings.

Trade-off two - GRC tooling: a plausible 50% cut on paper, but it is the evidence pipeline for the exam in nine months. Cutting it converts licence cost into analyst hours and exam risk. I would cut scope - fewer integrated frameworks - before cutting the tool.

Every reduction carries a named acceptor and a written residual-risk statement. A cut that nobody owns comes back as my failure at the next exam.

Five blocks on the page:

1. What changed - budget, cloud, DTC, exam date. Context first, so the numbers are read against reality.
2. What we are protecting - the top risk scenarios in business language (claims not paid, policyholder data exposed, exam finding, channel outage), never control names.
3. Three options with cost and consequence - for example: Option A, take the 18% cut as instructed, with these five capabilities degraded and this residual risk accepted. Option B, a 12% cut plus MSSP renegotiation and a 3% programme levy on cloud and DTC. Option C, flat funding, paid for by deferring two non-security projects. Each states what it buys and what it costs.
4. What I am not doing, and who owns that risk - explicit, signed, dated.
5. Leading indicators - four or five, with thresholds that trigger escalation.

Avoiding false comfort and fear: no red-amber-green heat map without a sentence on what would actually happen. Quantify where I can - exam remediation cost, expected downtime hours, service-credit exposure - and say 'unknown' where I cannot. A CISO who predicts catastrophe every quarter is ignored by the third quarter; a CISO who reports all-green is not believed in the first. Calibrated language is the deliverable, not dramatic language.

Position: security is a gate with a paved road, not a tax on delivery.

Practical stance:

• Define a minimum control baseline as entry criteria for any cloud workload or DTC service: identity, logging into the SIEM, encryption and key management, vulnerability management, tested backup and restore. Published, versioned, and meetable by default from the platform.
• Put cost where the value is. Platform-level controls - logging, IAM, guardrails - are funded centrally and consumed by all programmes; that is far cheaper than 40 teams buying 40 tools. Workload-specific controls are funded by the programme.
• Introduce showback in year one so each business unit sees its security consumption. Chargeback follows once the numbers are trusted.
• Fund the central capability with a programme levy proportional to programme spend - typically 3-5% for a regulated migration - agreed before the programme business case is approved, not after the money is committed.

If it is not funded: I do not silently absorb it by cutting detection. I write a risk acceptance naming the accountable executive, stating the constraint (workloads will run without central logging), and take it to the risk committee. My job is to make the trade-off visible and owned, not to pretend it does not exist or to fund it by starving the controls that keep the insurer out of the exam findings.