A cloud-native application protection platform (CNAPP) or cloud security posture management (CSPM) tool that looked complete at go-live drifts quietly: new accounts never get connected, suppressions pile up, scans fail without anyone noticing and the backlog of critical findings stops falling. This health check gives you a fixed set of measures to run every quarter, each with a formula, a data source and green, amber and red thresholds, so you can tell whether the platform is still doing the job you bought it for. It is written for the cloud security platform owner, the cloud centre of excellence, security risk and internal audit.
What this health check covers
The check covers the posture side of the platform (configuration scanning against benchmarks and policy), the workload and vulnerability scanning it runs, attack path and toxic combination analysis, and the platform's own administration. It answers one question each quarter: is the platform's view of the cloud estate complete, current and acted upon? It does not explain what a CNAPP is or how to choose one; for that, see the CNAPP Guide. It also does not repeat how to lock down the platform's admin roles, cloud integration roles and remediation permissions; that hardening lives in Securing the CNAPP and CSPM platform itself, and the remediation map below points back to the right section of it.
The difference is simple. The securing guide tells you how the platform should be configured. This health check measures whether, three months later, it still is, and whether the findings it produces are being fixed. Use it as a recurring CSPM audit checklist, as evidence for continuous monitoring under NIST SP 800-53 CA-7, or as the input to a quarterly cloud security posture review with engineering leads.
Key takeaways
- Coverage comes before every other number. A falling share of connected accounts, subscriptions and projects makes every other metric look better than the estate really is, so reconcile it first.
- Scan freshness is a silent failure. An integration role that loses permission keeps showing old findings as if they were current; measure the age of the last successful scan per account.
- Suppressions are the main source of drift. Track active exceptions, their expiry and who approved them, because a growing suppression list hides real exposure.
- Measure closure, not detection. Mean time to remediate and recurrence rate show whether findings are fixed at source or reverted by the next infrastructure-as-code deployment.
- Non-human identities sit in the scorecard. Long-lived cloud access keys and unused workload identities are often the first red finding, and the platform's own integration identities need the same scrutiny.
How to use this template
Copy the metrics table and the findings log into your own tracker, then run this CNAPP and CSPM platform health check at the cadence set out below. Collect each figure from the data sources described, score it against the green, amber and red thresholds, and record every amber or red result as a finding with an owner and a due date. Keep each completed review so you can compare results quarter on quarter: the trend matters as much as any single score.
Cadence and sign-off
Run the full scorecard quarterly. A small subset can run monthly as an operational dashboard, and the annual review adds sample testing and a threshold reset.
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Operational dashboard (metrics CN-01, CN-02, CN-05) | Monthly | Cloud security platform owner | Cloud security lead | Dated exports of account coverage and scan status |
| Quarterly health check (all metrics) | Quarterly | Cloud security platform owner | Head of cloud security or security risk | Scorecard, raw exports, findings log update, sign-off record |
| Annual review | Yearly | Cloud security platform owner with internal audit | CISO | Sample test of 10 findings marked fixed, threshold review, admin role recertification |
| Event-driven check | After a merger, new cloud provider, organisation restructure or platform migration | Cloud centre of excellence | Head of cloud security | Coverage reconciliation and integration test results |
Fix one measurement date per quarter, such as the last working day, and pull every export within one working day of it. People who administer the platform should not be the only signatories on figures about the platform's own admin roles and exceptions, in line with separation of duties (NIST SP 800-53 AC-5).
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. Record the agreed values in the cloud security standard and keep them stable from year to year so trends mean something. "Accounts" below means cloud accounts, subscriptions and projects together.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| CN-01 | Account coverage | Accounts connected to the platform / accounts in the cloud provider organisation inventory | Platform account list; cloud organisation or tenant hierarchy export | 99% or more | 95% to below 99% | Below 95%, or any production account unconnected |
| CN-02 | Scan freshness | Connected accounts with a successful posture scan in the last 24 hours / connected accounts | Platform integration or scan status view | 98% or more | 90% to below 98% | Below 90%, or any account stale for more than 7 days |
| CN-03 | Onboarding lag | Median days from account creation (cloud audit log) to first successful scan, for accounts created in the quarter | Cloud control plane audit logs; platform connection timestamps | 1 day or less | More than 1 day to 7 days | More than 7 days |
| CN-04 | Workload scan coverage | Running compute workloads (virtual machines, containers, serverless functions) with a vulnerability scan in the last 7 days / running workloads in the inventory | Platform workload inventory; cloud asset inventory | 95% or more | 85% to below 95% | Below 85% |
| CN-05 | Critical finding mean time to remediate | Sum of days from first detection to verified closure for critical findings closed in the quarter / number of those findings | Finding history export with first-seen and resolved dates | 7 days or less | More than 7 days to 30 days | More than 30 days |
| CN-06 | SLA adherence by severity | Findings closed within their severity SLA / findings that reached their SLA date in the quarter (report per severity) | Finding history export; ticketing system | 90% or more | 75% to below 90% | Below 75% |
| CN-07 | Recurrence rate | Findings that reopen within 30 days of closure / findings closed in the quarter | Finding history export (status changes) | Below 5% | 5% to 15% | Above 15% |
| CN-08 | Suppression hygiene | Active suppressions or exceptions past their expiry date or with no expiry / active suppressions | Platform exception or suppression register | 0% | Above 0% to 5% | Above 5%, or any suppression on a critical internet-exposed finding without risk acceptance |
| CN-09 | Open toxic combinations | Count of open attack paths that reach sensitive data or an administrative identity, and change from last quarter | Platform attack path or risk graph view | Falling, none older than 30 days | Flat | Rising, or any older than 90 days |
| CN-10 | Benchmark pass rate | Passed controls / evaluated controls for the adopted benchmark, per provider, production accounts only | Compliance or benchmark report export | 95% or more | 85% to below 95% | Below 85% |
| CN-11 | Long-lived cloud credentials | Cloud access keys and service account keys older than 90 days / all such keys in connected accounts | Platform identity or entitlement inventory; cloud credential reports | Below 2% | 2% to 10% | Above 10%, or any such key on an administrative identity |
| CN-12 | Prevention ratio | Policy violations blocked or fixed in pipeline checks / violations first detected in runtime plus those blocked in pipelines | CI system job logs; platform code-scanning results | 40% or more and rising | 20% to below 40%, or 40% or more but not rising | Below 20% |
| CN-13 | Platform admin and integration drift | Platform admin role holders and cloud integration roles not matching the approved baseline / all admin holders and integration roles | Platform audit log; cloud role and policy exports | 0 | Approved changes not yet recorded in baseline | Any unapproved holder or added write permission |
Report every metric with its numerator and denominator, not only the percentage. A 99% coverage figure across 40 accounts is a different story from 99% across 4,000.
A single red privileged finding outweighs a green percentage. An unconnected production account, a key on an administrative identity or an unapproved platform admin is red whatever the overall figure says.
Notes on the harder metrics
- CN-02 scan freshness: a scan that "completed" with permission errors on half its resource types is not successful. Count an account as fresh only if the scan reports no access denied errors for in-scope services.
- CN-05 and CN-06 remediation: measure to verified closure (the next scan no longer sees the issue), not to ticket closure. Report code fixes and console fixes separately, because console fixes are the usual cause of CN-07 recurrence.
- CN-09 toxic combinations: the count depends on the platform's risk model, so do not compare it across platforms or after a major rule update. Note any model change in the findings log.
- CN-10 benchmark pass rate: pick one benchmark per provider (for example the CIS Foundations benchmark for that provider) and one version for the year. Changing benchmark version mid-year resets the trend.
- CN-11 credentials: this measures non-human identity hygiene in the estate the platform watches. See the Cloud Misconfiguration Guide for the wider pattern.
How to collect the data
- Cloud organisation inventory: export the list of accounts, subscriptions and projects from each provider's organisation or tenant hierarchy as the denominator for CN-01. Do not use the platform's own account list as the denominator.
- Platform integration status: export per-account connection state, last successful scan time and any permission errors for CN-02 and CN-03.
- Cloud control plane audit logs: take account creation events for CN-03, and role and policy changes on the platform's integration roles for CN-13.
- Cloud asset inventory: list running compute workloads per account as the denominator for CN-04, and compare with the platform's workload inventory.
- Finding history export: pull raw rows with finding ID, severity, resource, first seen, status changes and resolved date for CN-05, CN-06 and CN-07. Calculate from rows, not dashboard tiles.
- Exception register: export suppressions with scope, approver, reason and expiry for CN-08.
- Attack path view: export open paths with their target type and first-seen date for CN-09.
- Benchmark report: export pass and fail per control for the adopted benchmark for CN-10.
- Identity inventory: pull key age and last-used dates for cloud access keys and service account keys for CN-11.
- CI system job logs: count infrastructure-as-code policy check failures that blocked or changed a merge for CN-12.
- Platform audit log and role exports: list admin role holders and integration role permissions for CN-13, and compare with the approved baseline.
For every red metric, check five to ten records directly in the cloud console or the provider's command line before reporting, so a data quality issue is not reported as a control failure. Keep each export, dated, with the findings log.
Red flags that need action now
- A production account, subscription or project with no connection to the platform.
- Any connected account with no successful scan for more than seven days, which means its findings are out of date.
- A suppression with no expiry covering a public storage bucket, an internet-exposed management port or an administrative identity.
- An attack path from the internet to sensitive data that has stayed open for more than 90 days.
- A cloud access key older than 90 days on an identity with administrative rights.
- Critical findings reopening after closure in the same resources, quarter after quarter, which points to infrastructure-as-code reverting console fixes.
- The platform's integration role holding write or delete permissions that the approved design does not include.
- A platform admin account held by someone who has left or changed role, or a shared admin login.
- Platform audit logs not forwarded to the SIEM, or a gap in forwarding during the quarter. See SIEM health check.
Findings log
Keep one running log across quarters so repeat findings are visible. Escalate anything red for two consecutive quarters to the CISO, and anything that repeats three times to the risk register (NIST SP 800-53 CA-5 Plan of Action and Milestones is the matching control).
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-CNAPP-01 | [n] production accounts created in the quarter not connected | CN-01 | Red | [Cloud centre of excellence] | [Date] | Open |
| HC-CNAPP-02 | Integration role lost read permission in [account]; scans stale for [n] days | CN-02 | Red | [Platform owner] | [Date] | Open |
| HC-CNAPP-03 | [n] suppressions past expiry, including [finding type] | CN-08 | Amber | [Security risk] | [Date] | Open |
| HC-CNAPP-04 | Critical findings in [service] reopen after each deployment | CN-07 | Amber | [Engineering lead] | [Date] | Open |
| HC-CNAPP-05 | [n] access keys older than 90 days, [n] on admin identities | CN-11 | Red | [Cloud identity owner] | [Date] | Open |
Remediation map
| Finding type | Where to fix it |
|---|---|
| Coverage gaps, slow onboarding (CN-01, CN-03) | CNAPP and CSPM platform rollout playbook: connecting accounts at organisation level |
| Stale scans, integration role permission errors (CN-02) | Securing the CNAPP and CSPM platform itself: integration roles in each cloud |
| Expired or unbounded suppressions (CN-08) | Securing the CNAPP and CSPM platform itself: findings exceptions and policy integrity |
| Unapproved admins, added write permissions (CN-13) | Securing the CNAPP and CSPM platform itself: admin roles and console access, and remediation and response guardrails |
| Slow remediation, SLA misses, recurrence (CN-05 to CN-07) | Cloud Security Posture Management (CSPM) Guide: prioritising findings and running remediation at scale |
| Open attack paths (CN-09) | CNAPP Guide: attack path analysis and prioritisation |
| Long-lived keys, unused workload identities (CN-11) | Cloud PAM and CIEM Guide |
| Low benchmark pass rate (CN-10) | CIS Benchmarks Guide |
| Signs the platform itself has been misused | If your CNAPP and CSPM platform is compromised |
Related guides
- Securing the CNAPP and CSPM platform itself: the hardening this check measures against.
- CNAPP Guide: what the platform does, components and programme design.
- CNAPP and CSPM platform maturity model: where the scorecard results place you.
- Security Metrics and KPIs Programme Guide: how to run a metrics programme around checks like this one.
- If your CNAPP and CSPM platform is compromised: response steps when a red flag turns into an incident.
- Cloud Security Guide: the wider cloud security programme.
References
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (CA-5, CA-7, CM-6, CM-8, RA-5, AC-5)
- NIST: SP 800-137 Information Security Continuous Monitoring
- NIST: SP 800-55 Vol. 1 Measurement Guide for Information Security
- NIST: Cybersecurity Framework 2.0 (ID.AM-02, PR.PS-01, DE.CM-09, ID.RA-01)
- CIS: CIS Benchmarks
- CIS: CIS Controls v8.1
- Cloud Security Alliance: Cloud Controls Matrix
Related NHI Mgmt Group resources: Securing the CNAPP and CSPM platform itself, CNAPP Guide, CNAPP and CSPM platform maturity model, Security Metrics and KPIs Programme Guide, If your CNAPP and CSPM platform is compromised, Cloud Security Guide.