Most cloud security reporting gives the board a posture percentage and a count of findings, neither of which tells directors whether the organisation could lose its most important data through the cloud next quarter. This guide sets out a small set of board-level key performance indicators (KPIs) and key risk indicators (KRIs) for cloud security, covering posture, identity, detection and recovery across AWS, Azure and Google Cloud (providers are listed alphabetically). For each measure it gives a formula, the reason a board should care, and where the data comes from in each provider's native services. It is written for CISOs, heads of cloud security and the risk and audit staff who prepare board packs. Operational, team-level measures are deliberately left to the health checks linked below; this page is about the few numbers that support board decisions.
Key takeaways
- Report exposure, not activity. The board needs to know how many paths exist to critical data and how fast they close, not how many findings were raised.
- Pair every KPI with a KRI. A rising posture score alongside a rising count of exposed crown-jewel data stores is a warning, not a success.
- Vendor posture scores are inputs, not board metrics. AWS Security Hub, Microsoft Defender for Cloud and Google Cloud Security Command Center each calculate scores differently, so they cannot be added up or compared.
- Identity drives cloud risk. Standing privilege and long-lived credentials, mostly held by non-human identities, belong on the board scorecard.
- Coverage comes first. State what share of the cloud estate the numbers describe; every other figure is only as good as that denominator.
What the board needs from cloud security metrics
Boards approve risk appetite, investment and accountability. Cloud metrics earn a place in the board pack only if they help with one of those decisions. In practice that means answering four questions:
- Are we covered? What share of the cloud estate is under central guardrails, logging and monitoring, and is shadow cloud shrinking?
- How exposed are we? How many routes exist from the internet or a compromised identity to critical systems and data?
- Would we notice and respond? How quickly are serious cloud incidents contained, and are detections tested?
- Could we recover? Have critical cloud workloads been restored in a test within the last year?
NIST CSF 2.0 places this under GV.OV-03 (cybersecurity risk management performance is evaluated and reviewed for adjustments needed), and NIST SP 800-53 Rev 5 control PM-6 (Measures of Performance) requires organisations to develop, monitor and report on the results of measures. NIST's measurement guide, SP 800-55 Volume 1 (December 2024), covers how to identify, prioritise and select measures. For the general method of building a security metrics programme, see the Security Metrics and KPIs Programme Guide.
KPIs, KRIs and operational metrics
| Type | What it answers | Cloud example | Audience |
|---|---|---|---|
| Key performance indicator (KPI) | Is the programme delivering the controls we funded? | Share of privileged cloud access granted just in time | Board, executive committee |
| Key risk indicator (KRI) | Is exposure rising towards or beyond appetite? | Crown-jewel data stores reachable from outside the organisation | Board, risk committee |
| Operational metric | Is the team and tooling working day to day? | Scan freshness, mean time to remediate by severity, suppression hygiene | Cloud security and platform teams |
Operational metrics feed the board measures but should not be shown to the board unless they explain a movement. The CNAPP and CSPM platform health check and the Cloud Identity Health Check hold the operational sets; this scorecard shares only two measures with them (estate coverage and long-lived credential share) because those two matter at both levels.
The board scorecard: ten cloud KPIs and KRIs
Keep the board set to around ten measures, stable from quarter to quarter so trends mean something. Each formula states its numerator and denominator; report both, not only the percentage.
| # | Measure | Type | Formula | Why the board cares |
|---|---|---|---|---|
| 1 | Governed estate coverage | KPI | Accounts, subscriptions and projects under the central organisation, guardrails and log collection / all known accounts, subscriptions and projects (including those found through billing and expense data) | Ungoverned cloud is unmanaged risk; every other figure describes only the governed part |
| 2 | Critical attack paths to crown jewels | KRI | Count of open attack paths or toxic combinations rated critical that end at a resource tagged as critical, at period end | The most direct measure of how a breach would happen |
| 3 | Time to close critical attack paths | KPI | Median days from first detection to verified closure for critical attack paths closed in the period | Shows whether the organisation can act on what it finds |
| 4 | Externally reachable sensitive data | KRI | Data stores classified as confidential or above that are publicly accessible or shared outside the organisation without an approved exception / all such data stores | Public storage remains a leading cause of cloud data exposure |
| 5 | Standing cloud privilege | KPI | Privileged cloud role assignments that are eligible or just-in-time / all privileged cloud role assignments (human and non-human) | Standing admin rights turn one stolen credential into full control |
| 6 | Long-lived credential share | KRI | Active workloads authenticating with static access keys, client secrets or service account keys / all active workload identities | Static keys are the credentials most often leaked and reused |
| 7 | Tested detection coverage | KPI | Priority cloud attack techniques with a detection tested in the last 6 months / priority techniques on the organisation's threat list | Shows whether investment in monitoring would catch the attacks that matter |
| 8 | Time to contain high-severity cloud incidents | KPI | Median hours from detection to containment (credential revoked, access removed or resource isolated) for high and critical cloud incidents in the period | Dwell time drives impact and notification exposure |
| 9 | Protected audit trail | KPI | Production accounts, subscriptions and projects whose control plane logs flow to a central store that workload administrators cannot modify or delete / all production accounts, subscriptions and projects | Without trustworthy logs, investigation and regulatory reporting fail |
| 10 | Recovery tested | KPI | Critical cloud workloads with a successful restore or failover test in the last 12 months / all critical cloud workloads | Resilience against ransomware, deletion and provider outage |
For measure 2, decide once what counts as "critical" (for example, internet-exposed, with an exploitable vulnerability or a privileged identity attached, and reaching regulated or business-critical data), and keep that definition fixed. For measure 7, take the technique list from the organisation's threat model; common cloud entries include MITRE ATT&CK T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials, T1528 Steal Application Access Token, T1530 Data from Cloud Storage, T1552.005 Cloud Instance Metadata API and T1580 Cloud Infrastructure Discovery.
Where the numbers come from in AWS, Azure and Google Cloud
Each provider's native services supply most of the raw data. Their scores use different methods, so use them to calculate the measures above rather than reporting the scores themselves.
| Input | AWS | Azure | Google Cloud |
|---|---|---|---|
| Posture findings and score | AWS Security Hub: standard score is passed controls divided by passed, failed and unknown controls; scores update every 24 hours | Microsoft Defender for Cloud: classic secure score from control points per resource, and a risk-based cloud secure score from 0 to 100 weighted by recommendation risk and asset criticality | Security Command Center: findings from built-in detectors, with attack exposure scores and toxic combinations for prioritisation |
| Estate inventory (measure 1) | AWS Organizations account list | Management group and subscription hierarchy | Organisation resource hierarchy (folders and projects) |
| Unused and excessive access (measures 5 and 6) | IAM Access Analyzer unused access findings (unused roles, access keys, passwords and permissions); IAM credential report | Microsoft Entra role assignments and Privileged Identity Management eligibility; app registration credential inventory | IAM recommender and service account key inventory |
| Audit trail (measure 9) | AWS CloudTrail organisation trail | Activity Log and Entra logs routed through diagnostic settings | Cloud Audit Logs with organisation-level log sinks |
Two scoring details affect board numbers directly. In AWS Security Hub, suppressing all failed findings for a control changes the control's status to passed, which can raise the score, so pair the score with a review of suppressions. In Microsoft Defender for Cloud, Microsoft notes that from 30 June 2026 over 200 new AWS and Google Cloud recommendations contribute to secure score, so a score drop after that date can reflect a wider assessed scope rather than a worse environment. Annotate the board chart when scope changes like this occur. Deeper guidance on each service is in the AWS Security Hub Guide, the Microsoft Defender for Cloud Guide and the Google Cloud Security Guide.
Thresholds and risk appetite
A KRI only helps the board if it has a threshold agreed in advance. Set three bands per measure and record them in the cloud security standard.
| Measure | Example within appetite | Example escalate to executive | Example escalate to board |
|---|---|---|---|
| Critical attack paths to crown jewels | 0 open beyond 7 days | Any open beyond 7 days | Any open beyond 30 days, or a rising trend over two quarters |
| Externally reachable sensitive data | 0% | Any confirmed case closed within 48 hours | Any case open beyond 48 hours, or any with evidence of access |
| Long-lived credential share | Falling each quarter towards target | Flat for two quarters | Rising, or any static key on an administrative identity |
| Recovery tested | 100% within 12 months | 90% to below 100% | Below 90%, or a failed test not re-run |
These are illustrative NHI Mgmt Group starting points; set your own values from risk appetite, sector regulation and the current baseline. A single critical item (an exposed crown-jewel store, a key on an admin identity) should be reported by exception whatever the percentage shows.
Building the reporting pipeline
- Agree definitions first. Write each measure's numerator, denominator, data source, owner and threshold on one page and have the CISO and risk owner sign it off. Define "critical workload", "crown jewel" and "privileged role" once.
- Fix the inventory. Reconcile the provider organisation lists against billing data and the configuration management database before reporting measure 1. Unknown accounts found later will otherwise move every figure.
- Tag what matters. Apply data classification and criticality tags to resources so attack-path and data measures can be filtered. See the Cloud Resource Tagging Standard Template.
- Automate collection. Export findings and identity data on a schedule (for example, Security Hub findings, Defender for Cloud exports and Security Command Center exports to BigQuery or Pub/Sub) into one store, with the run date recorded.
- Run a shadow quarter. Produce the scorecard internally for one quarter before it goes to the board. Check that movements can be explained and that owners agree with their numbers.
- Baseline and set targets. Use the shadow quarter as the baseline; set targets as quarterly improvements rather than absolute values in the first year.
- Report and annotate. Present trend lines over at least four quarters, with notes on scope changes, new accounts or tooling changes.
- Review annually. Retire measures that no longer drive decisions; keep at least the coverage, exposure and recovery measures stable for continuity. If a new measure turns out to be unreliable, revert to the previous definition and say so in the pack.
Choosing measures for your organisation
- Small organisations with one provider: start with five measures (1, 4, 5, 6 and 10). Use the provider's native posture service and identity reports; a spreadsheet updated monthly is enough.
- Large or multi-cloud organisations: use the full set, calculated centrally, with per-provider breakdowns available but the headline figure across the estate. A CNAPP or a data warehouse is usually needed to calculate attack paths and identity measures consistently. See the CNAPP Guide.
- Regulated sectors: add a measure tied to the regulator's expectations, for example concentration or exit readiness for material cloud outsourcing. See the Cloud Concentration Risk and Exit Strategy Guide.
- Organisations early in maturity: report coverage and the trend in long-lived credentials before attack-path measures, which need tagging and tooling. The Cloud Security Maturity Model helps sequence this.
Framework mapping
| Measure area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 |
|---|---|---|
| Programme performance reporting | GV.OV-03, ID.IM-01 | PM-6 Measures of Performance |
| Estate coverage | ID.AM-01 | CA-7 Continuous Monitoring |
| Attack paths and exposure | PR.PS-01 | CM-6 Configuration Settings, RA-5 Vulnerability Monitoring and Scanning |
| Privilege and credentials | PR.AA-05 | AC-2 Account Management, AC-6 Least Privilege |
| Detection and audit trail | DE.CM-01 | AU-6 Audit Record Review, Analysis, and Reporting; SI-4 System Monitoring |
Common failure patterns
- Reporting a vendor score as the headline: a posture percentage can rise because findings were suppressed or fall because more checks were added, with no change in real risk.
- Counts without denominators: "120 critical findings" says nothing unless the board knows whether the estate holds 40 accounts or 4,000.
- Leaving out non-human identities: scorecards that count only human admins miss the roles, service principals and keys that hold most cloud privilege. In the Capital One breach, a firewall's role credentials could read far more storage than the role needed, which is exactly what measure 5 and measure 2 are meant to surface.
- Measuring only the cloud provider estate: SaaS data platforms hold crown-jewel data too. The Snowflake breach involved static, single-factor passwords without network restrictions, so extend measure 6 to service users on data platforms.
- Changing definitions every quarter: trends become meaningless and the board loses confidence; version the definitions and change them once a year.
- No owner per measure: a red measure without a named executive owner produces discussion but not action.
Practitioner checklist
- Write a one-page definition for each board measure: formula, source, owner, thresholds.
- Reconcile the cloud account, subscription and project inventory against billing before the first report.
- Tag crown-jewel data stores and critical workloads so exposure measures can be calculated.
- Use provider posture scores as inputs only, and annotate any scope change on board charts.
- Include non-human identities in privilege and credential measures.
- Keep a tested list of priority cloud attack techniques for the detection coverage measure.
- Run one internal shadow quarter before the first board report.
- Report critical items by exception, whatever the percentages show.
- Review the measure set once a year with the risk committee.
Standards and references
- NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security: Identifying and Selecting Measures
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev 5, Security and Privacy Controls
- AWS: Calculating security scores in Security Hub
- AWS: What is IAM Access Analyzer?
- Google Cloud: Security Command Center overview
- Microsoft Learn: Secure score in Defender for Cloud
- MITRE ATT&CK: Cloud Matrix
Related NHI Mgmt Group resources: Cloud Security Maturity Model · CNAPP and CSPM platform health check · Cloud Identity Health Check · Identity Security Metrics Guide · Cloud Security Glossary