docs(compliance): improve cross-provider compliance guide (#12162)

This commit is contained in:
Pedro Martín
2026-07-30 07:59:55 +02:00
committed by GitHub
parent 17f726f816
commit 9b565586da
11 changed files with 298 additions and 159 deletions
+1
View File
@@ -164,6 +164,7 @@
"group": "Compliance",
"pages": [
"user-guide/compliance/tutorials/compliance",
"user-guide/compliance/tutorials/cross-provider-type-compliance",
"user-guide/compliance/tutorials/cross-provider-compliance",
"user-guide/compliance/tutorials/threatscore"
]
Binary file not shown.

After

Width:  |  Height:  |  Size: 191 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 236 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 174 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 155 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 170 KiB

+1
View File
@@ -87,6 +87,7 @@ li[data-title="Prowler MCP"] > button span:first-child::after,
li[data-title="Prowler for AI Agents"] > button span:first-child::after,
div:has(+ ul a[href="/security/encryption"]) h3 span::after,
li[id="/user-guide/compliance/tutorials/cross-provider-compliance"] a > div > div > span:first-child::after,
li[id="/user-guide/compliance/tutorials/cross-provider-type-compliance"] a > div > div > span:first-child::after,
li[id="/user-guide/tutorials/prowler-alerts"] a > div > div > span:first-child::after,
li[id="/user-guide/tutorials/prowler-app-attack-paths-active-queries"] a > div > div > span:first-child::after,
li[id="/user-guide/tutorials/prowler-app-findings-triage"] a > div > div > span:first-child::after,
@@ -4,6 +4,8 @@ sidebarTitle: 'Overview'
description: 'Run security checks against compliance frameworks, review posture across providers, and download CSV or PDF reports from Prowler Cloud and Prowler Local Server, or CSV reports from Prowler CLI.'
---
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
Prowler maps every security check to one or more industry-standard compliance frameworks, so a single scan produces both technical findings and framework-aligned evidence. The same evaluation runs identically whether scans are launched from Prowler Cloud, Prowler Local Server, or Prowler CLI.
Out of the box, Prowler covers frameworks such as CIS Benchmarks, NIST 800-53, NIST CSF, NIS2, ENS RD2022, ISO 27001, PCI-DSS, SOC 2, GDPR, HIPAA, AWS Well-Architected, BSI C5, CSA CCM, MITRE ATT&CK, KISA ISMS-P, FedRAMP, and Prowler ThreatScore. The full catalog is available at [Prowler Hub](https://hub.prowler.com/compliance).
@@ -32,12 +34,17 @@ To open the compliance overview, follow these steps:
1. Sign in to Prowler Cloud at [cloud.prowler.com](https://cloud.prowler.com/sign-in) or to a Prowler Local Server instance.
2. Select **Compliance** from the left navigation.
The page lists every framework evaluated by the most recent completed scan of the selected provider.
The Compliance page is organized into two tabs:
<img src="/images/compliance/prowler-app-compliance-overview.png" alt="Compliance overview page in Prowler Cloud and App showing filters, the Prowler ThreatScore card, and the framework grid" width="900" />
* **Single Scan:** Lists every framework evaluated by one completed scan of one provider. This is the experience described in the rest of this guide, and the default view in Prowler Local Server.
* **Multiple Scans:** Aggregates one framework across several scans at once, either across provider types ([Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance)) or across every provider of the same type ([Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance)).
<SubscriptionBanner label="Multiple Scans tab" />
<img src="/images/compliance/prowler-app-compliance-overview.png" alt="Compliance overview page in Prowler Cloud and Prowler Local Server showing filters, the Prowler ThreatScore card, and the framework grid" width="900" />
<Note>
Compliance results require at least one completed scan. If no scan has finished yet, Prowler Cloud and App display a notice prompting to launch or wait for a scan to complete.
Compliance results require at least one completed scan. If no scan has finished yet, Prowler Cloud and Prowler Local Server display a notice prompting to launch or wait for a scan to complete.
</Note>
### Filtering Compliance Results
@@ -50,7 +57,7 @@ The scan selector lists completed scans across all connected providers. Each ent
#### Region Filter
The region multi-select narrows results to one or more regions detected in the selected scan. Use it to evaluate compliance posture for a specific geography or account boundary. The filter applies to:
The region multi-select narrows results to one or more regions detected in the selected scan. Use it to evaluate compliance posture for a specific geography or regulatory boundary. The filter applies to:
* The framework grid scores and pass/fail counts.
* The detailed requirement view inside each framework.
@@ -145,7 +152,7 @@ Frameworks without a custom layout fall back to the generic details panel, which
### Downloading Compliance Reports
Prowler Cloud and App expose two formats:
Prowler Cloud and Prowler Local Server expose two formats:
* **CSV report:** Every requirement, every check, and every finding for the selected scan and filters. Available for all supported frameworks.
* **PDF report:** Curated executive-style report. Currently supported for Prowler ThreatScore, ENS RD2022, NIS2, and CSA CCM. Additional PDF reports are added in subsequent Prowler releases.
@@ -183,7 +190,7 @@ Use the API to integrate compliance evidence into ticketing systems, executive d
## Prowler CLI
Prowler CLI evaluates the same compliance frameworks as Prowler Cloud and App, and produces detailed CSV outputs alongside the standard scan results. By default, it runs every supported framework and prints a status summary at the end of the scan:
Prowler CLI evaluates the same compliance frameworks as Prowler Cloud and Prowler Local Server, and produces detailed CSV outputs alongside the standard scan results. By default, it runs every supported framework and prints a status summary at the end of the scan:
<img src="/images/cli/compliance/compliance.png" />
@@ -263,6 +270,7 @@ To request a new framework or contribute one, see [Creating a New Security Compl
## Related Documentation
* [Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance)
* [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance)
* [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore)
* [Creating a New Security Compliance Framework in Prowler](/developer-guide/security-compliance-framework)
@@ -1,48 +1,28 @@
---
title: 'Cross-Provider Compliance'
sidebarTitle: 'Cross-Provider Compliance'
description: 'Aggregate a universal compliance framework across compatible providers with completed scans, or a single-provider framework across every provider of one type, review consolidated roll-ups and per-provider breakdowns, and download combined PDF reports.'
description: 'Aggregate a single-provider compliance framework across every provider of the same type, review the consolidated roll-up and per-provider coverage, and download a combined PDF report.'
---
import { VersionBadge } from "/snippets/version-badge.mdx"
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
<VersionBadge version="5.34.0" />
<VersionBadge version="5.37.0" />
Cross-Provider Compliance consolidates a single **universal compliance framework** across your compatible providers with completed scans into one unified view. Instead of reviewing the same framework on AWS, Azure, Google Cloud, and other supported providers as separate reports, Prowler takes the most recent completed scan of every compatible provider, aggregates them by requirement, and produces a single roll-up posture with a per-provider breakdown and a combined executive PDF.
Cross-Provider Compliance aggregates one **single-provider compliance framework** — CIS AWS, CIS GCP, ENS for Azure — across every provider of that type into a single view. It answers the question a per-scan report cannot: **"How compliant is my whole AWS estate against CIS AWS, together?"**
<SubscriptionBanner />
## What Is a Universal Compliance Framework
Most Prowler compliance frameworks target a single provider (for example, CIS AWS or CIS Azure). A **universal** framework declares its requirements once in a single JSON and maps each requirement to checks for many providers at the same time, so the same CSA CCM control maps to both AWS and Azure checks. Universal frameworks live at the top of the compliance catalog (`prowler/compliance/<framework>.json`), as opposed to the legacy per-provider frameworks under `prowler/compliance/<provider>/`. For real definitions, see [`csa_ccm_4.0.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/csa_ccm_4.0.json), [`cis_controls_8.1.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/cis_controls_8.1.json), and [`dora_2022_2554.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/dora_2022_2554.json) in the Prowler repository.
Prowler currently ships three universal frameworks: [CSA CCM](https://hub.prowler.com/compliance/csa_ccm_4.0), [CIS Controls](https://hub.prowler.com/compliance/cis_controls_8.1), and [DORA](https://hub.prowler.com/compliance/dora_2022_2554). Each framework page on Prowler Hub lists the full requirement-to-check mapping per provider.
This view is the sibling of [Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance), which aggregates a *universal* framework across different provider types. Both live in the **Multiple Scans** tab and share the same roll-up rules, scan selection, and report flow. Only the column axis changes, from provider type to individual provider.
## How Cross-Provider Compliance Works
Cross-Provider Compliance uses this structure to answer a single question: **"How compliant is my whole estate against this framework, regardless of provider?"** For a chosen universal framework, Prowler Cloud:
For a chosen framework and provider type, Prowler Cloud:
1. Selects **one scan per compatible provider**: by default, the latest completed scan of each provider the framework supports and that you are allowed to see.
2. Aggregates the requirement results across those scans, folding multiple accounts of the same provider type together.
3. Computes a **roll-up status** for each requirement and an overall pass / fail / manual summary for the framework.
4. Exposes a **per-provider breakdown** so you can see exactly which provider is failing a given control.
<Note>
Cross-Provider Compliance never mixes different frameworks. It aggregates one universal framework at a time across providers. To review a single provider in isolation, use the standard per-scan [Compliance](/user-guide/compliance/tutorials/compliance) view.
</Note>
### Supported Universal Frameworks
The Cross-Provider Compliance view currently supports the following universal frameworks. The compatible providers are the ones each framework declares checks for; a provider only contributes to the roll-up when it has a completed scan.
| Framework | Version | Compatible providers |
|-----------|---------|----------------------|
| [**CSA CCM**](https://hub.prowler.com/compliance/csa_ccm_4.0) (Cloud Controls Matrix) | 4.0 | AWS, Azure, Google Cloud, Alibaba Cloud, Oracle Cloud |
| [**CIS Controls**](https://hub.prowler.com/compliance/cis_controls_8.1) | 8.1 | AWS, Azure, Google Cloud, Microsoft 365, Kubernetes, GitHub, Google Workspace, Okta, Oracle Cloud, Alibaba Cloud, Cloudflare, MongoDB Atlas, OpenStack, Vercel |
| [**DORA**](https://hub.prowler.com/compliance/dora_2022_2554) (Digital Operational Resilience Act) | 2022/2554 | AWS, Azure, Google Cloud, Alibaba Cloud, Cloudflare |
The catalog grows as new universal frameworks ship in Prowler. Browse the full compliance catalog at [Prowler Hub](https://hub.prowler.com/compliance).
1. Selects **one scan per provider**: the latest completed scan of every provider of that type you are allowed to see.
2. Aggregates the requirement results across those scans.
3. Computes a **roll-up status** for each requirement and an overall pass / fail / manual summary.
4. Exposes a **per-provider breakdown** so a failing provider is immediately attributable.
## Accessing the Cross-Provider View
@@ -50,86 +30,76 @@ The catalog grows as new universal frameworks ship in Prowler. Browse the full c
<Step title="Open the Compliance section">
Sign in to Prowler Cloud at [cloud.prowler.com](https://cloud.prowler.com/sign-in) and select **Compliance** from the left navigation.
</Step>
<Step title="Switch to the Multiple Scans tab">
At the top of the Compliance page, select the **Multiple Scans** tab. The **Single Scan** tab (the default) keeps the single-provider compliance experience unchanged.
<Step title="Open the Multiple Scans tab">
**Multiple Scans** is the landing tab of the Compliance page in Prowler Cloud. Scroll to the **Across providers** section, below the **Across provider types** cards.
</Step>
<Step title="Expand a provider type">
Each provider type is a collapsible group headed by its counts (frameworks available and providers registered). Expanding it reveals one card per single-provider framework available for that type.
</Step>
</Steps>
<img src="/images/compliance/prowler-app-cross-provider-tab.png" alt="Compliance page showing the Single Scan and Multiple Scans tabs, with the Multiple Scans tab highlighted" width="900" />
<img src="/images/compliance/prowler-app-compliance-multiple-scans.png" alt="Multiple Scans tab showing the Across provider types cards and the Across providers section, with the AWS group collapsed and its framework and provider counts" width="900" />
<Note>
The **Across provider types** section requires at least one completed scan for a provider compatible with a universal framework. If none is available, that section shows a notice prompting you to launch or wait for a scan to complete. The **Across providers** section can still list single-provider frameworks when its own account and scan requirements are met.
A provider type appears only when it has two or more providers registered **and** at least one of them has a completed scan: that scan is where the framework catalog of the provider type is read from. With a single provider the aggregation is identical to the standard per-scan [Compliance](/user-guide/compliance/tutorials/compliance) view.
</Note>
## Exploring the Overview
Framework cards in this section carry no score: they enumerate which frameworks can be aggregated for a provider type, and the roll-up numbers are computed on the detail page. Two catalogs stay out of the section, because each already has its own view:
The Multiple Scans tab is organized into two sections, each labeled with the axis it aggregates across:
* **Universal frameworks:** Aggregated in the **Across provider types** section above. See [Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance).
* **Prowler ThreatScore:** Reviewed per scan in the **Single Scan** tab. See [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore).
* **Across provider types:** One card per supported universal framework, aggregating every compatible provider type. This is the Cross-Provider Compliance experience described in the rest of this guide.
* **Across providers:** One card per single-provider framework (for example, CIS AWS) that can be aggregated across every connected provider of the same type. See [Aggregating a Single-Provider Framework Across Providers](#aggregating-a-single-provider-framework-across-providers).
<img src="/images/compliance/prowler-app-across-providers-expanded.png" alt="Across providers section with the AWS group expanded, showing one card per single-provider framework with its View across providers link and provider count" width="900" />
The **Across provider types** section presents one card per supported universal framework, each summarizing the consolidated posture across every contributing provider.
## Which Providers Are Listed and Which Contribute
<img src="/images/compliance/prowler-app-cross-provider-overview.png" alt="Cross-Provider Compliance overview showing the provider filters and the framework grid (CSA CCM, CIS Controls, DORA) with per-provider chips, scores, and failed/manual counts" width="900" />
The **Across providers** section and the detail page count different things, so their numbers often differ:
Each **framework card** includes:
* The section describes your **catalog**: the group header and each framework card report how many providers of that type exist in Prowler Cloud, after the filters you applied.
* The detail page describes your **evidence**: only providers with a completed scan become a column in the aggregation, because every number on that page is computed from scan results.
* **Framework logo, name, and version:** Identifies the universal standard (CSA CCM, CIS Controls, DORA).
* **Score:** The percentage of passing requirements over the total evaluated, aggregated across every contributing provider. Color coding follows three thresholds: red for severely low compliance, amber for partial compliance, and green for healthy posture.
* **Passing Requirements:** A `passed / total` counter with the aggregated roll-up.
* **Provider chips:** One icon per compatible provider. Providers with a completed scan appear active with their passing percentage; providers without a scan appear dimmed with a "no completed scan yet" tooltip so coverage gaps are obvious at a glance.
* **Failed and manual counts:** The number of failing and manual requirements in the roll-up.
A card can therefore read `17 providers` while its detail page reports two providers aggregated from two scans. The other 15 providers exist in Prowler Cloud but have no completed scan, so there is nothing of theirs to aggregate. This is the expected state right after onboarding an AWS Organization: the discovery wizard registers every member it finds in the organization as a provider, and providers not scanned yet count toward the catalog while contributing nothing to the roll-up. See [AWS Organizations](/user-guide/tutorials/prowler-cloud-aws-organizations) for that onboarding flow.
Select any card to open the framework detail page.
What decides whether a provider contributes is **having a completed scan**, not its connection status:
### Filtering the Roll-Up
* **Completed scans only:** Failed, cancelled, and in-progress scans are ignored, so a provider whose latest scan is still running keeps contributing its previous completed one.
* **Disconnected providers still count:** A provider whose credentials stopped working contributes its last completed scan. The posture it shows is as old as that scan.
* **Newly connected providers do not:** A provider contributes nothing until its first scan completes.
The filters bar controls which providers and accounts feed every card and detail view. Cross-Provider Compliance supports three filters:
To confirm which providers made it into an aggregation, read the coverage summary in the detail page header and the coverage card, which lists one row per contributing provider.
* **Provider type:** Narrow the roll-up to specific provider types (for example, only AWS and Azure).
* **Provider / account:** Narrow to specific connected accounts.
* **Provider group:** Narrow to accounts within one or more provider groups.
Select **Clear filters** to reset all filters. Filters applied on the overview are carried through into the detail page and the PDF report so the view stays consistent end to end.
<Note>
Filters narrow **which providers contribute** to the aggregation. They do not change how a requirement rolls up (see [Understanding the Roll-Up Status](#understanding-the-roll-up-status)).
</Note>
<Warning>
The **Providers** filter on the detail page lists every provider of the type, including ones that have never been scanned. Narrowing to providers with no completed scan leaves the view with no evidence to aggregate: the coverage card reports nothing scanned, requirements show no per-provider status, and any report generated for that selection is empty. Clear the filter or select providers that have already been scanned.
</Warning>
## Working With the Framework Detail Page
The detail page provides the full breakdown for a single universal framework: aggregate metrics, provider coverage, top failing sections, and a requirement-by-requirement view with per-provider status.
Selecting a card opens a detail page with the same layout as the cross-provider-type detail, with the column axis swapped from provider type to provider:
<img src="/images/compliance/prowler-app-cross-provider-detail.png" alt="Cross-Provider Compliance detail page for CSA CCM 4.0 showing the header with providers scanned and the Report button, the filters, and the Requirements Status, Provider Coverage, and Top Failed Sections summary cards" width="900" />
* **Header:** States the framework, the provider type, and the real coverage behind the numbers, as a count of aggregated providers and scans. The **Report** button generates the combined PDF.
* **Requirements Status:** Donut chart with the consolidated `Pass`, `Fail`, and `Manual` counts.
* **Coverage card:** Ranks each contributing provider's individual posture, so the weakest one is visible at a glance. Every row is one provider of the type, labeled with its alias and unique identifier (UID).
* **Top Failed Sections:** Ranks the framework sections with the most failing requirements, with deep links into the requirements accordion.
* **Requirements accordion:** Each requirement shows its roll-up badge plus the status of every contributing provider, labeled with the provider alias and unique identifier (UID). With one or two providers the statuses appear as inline chips; from three onwards the row condenses into per-status counts (for example, `Fail ×3 Pass ×6`), and selecting the counts opens the full provider-by-provider breakdown. Expanding a requirement queries the findings of every contributing scan and merges them into a single table.
### Header
<img src="/images/compliance/prowler-app-across-providers-detail.png" alt="Cross-Provider Compliance detail page for CIS AWS 7.0 showing the header with the aggregated providers and scans, the Report button, the Providers and Provider group filters, and the Requirements Status, coverage, and Top Failed Sections cards above the requirements accordion" width="900" />
The header shows the framework name and version, a link to the framework page on [Prowler Hub](https://hub.prowler.com/compliance), and a summary such as *"X of Y compatible providers scanned · N scans aggregated"* so you always know the coverage behind the numbers. The **Report** button in the top-right generates and downloads the combined PDF (see [Downloading the Combined PDF Report](#downloading-the-combined-pdf-report)).
<Note>
Checks are not labeled per provider type as in the cross-provider-type view. Every provider of the same type shares one check set, so a single list of checks covers the whole aggregation.
</Note>
### Summary Cards
### Filtering the Roll-Up
Below the header, three summary cards condense the framework state:
Two filters control which providers feed the aggregation:
* **Requirements Status:** Donut chart with `Pass`, `Fail`, and `Manual` counts plus the total number of requirements, reflecting the consolidated roll-up.
* **Provider Coverage:** Shows which compatible providers contributed a scan and their individual posture, so coverage gaps and per-provider weak spots are visible at a glance.
* **Top Failed Sections:** Ranks the framework sections with the highest number of failing requirements, with deep links into the requirements accordion.
* **Providers:** Narrow to specific providers of the type, listed by alias and UID.
* **Provider group:** Narrow to the providers belonging to one or more provider groups.
### Requirements Accordion
The accordion organizes every requirement of the framework. For each requirement you see:
* **Requirement ID and title:** The official identifier from the framework.
* **Roll-up status badge:** A single `Pass`, `Fail`, or `Manual` badge representing the consolidated status across all contributing providers.
* **Per-provider status:** The status each contributing provider returned for that requirement, so a single failing provider is immediately attributable.
* **Provider-labeled checks:** When you expand a requirement, the underlying checks are labeled with the provider they belong to (each universal requirement maps to different check IDs per provider).
Expand a requirement to review the failing checks per provider, the affected resources, and remediation guidance. Findings are queried across every contributing scan and merged into a single table.
<img src="/images/compliance/prowler-app-cross-provider-requirements-accordion.png" alt="Expanded DORA requirement showing the per-provider Fail badges for AWS, Azure, and Google Cloud, the requirement description and attributes, the checks count, and the merged findings table with a Provider column" width="900" />
The provider type is fixed by the framework, so there is no type filter here. Filters applied on the overview carry through into the detail page and the PDF report.
## Understanding the Roll-Up Status
Cross-Provider Compliance rolls up results in two stages, with a strict **FAIL > PASS > MANUAL** precedence.
Results roll up in two stages, with a strict **FAIL > PASS > MANUAL** precedence.
**Per provider, per requirement:**
@@ -137,8 +107,6 @@ Cross-Provider Compliance rolls up results in two stages, with a strict **FAIL >
* Else if every check passes → **PASS**.
* Otherwise (no pass/fail evidence) → **MANUAL**.
Multiple accounts of the same provider type (for example, three AWS accounts) are folded together first, so a failure in any one account marks that provider type as failing.
**Across providers, per requirement (the roll-up badge):**
* If at least one contributing provider is **FAIL** → the requirement is **FAIL**.
@@ -146,90 +114,26 @@ Multiple accounts of the same provider type (for example, three AWS accounts) ar
* Otherwise → **MANUAL**.
<Note>
Only providers that **actually contributed a result** for a requirement are counted. A provider that has a scan in the aggregation but produced no result for a specific requirement (for example, because the framework maps no checks to that provider for that control) does **not** degrade the requirement to Manual. This keeps the roll-up focused on real evidence.
Only providers that **actually contributed a result** for a requirement are counted. A provider whose scan produced no result for a specific requirement does not degrade that requirement to Manual, which keeps the roll-up focused on real evidence.
</Note>
### How Scans Are Selected
By default, Cross-Provider Compliance auto-selects the **latest completed scan** of each compatible provider you are allowed to see. This means:
* The view always reflects your most recent posture per provider, without any manual scan selection.
* Adding a new compatible provider and running a scan automatically brings it into the roll-up.
* Provider visibility follows your role: you only ever see providers your permissions allow, and the roll-up is scoped accordingly.
Scan selection and permission scoping match the cross-provider-type view: the aggregation always reflects each provider's most recent completed scan, restricted to the providers your role is allowed to see. To review how provider visibility is granted, see [Role-Based Access Control (RBAC)](/user-guide/tutorials/prowler-app-rbac).
## Downloading the Combined PDF Report
The **Report** button on the detail page generates a single PDF that combines every contributing provider's latest scan for the framework into one executive document: a cover page listing all providers and accounts, an executive summary with the consolidated roll-up, charts, a requirements index, and detailed findings grouped by requirement, provider, and account.
The **Report** button produces a single PDF across every contributing provider of the type: a cover page listing the providers, an executive summary with the consolidated roll-up, charts, a requirements index, and detailed findings grouped by requirement and provider.
### The Report Follows Your Filters
<img src="/images/compliance/prowler-app-across-providers-report.png" alt="Report dropdown on the Cross-Provider Compliance detail page showing the Generate new report option" width="420" />
A report covers the exact set of scans your current filters resolve to. The provider type, provider / account, and provider group filters applied on the detail page determine which providers contribute, and the auto-select rule pins each contributing provider's latest completed scan. The PDF is built from that resolved scan set together with the framework.
As a result, each filter combination produces its own report. For example:
* No filters → a report covering every compatible provider that has a completed scan.
* `Provider type = AWS, Azure` → a report covering only your AWS and Azure scans.
* `Provider group = Production` → a report covering only the accounts in that group.
Changing the filters and generating again produces a different, independent report. Each combination is tracked on its own, so switching filters back and forth never overwrites a previously generated report.
Generation is asynchronous and behaves exactly like the cross-provider-type report — background job, toast notification when ready, and **Report → Download latest** to reuse a report already generated for the current filters. See [Downloading the Combined PDF Report](/user-guide/compliance/tutorials/cross-provider-type-compliance#downloading-the-combined-pdf-report) for the full flow, including report reuse and the findings cap.
<Note>
Region filtering is **not** supported for the combined PDF report. The report recomputes status live across every region of the contributing scans, so a region-scoped request is rejected rather than producing a report that contradicts a region-filtered view.
A report is tied to the exact set of scans it was built from. When any contributing provider completes a new scan, the previous report no longer matches the current selection and Prowler Cloud offers to generate an up-to-date one.
</Note>
### Generating and Reusing a Report
Because the report aggregates many scans, it is generated **asynchronously**:
<Steps>
<Step title="Start the report">
Select **Report → Generate new report…**, optionally give it a name, and confirm. Prowler starts a background job and shows a "Report generation started" confirmation.
</Step>
<Step title="Wait for completion">
The button shows a "Generating report…" state while the job runs. Generation continues in the background: you can navigate away, and a toast notification appears when the report is ready, even after a page reload.
</Step>
<Step title="Download">
When the report is ready, select **Download** from the notification, or use **Report → Download latest** at any time to fetch the most recent report for the current filters.
</Step>
</Steps>
<img src="/images/compliance/prowler-app-cross-provider-report.png" alt="Report dropdown on the Cross-Provider Compliance detail page showing the Generate new report option" width="420" />
A report already generated for a given set of filters does not need to be generated again. When you open the detail page with a filter combination that was reported before, Prowler detects the existing report and surfaces **Report → Download latest** so you can download it immediately, without launching a new job. You only need to generate a fresh report when:
* You apply a filter combination that has never been reported before, or
* A contributing provider has completed a new scan since the report was generated. The report is tied to the specific scans it was built from, so a newer completed scan makes the previous report stale; Prowler recognizes it no longer matches the current selection and offers to generate an up-to-date one.
"Download latest" reuses an existing report only when it matches the framework, the exact resolved scan set for the current filters, and the same report options. This guarantees the PDF you download reflects the posture you are looking at, rather than a report generated for a different filter or an older scan.
<Note>
The PDF detail section renders only **failed** requirements by default so the report stays focused as an executive/auditor document. As with every Prowler PDF, the detail section is capped at the first 100 failed findings per check; use the per-scan CSV or JSON-OCSF exports for the complete, untruncated list. See [Downloading Compliance Reports](/user-guide/compliance/tutorials/compliance#downloading-compliance-reports) for the full PDF behavior and the `DJANGO_PDF_MAX_FINDINGS_PER_CHECK` setting.
</Note>
## Aggregating a Single-Provider Framework Across Providers
Universal frameworks answer the cross-provider-type question, but most compliance frameworks target a single provider type — CIS AWS, CIS GCP, ENS for Azure. The **Across providers** section of the Multiple Scans tab answers the sibling question for those frameworks: **"How compliant are all of my AWS accounts against CIS AWS, together?"**
For every provider type with **two or more connected providers**, the section shows a collapsible group headed by the provider type and its counts (frameworks available and providers connected). Expanding a group reveals one card per single-provider framework available for that type, keeping the section compact even when several multi-provider types are connected. Selecting a card opens a detail page with the same layout as the cross-provider detail, with the column axis swapped from provider type to provider:
* **One column per provider:** Prowler auto-selects the latest completed scan of every provider of that type you are allowed to see, and each requirement shows a status chip per provider (labeled with its alias or account ID).
* **Account Coverage:** The coverage card ranks each provider's individual posture so the weakest account is visible at a glance.
* **Filters:** Narrow the aggregation to specific providers or provider groups. The provider type is fixed by the framework, so there is no type filter here.
* **Findings drill-down:** Expanding a requirement queries the findings of every contributing provider's scan and merges them into a single table.
The roll-up rules are identical to the cross-provider ones (**FAIL > PASS > MANUAL**, only providers that contributed a result count), applied per provider instead of per provider type. Scan selection, RBAC scoping, and staleness behavior also match: the view always reflects each provider's most recent completed scan, scoped to your role's visibility.
<Note>
Provider types with a single connected provider are not listed — with one provider the aggregation is identical to the standard per-scan [Compliance](/user-guide/compliance/tutorials/compliance) view.
</Note>
### Cross-Account PDF Report
The detail page's **Report** button produces a single combined PDF across every contributing provider of the type, with the same asynchronous generation, background notification, and **Download latest** reuse flow as the [cross-provider report](#downloading-the-combined-pdf-report). The report is tied to the exact resolved scan set, so a new completed scan in any contributing provider makes the previous report stale and Prowler offers to generate an up-to-date one.
## Related Documentation
* [Cross-Provider Type Compliance](/user-guide/compliance/tutorials/cross-provider-type-compliance)
* [Compliance](/user-guide/compliance/tutorials/compliance)
* [AWS Organizations](/user-guide/tutorials/prowler-cloud-aws-organizations)
* [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore)
* [Creating a New Security Compliance Framework in Prowler](/developer-guide/security-compliance-framework)
* [Prowler Cloud — Getting Started](/user-guide/tutorials/prowler-app)
@@ -0,0 +1,225 @@
---
title: 'Cross-Provider Type Compliance'
sidebarTitle: 'Cross-Provider Type Compliance'
description: 'Aggregate a universal compliance framework across every compatible provider with a completed scan, review the consolidated roll-up and per-provider breakdown, and download a combined PDF report.'
---
import { VersionBadge } from "/snippets/version-badge.mdx"
import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
<VersionBadge version="5.34.0" />
Cross-Provider Type Compliance consolidates a single **universal compliance framework** across your compatible providers with completed scans into one unified view. Instead of reviewing the same framework on AWS, Azure, Google Cloud, and other supported providers as separate reports, Prowler takes the most recent completed scan of every compatible provider, aggregates them by requirement, and produces a single roll-up posture with a per-provider breakdown and a combined executive PDF.
<SubscriptionBanner />
## What Is a Universal Compliance Framework
Most Prowler compliance frameworks target a single provider (for example, CIS AWS or CIS Azure). A **universal** framework declares its requirements once in a single JSON and maps each requirement to checks for many providers at the same time, so the same CSA CCM control maps to both AWS and Azure checks. Universal frameworks live at the top of the compliance catalog (`prowler/compliance/<framework>.json`), as opposed to the legacy per-provider frameworks under `prowler/compliance/<provider>/`. For real definitions, see [`csa_ccm_4.0.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/csa_ccm_4.0.json), [`cis_controls_8.1.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/cis_controls_8.1.json), and [`dora_2022_2554.json`](https://github.com/prowler-cloud/prowler/blob/master/prowler/compliance/dora_2022_2554.json) in the Prowler repository.
Prowler currently ships three universal frameworks: [CSA CCM](https://hub.prowler.com/compliance/csa_ccm_4.0), [CIS Controls](https://hub.prowler.com/compliance/cis_controls_8.1), and [DORA](https://hub.prowler.com/compliance/dora_2022_2554). Each framework page on Prowler Hub lists the full requirement-to-check mapping per provider.
## How Cross-Provider Type Compliance Works
Cross-Provider Type Compliance uses this structure to answer a single question: **"How compliant is my whole estate against this framework, regardless of provider?"** For a chosen universal framework, Prowler Cloud:
1. Selects **one scan per compatible provider**: by default, the latest completed scan of each provider the framework supports and that you are allowed to see.
2. Aggregates the requirement results across those scans, folding multiple providers of the same type together.
3. Computes a **roll-up status** for each requirement and an overall pass / fail / manual summary for the framework.
4. Exposes a **per-provider breakdown** so you can see exactly which provider is failing a given control.
<Note>
Cross-Provider Type Compliance never mixes different frameworks. It aggregates one universal framework at a time across providers. To review a single provider in isolation, use the standard per-scan [Compliance](/user-guide/compliance/tutorials/compliance) view.
</Note>
### Supported Universal Frameworks
The Cross-Provider Type Compliance view currently supports the following universal frameworks. The compatible providers are the ones each framework declares checks for; a provider only contributes to the roll-up when it has a completed scan.
| Framework | Version | Compatible providers |
|-----------|---------|----------------------|
| [**CSA CCM**](https://hub.prowler.com/compliance/csa_ccm_4.0) (Cloud Controls Matrix) | 4.0 | AWS, Azure, Google Cloud, Alibaba Cloud, Oracle Cloud |
| [**CIS Controls**](https://hub.prowler.com/compliance/cis_controls_8.1) | 8.1 | AWS, Azure, Google Cloud, Microsoft 365, Kubernetes, GitHub, Google Workspace, Okta, Oracle Cloud, Alibaba Cloud, Cloudflare, MongoDB Atlas, OpenStack, Vercel |
| [**DORA**](https://hub.prowler.com/compliance/dora_2022_2554) (Digital Operational Resilience Act) | 2022/2554 | AWS, Azure, Google Cloud, Alibaba Cloud, Cloudflare |
The catalog grows as new universal frameworks ship in Prowler. Browse the full compliance catalog at [Prowler Hub](https://hub.prowler.com/compliance).
## Accessing the Cross-Provider Type View
<Steps>
<Step title="Open the Compliance section">
Sign in to Prowler Cloud at [cloud.prowler.com](https://cloud.prowler.com/sign-in) and select **Compliance** from the left navigation.
</Step>
<Step title="Open the Multiple Scans tab">
In Prowler Cloud, **Multiple Scans** is the landing tab of the Compliance page, so it opens already selected. Select **Single Scan** at the top of the page to return to the per-scan compliance experience, which remains unchanged.
</Step>
</Steps>
<Note>
The **Across provider types** section requires at least one completed scan for a provider compatible with a universal framework. If none is available, that section shows a notice prompting you to launch or wait for a scan to complete. The **Across providers** section below it has its own requirements — see [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance).
</Note>
## Exploring the Overview
The Multiple Scans tab is organized into two sections, each labeled with the axis it aggregates across:
* **Across provider types:** One card per supported universal framework, aggregating every compatible provider type. This is the Cross-Provider Type Compliance experience described in the rest of this guide.
* **Across providers:** One card per single-provider framework (for example, CIS AWS) that can be aggregated across every provider of the same type. See [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance).
The **Across provider types** section presents one card per supported universal framework, each summarizing the consolidated posture across every contributing provider.
<img src="/images/compliance/prowler-app-compliance-multiple-scans.png" alt="Multiple Scans tab showing the provider filters, the Across provider types grid (CSA CCM, CIS Controls, DORA) with per-provider chips, scores, and failed and manual counts, and the Across providers section below it" width="900" />
Each **framework card** includes:
* **Framework logo, name, and version:** Identifies the universal standard (CSA CCM, CIS Controls, DORA).
* **Score:** The percentage of passing requirements over the total evaluated, aggregated across every contributing provider. Color coding follows three thresholds: red for severely low compliance, amber for partial compliance, and green for healthy posture.
* **Passing Requirements:** A `passed / total` counter with the aggregated roll-up.
* **Provider chips:** One icon per compatible provider. Providers with a completed scan appear active with their passing percentage; providers without a scan appear dimmed with a "no completed scan yet" tooltip so coverage gaps are obvious at a glance.
* **Failed and manual counts:** The number of failing and manual requirements in the roll-up.
Select any card to open the framework detail page.
### Filtering the Roll-Up
The filters bar controls which providers feed every card and detail view. Cross-Provider Type Compliance supports three filters:
* **Provider type:** Narrow the roll-up to specific provider types (for example, only AWS and Azure).
* **Providers:** Narrow to specific providers, listed by alias and unique identifier (UID).
* **Provider group:** Narrow to the providers belonging to one or more provider groups.
Select **Clear filters** to reset all filters. Filters applied on the overview are carried through into the detail page and the PDF report so the view stays consistent end to end.
<Note>
Filters narrow **which providers contribute** to the aggregation. They do not change how a requirement rolls up (see [Understanding the Roll-Up Status](#understanding-the-roll-up-status)).
</Note>
## Working With the Framework Detail Page
The detail page provides the full breakdown for a single universal framework: aggregate metrics, provider coverage, top failing sections, and a requirement-by-requirement view with per-provider status.
<img src="/images/compliance/prowler-app-cross-provider-detail.png" alt="Cross-Provider Type Compliance detail page for CSA CCM 4.0 showing the header with providers scanned and the Report button, the filters, and the Requirements Status, Provider Coverage, and Top Failed Sections summary cards" width="900" />
### Header
The header shows the framework name and version, a link to the framework page on [Prowler Hub](https://hub.prowler.com/compliance), and a summary such as *"X of Y compatible providers scanned · N scans aggregated"* so you always know the coverage behind the numbers. The **Report** button in the top-right generates and downloads the combined PDF (see [Downloading the Combined PDF Report](#downloading-the-combined-pdf-report)).
### Summary Cards
Below the header, three summary cards condense the framework state:
* **Requirements Status:** Donut chart with `Pass`, `Fail`, and `Manual` counts plus the total number of requirements, reflecting the consolidated roll-up.
* **Provider Coverage:** Shows which compatible providers contributed a scan and their individual posture, so coverage gaps and per-provider weak spots are visible at a glance.
* **Top Failed Sections:** Ranks the framework sections with the highest number of failing requirements, with deep links into the requirements accordion.
### Requirements Accordion
The accordion organizes every requirement of the framework. For each requirement you see:
* **Requirement ID and title:** The official identifier from the framework.
* **Roll-up status badge:** A single `Pass`, `Fail`, or `Manual` badge representing the consolidated status across all contributing providers.
* **Per-provider status:** The status each contributing provider returned for that requirement, so a single failing provider is immediately attributable. Up to five providers are shown as inline chips; beyond that the row condenses into per-status counts (for example, `Fail ×3 Pass ×6`), and selecting the counts opens the full provider-by-provider breakdown.
* **Provider-labeled checks:** When you expand a requirement, the underlying checks are labeled with the provider they belong to (each universal requirement maps to different check IDs per provider).
Expand a requirement to review the failing checks per provider, the affected resources, and remediation guidance. Findings are queried across every contributing scan and merged into a single table.
<img src="/images/compliance/prowler-app-cross-provider-requirements-accordion.png" alt="Expanded DORA requirement showing the per-provider Fail badges for AWS, Azure, and Google Cloud, the requirement description and attributes, the checks count, and the merged findings table with a Provider column" width="900" />
## Understanding the Roll-Up Status
Cross-Provider Type Compliance rolls up results in two stages, with a strict **FAIL > PASS > MANUAL** precedence.
**Per provider, per requirement:**
* If any check fails → the provider contributes **FAIL** for that requirement.
* Else if every check passes → **PASS**.
* Otherwise (no pass/fail evidence) → **MANUAL**.
Multiple providers of the same type (for example, three AWS providers) are folded together first, so a failure in any one of them marks that provider type as failing.
**Across providers, per requirement (the roll-up badge):**
* If at least one contributing provider is **FAIL** → the requirement is **FAIL**.
* Else if at least one contributing provider is **PASS** → **PASS**.
* Otherwise → **MANUAL**.
<Note>
Only providers that **actually contributed a result** for a requirement are counted. A provider that has a scan in the aggregation but produced no result for a specific requirement (for example, because the framework maps no checks to that provider for that control) does **not** degrade the requirement to Manual. This keeps the roll-up focused on real evidence.
</Note>
### How Scans Are Selected
By default, Cross-Provider Type Compliance auto-selects the **latest completed scan** of each compatible provider you are allowed to see. This means:
* The view always reflects your most recent posture per provider, without any manual scan selection.
* Adding a new compatible provider and running a scan automatically brings it into the roll-up.
* Provider visibility follows your role: only the providers your permissions allow are ever shown, and the roll-up is scoped accordingly. See [Role-Based Access Control (RBAC)](/user-guide/tutorials/prowler-app-rbac).
What makes a provider contribute is **having a completed scan**, not its current connection status:
* Only scans in the **completed** state are eligible. Failed, cancelled, and in-progress scans are ignored, so a provider whose latest scan is still running keeps contributing its previous completed one.
* A provider whose credentials stopped working still contributes its last completed scan. The posture it shows is as old as that scan.
* A provider connected but never scanned contributes nothing until its first scan completes. On the framework cards it appears dimmed instead of disappearing, so the coverage gap stays visible.
## Downloading the Combined PDF Report
The **Report** button on the detail page generates a single PDF that combines every contributing provider's latest scan for the framework into one executive document: a cover page listing every contributing provider, an executive summary with the consolidated roll-up, charts, a requirements index, and detailed findings grouped by requirement and provider.
### The Report Follows Your Filters
A report covers the exact set of scans your current filters resolve to. The provider type, providers, and provider group filters applied on the detail page determine which providers contribute, and the auto-select rule pins each contributing provider's latest completed scan. The PDF is built from that resolved scan set together with the framework.
As a result, each filter combination produces its own report. For example:
* No filters → a report covering every compatible provider that has a completed scan.
* `Provider type = AWS, Azure` → a report covering only your AWS and Azure scans.
* `Provider group = Production` → a report covering only the providers in that group.
Changing the filters and generating again produces a different, independent report. Each combination is tracked on its own, so switching filters back and forth never overwrites a previously generated report.
<Note>
Region filtering is **not** supported for the combined PDF report. The report recomputes status live across every region of the contributing scans, so a region-scoped request is rejected rather than producing a report that contradicts a region-filtered view.
</Note>
### Generating and Reusing a Report
Because the report aggregates many scans, it is generated **asynchronously**:
<Steps>
<Step title="Start the report">
Select **Report → Generate new report…**, optionally give it a name, and confirm. Prowler starts a background job and shows a "Report generation started" confirmation.
</Step>
<Step title="Wait for completion">
The button shows a "Generating report…" state while the job runs. Generation continues in the background: you can navigate away, and a toast notification appears when the report is ready, even after a page reload.
</Step>
<Step title="Download">
When the report is ready, select **Download** from the notification, or use **Report → Download latest** at any time to fetch the most recent report for the current filters.
</Step>
</Steps>
<img src="/images/compliance/prowler-app-cross-provider-report.png" alt="Report dropdown on the Cross-Provider Type Compliance detail page showing the Generate new report option" width="420" />
A report already generated for a given set of filters does not need to be generated again. When you open the detail page with a filter combination that was reported before, Prowler detects the existing report and surfaces **Report → Download latest** so you can download it immediately, without launching a new job. You only need to generate a fresh report when:
* You apply a filter combination that has never been reported before, or
* A contributing provider has completed a new scan since the report was generated. The report is tied to the specific scans it was built from, so a newer completed scan makes the previous report stale; Prowler recognizes it no longer matches the current selection and offers to generate an up-to-date one.
"Download latest" reuses an existing report only when it matches the framework, the exact resolved scan set for the current filters, and the same report options. This guarantees the PDF you download reflects the posture you are looking at, rather than a report generated for a different filter or an older scan.
<Note>
The PDF detail section renders only **failed** requirements by default so the report stays focused as an executive/auditor document. As with every Prowler PDF, the detail section is capped at the first 100 failed findings per check; use the per-scan CSV or JSON-OCSF exports for the complete, untruncated list. See [Downloading Compliance Reports](/user-guide/compliance/tutorials/compliance#downloading-compliance-reports) for the full PDF behavior and the `DJANGO_PDF_MAX_FINDINGS_PER_CHECK` setting.
</Note>
## Aggregating a Single-Provider Framework Across Providers
Universal frameworks answer the cross-provider-type question, but most compliance frameworks target a single provider type — CIS AWS, CIS GCP, ENS for Azure. The **Across providers** section of the Multiple Scans tab answers the sibling question for those frameworks: **"How compliant is my whole AWS estate against CIS AWS, together?"**
The aggregation works the same way, with the column axis swapped from provider type to individual provider, and it produces its own combined PDF report. See [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance) for the full guide.
## Related Documentation
* [Cross-Provider Compliance](/user-guide/compliance/tutorials/cross-provider-compliance)
* [Compliance](/user-guide/compliance/tutorials/compliance)
* [Prowler ThreatScore](/user-guide/compliance/tutorials/threatscore)
* [Creating a New Security Compliance Framework in Prowler](/developer-guide/security-compliance-framework)
* [Prowler Cloud — Getting Started](/user-guide/tutorials/prowler-app)