Cloud Security: Executive Briefing for Boards

Most serious cloud breaches are not failures of the cloud provider but of how the customer configured and governed its own use of the service, and boards often do not know where that line sits. This briefing is for board members, chief executives and the executives who answer to them for technology risk. It explains the shared responsibility model in business terms, why misconfiguration and stolen credentials drive cloud incidents, why dependence on a few providers is a strategic risk in its own right, and the questions and red flags that tell directors whether management has cloud security under control. It stays at board level; the staged capability detail is in the Cloud Security Maturity Model and the technical controls in the Cloud Security Guide.

The risk in one paragraph

Moving to the cloud moves some security work to the provider but never the accountability. The provider secures the data centres, hardware and the platform it runs; the customer remains responsible, in the UK NCSC's words, for making sure the service meets its security needs, configuring the services it chooses securely and deciding which data to put in them. Cloud makes that configuration fast, programmable and global, so a single wrong setting or a single stolen password can expose millions of records in minutes, and the activity often looks like normal use of a valid account. At the same time, concentrating critical services on one or two providers turns their outage into your outage. The board's job is not to judge technical settings but to insist that responsibilities are clear, that identities and configurations are governed continuously rather than audited once a year, and that the business can survive losing a provider or a region.

Why this is a board-level issue now

Valid credentials are the main way in: in the 2024 Snowflake customer data thefts, Mandiant and Snowflake notified about 165 potentially exposed organisations. Mandiant found the accounts used had no MFA, at least 79.7% had credentials previously exposed by infostealer malware, some credentials dating back to 2020 had never been rotated, and the affected instances had no network allow lists. No flaw in the platform was found. See the Snowflake breach.
Regulators judge the governance, not only the attacker: after the 2019 Capital One breach, in which an attacker obtained the cloud role credentials of a misconfigured web application firewall and copied data on about 100 million people in the US and 6 million in Canada, the US Office of the Comptroller of the Currency imposed an $80 million civil money penalty tied to weaknesses in cloud risk management. See the Capital One breach.
Machine identities now outnumber people: workloads, pipelines and integrations authenticate with roles, keys and tokens that nobody logs in with and few people review. In the Capital One case the stolen identity belonged to a firewall, not a person.
Governments now publish what "good" means: the US NSA, with CISA on six of the items, published its Top Ten Cloud Security Mitigation Strategies in March 2024, starting with "uphold the cloud shared responsibility model". The UK NCSC publishes 14 Cloud Security Principles for choosing and assessing providers. Directors can ask management to show alignment.
Directors are expected to own cyber risk: the UK government launched its Cyber Governance Code of Practice for boards and directors on 8 April 2025. See the UK Cyber Governance Code of Practice Guide.

Shared responsibility in business terms

The split of security work depends on the type of service. NCSC advises customers to hand as much responsibility to the provider as their needs allow, preferring software as a service where it fits, then platform services, and to replace self-built components such as logging, monitoring and identity with managed services where possible.

Service model	Provider typically secures	Your organisation always owns	Board implication
Infrastructure as a service (IaaS)	Physical facilities, hardware, hypervisor, core network	Operating systems, network rules, identities, keys, data, logging, configuration	Most control, most work, most room for error; needs strong in-house engineering
Platform as a service (PaaS) and serverless	The above plus operating system and runtime	Application code, identities and permissions, configuration, data	Less to patch, but permissions and configuration still decide exposure
Software as a service (SaaS)	Almost all of the stack	Who has access, how they authenticate, integrations, data placed in it, tenant settings	Least work, but identity and integration risk remain fully yours
Managed service provider on top	Whatever the contract says	Oversight of the provider's privileged access to your environment	A third party with administrator rights: least privilege and audit, as NCSC and NSA both advise

The point for directors is the last column of the middle section: identity, configuration and data decisions never transfer. See the Shared Responsibility Models Guide.

Misconfiguration and identity: where cloud incidents start

Cloud incidents cluster around a short list of causes, and almost all are within the customer's control.

Cause	What it looks like	What management should have in place
Password-only access to cloud services	Stolen credentials work from anywhere; Snowflake 2024	Single sign-on and phishing-resistant MFA for every human; no password-only service accounts
Over-permissioned workload identities	A firewall or application role can read far more data than it needs; Capital One 2019	Least-privilege roles, owners for every machine identity, regular entitlement review
Long-lived keys and secrets	Access keys in code repositories or images that keep working for years	Short-lived federated credentials, secrets management, scanning and rotation
Publicly exposed storage and services	Storage buckets, databases or management consoles open to the internet	Guardrails that block public exposure by default; continuous posture checks
Missing or unread logs	Breach discovered by an outsider months later	Cloud audit logs retained centrally and monitored, alerts on bulk data export
Manual, unreviewed changes	Settings drift from the approved design	Infrastructure as code with review, policy checks before deployment

See the Cloud Misconfiguration Guide and the Cloud Workload Identity Guide.

Concentration and exit: the strategic risk

Concentration risk is the business consequence of depending on a small number of providers, regions or services for critical operations. It is not a security failure by your team, which is why it is often missed in security reporting. Directors should expect management to answer three things:

Dependency map: which critical business services run on which provider, region and underlying services, including the SaaS products that themselves run on the same hyperscalers.
Tolerance: how long each critical service can be unavailable, and whether the architecture (multiple zones or regions, or a second provider) actually meets that tolerance in a test.
Exit: a documented, costed plan for leaving a provider or moving a critical service, with data portability and contract terms checked. Financial services firms in the EU face explicit expectations here under DORA. See the Cloud Concentration Risk and Exit Strategy Guide and the DORA Executive Briefing.

NSA's guidance adds that hybrid and multi-cloud estates bring their own complexity: more consoles, more identity systems and more inconsistent logging. A second provider reduces dependency but increases the attack surface, so it should be a deliberate decision with a security budget attached, not a slogan.

Where cloud oversight sits in the frameworks

Boards that report against a framework can ask for cloud evidence under these references:

Framework	Reference	What the board should see
NIST CSF 2.0	GV.SC-01	A supply chain risk programme that covers cloud and SaaS providers
NIST CSF 2.0	PR.PS-01	Configuration management practices applied to cloud resources
NIST SP 800-53 Rev. 5	SA-9 External System Services	Provider assurance and agreed security requirements
NIST SP 800-53 Rev. 5	AC-2, AC-6	Account management and least privilege for people and workloads
NIST SP 800-53 Rev. 5	CP-2 Contingency Plan	Recovery and exit for critical cloud services
NCSC Cloud Security Principles	Principles 9, 10, 13 and 14	Secure user management, identity and authentication, audit information, secure use of the service

Five questions for the board to ask

Where exactly does our responsibility start? For our five most critical cloud and SaaS services, show us what the provider secures, what we secure, and who in the organisation owns our part.
Can anyone reach our cloud data with just a password? What percentage of human and service access to cloud and SaaS platforms uses single sign-on with MFA, and how many service accounts still use passwords or long-lived keys?
How do we know our configuration is right today, not at the last audit? Show us continuous posture results against a published baseline, the trend in high-risk findings, and how fast they are fixed.
Would we see a bulk data theft while it happens? Are cloud audit logs collected, retained and monitored, and when did we last test detection of a large export by a valid account?
What happens if our main provider or region is unavailable for a week? Which services stop, what does it cost, when did we last test failover, and what is the exit plan?

Red flags in management answers

"The provider handles security": management cannot describe the customer side of the shared responsibility model.
No inventory of cloud accounts and subscriptions: shadow accounts created by teams or acquisitions sit outside central guardrails.
Machine identities nobody owns: management can count employees with cloud access but not roles, keys and service accounts.
Annual review instead of continuous checks: configuration is assessed once a year by an auditor rather than continuously by tooling.
Logs "available" but not collected: logging is switched on in the console but not retained or monitored centrally.
Resilience assumed from the provider's marketing: availability claims rest on the provider's architecture, not on a failover test of your own services.

What good looks like

A cloud security standard approved by management that sets baselines, ownership, logging and identity requirements for every cloud and SaaS service, aligned to a published baseline. See the Cloud Security Policy Template.
A complete inventory of cloud accounts, subscriptions and projects, each with a business owner, under organisation-wide guardrails.
Single sign-on and phishing-resistant MFA for all people; workloads using short-lived federated credentials; every machine identity owned and reviewed. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments guide.
Continuous posture management with agreed fix times for high-risk findings. See the Cloud Security Posture Management (CSPM) Guide.
Infrastructure changes made through reviewed code with automated policy checks.
Cloud audit logs retained centrally and monitored, with a tested cloud incident response plan. See the Cloud Incident Response Guide.
A dependency map, tested recovery for critical services, and a documented exit plan.

Where to invest first

Identity: remove password-only access for people and service accounts, and replace long-lived keys with short-lived credentials. This would have blocked the access route in the Snowflake campaign.
Visibility: a full inventory of cloud accounts, data stores and machine identities, with owners.
Guardrails: organisation-level policies that prevent public exposure and enforce encryption and logging by default, so individual teams cannot get them wrong.
Detection: central cloud logs with alerts on bulk export, new privileged roles and access from unusual networks.
Resilience: dependency mapping and a tested failover for the most critical service, then the exit plan.

Metrics to track

Metric	What it tells the board
Percentage of cloud and SaaS access (human and service) using SSO with MFA or federated short-lived credentials	Exposure to the most common attack route
Number of long-lived access keys and password-based service accounts, and their age	Machine identity hygiene
Cloud accounts and subscriptions under central guardrails, as a percentage of all known	Coverage of governance
Open high-risk posture findings and median days to fix	Whether configuration risk is being reduced
Critical services with a tested recovery or failover within tolerance in the last 12 months	Real resilience versus assumed
Time to detect in the last exercise simulating bulk data export	Whether monitoring works

A 90-day plan

Days 1 to 30: management presents the shared responsibility split and named owners for the top five cloud and SaaS services, plus a first inventory of cloud accounts and machine identities; confirm MFA coverage figures.
Days 31 to 60: close password-only and MFA gaps on critical platforms; apply organisation-wide guardrails against public exposure; start continuous posture reporting against a published baseline.
Days 61 to 90: board receives the first metrics pack, a dependency map for critical services and a plan for a failover test and exit plan; cloud security metrics join the regular risk report. See the Board Cyber Risk Reporting Guide.

Common failure patterns

Responsibility assumed, not assigned: each team believes another, or the provider, owns a control, so nobody does.
Contractors and third parties outside the controls: MFA and SSO enforced for employees but not for contractor and service logins, which is where stolen credentials work.
Workload roles granted broad access for convenience: a front-end or appliance role that can read every storage bucket turns a small flaw into a mass data loss.
Credentials that never expire: keys and passwords stay valid for years after they leak.
Multi-cloud without consistent controls: a second provider added for resilience runs with weaker identity and logging than the first.

Lessons from incidents

The two cases share a board-level lesson: the attacker used a legitimate identity, so the provider's controls saw nothing unusual and the customer's governance was the only defence. In the Snowflake campaign, three customer-side gaps, no MFA, unrotated credentials and no network allow lists, explain the access, and Snowflake later moved to phase out single-factor password sign-ins. At Capital One, a machine identity with far more access than its job required let one flaw expose data on over 100 million people, and the regulator's penalty focused on cloud risk management. Neither case needed exotic defences; both needed ownership, least privilege and monitoring of identities.

Practitioner checklist

Document the shared responsibility split and an owner for each critical cloud and SaaS service.
Maintain an inventory of cloud accounts, subscriptions, projects and machine identities with owners.
Enforce SSO and phishing-resistant MFA for all people, including contractors and administrators.
Eliminate password-only service accounts and long-lived keys where the platform supports alternatives.
Apply organisation-level guardrails against public exposure and for encryption and logging.
Run continuous posture checks against a published baseline with agreed fix times.
Collect and monitor cloud audit logs centrally and alert on bulk data export.
Map dependencies, test recovery for critical services and keep a costed exit plan.
Report cloud metrics to the board at least quarterly.

Standards and references

How NHI Mgmt Group can help

We provide independent identity and non-human identity risk assessments and board briefings, including how cloud roles, service accounts, access keys and integration tokens are governed across cloud and SaaS estates. Our NHI Foundation Level Training Course helps security and IAM teams govern service accounts, API keys and secrets. Contact us to arrange a briefing.

Cloud Security Executive Briefing: What Boards Need to Know and Ask