Merge master

2026-11-08 12:24:45 +00:00 · 2026-08-31 07:08:03 +00:00
commit 6519927d64
@@ -4,6 +4,139 @@ description: "Track new features, improvements, provider updates, and bug fixes
 rss: true
 ---

+<Update label="v5.40.0" description="August 28, 2026">
+  ### 💬 Slack Integration — Alert Channel Destinations
+
+  <Note>
+  This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
+  </Note>
+
+  Alerts can now reach Slack. Connect a Slack workspace from the Integrations page, authorize one or several destination channels (the connection check confirms each channel with a one-time message and names any channel Slack refuses), and pick those channels in the alert modal's "Destination channels" selector, next to the "Recipients" selector for email. The alerts list summarizes both in a single "Destinations" column, showing a rule's email recipients and Slack channels at a glance. Disconnecting the workspace and recovering from revoked credentials are handled from the same page.
+
+  ![Connected Slack workspace on the Integrations page](/images/prowler-app/slack/connected-workspace.png)
+
+  ![Alert rule with Slack channel destinations](/images/prowler-app/alerts/create-alert-modal.png)
+
+  Read more in the [Slack integration documentation](https://docs.prowler.com/user-guide/tutorials/prowler-app-slack-integration) and the [Alerts documentation](https://docs.prowler.com/user-guide/tutorials/prowler-alerts).
+
+  ### 🤖 Lighthouse AI — Answer Feedback
+
+  <Note>
+  This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
+  </Note>
+
+  Every Lighthouse AI answer can now be rated with a thumbs up or thumbs down, with an optional field to describe what worked or what did not. Feedback is collected per answer, directly in the chat, and tells the team where Lighthouse should improve next.
+
+  Read more in the [Lighthouse AI documentation](https://docs.prowler.com/getting-started/products/prowler-cloud-lighthouse).
+
+  ### 📥 Providers — Imported Findings Indicator
+
+  <Note>
+  This feature is available exclusively in **Prowler Cloud** and **Prowler Private Cloud** with a [subscription](https://prowler.com/pricing).
+  </Note>
+
+  Providers whose findings were imported with the Prowler CLI now show an "Imported provider" indicator next to their connection status in the providers table. In accounts that mix connected providers with Import Findings uploads, the table now tells them apart at a glance.
+
+  ![Provider row with the Imported provider indicator and its tooltip](/images/changelog/v5.40.0-imported-provider-indicator.png)
+
+  Read more in the [Import Findings documentation](https://docs.prowler.com/user-guide/tutorials/prowler-import-findings).
+
+  ### 📚 Compliance — NCSC Cyber Essentials 3.3
+
+  Cyber Essentials is the UK National Cyber Security Centre (NCSC) scheme certifying the baseline technical controls an organization must implement, and cloud services are explicitly in scope and cannot be excluded from an assessment. Prowler now includes NCSC Cyber Essentials: Requirements for IT Infrastructure v3.3 (April 2026) as a universal framework, with its 28 requirements organized in the five control themes: Firewalls, Secure Configuration, Security Update Management, User Access Control, and Malware Protection.
+
+  Sixteen requirements map to Azure checks covering the controls the applicant organization owns under the shared responsibility model. The remaining twelve apply to end-user devices, on-premises network appliances, or organizational process, which cloud control-plane evidence cannot observe, so they are reported as Manual.
+
+  Contributed by @m-khan-97. Thank you!
+
+  Read more in the [Compliance documentation](https://docs.prowler.com/user-guide/compliance/tutorials/compliance).
+
+  ### 🔍 Checks
+
+  Fifteen new checks land across seven providers in this release.
+
+  #### AWS
+
+  - `ecr_repository_image_no_secrets` scans the latest image of each ECR repository, both its configuration and its filesystem layers, for hardcoded secrets. Thanks to @esquaredsec!
+  - Four new Amazon Bedrock checks, thanks to @tamg-aws!
+    - `bedrock_guardrail_contextual_grounding_filter_enabled` verifies that guardrails enable both contextual grounding filters, blocking responses that are not supported by the retrieved source or do not answer the question asked.
+    - `bedrock_custom_model_encrypted_with_cmk` verifies that custom models are encrypted at rest with a customer-managed KMS key instead of an AWS-owned key the organization cannot audit, rotate, or revoke.
+    - `bedrock_knowledge_base_encrypted_with_cmk` verifies that each knowledge-base data source encrypts with a customer-managed KMS key the transient storage used while documents are chunked and embedded.
+    - `bedrock_agent_role_not_shared_across_agents` verifies that every agent has a dedicated execution role, so no agent inherits another's permissions.
+  - `rolesanywhere_profile_restricts_session_permissions` flags IAM Roles Anywhere profiles that reference an administrative role without scoping down the vended session with a session policy or managed policies.
+
+  Explore all AWS checks at [Prowler Hub](https://hub.prowler.com/check?provider=aws).
+
+  #### GCP
+
+  - `iam_workload_identity_pool_provider_attribute_condition` flags Workload Identity Federation providers that trust a multi-tenant issuer without an attribute condition restricting which external identities can impersonate federated principals.
+
+  Explore all GCP checks at [Prowler Hub](https://hub.prowler.com/check?provider=gcp).
+
+  #### GitHub
+
+  Three new checks harden GitHub Actions defaults, all contributed by @Edneam. Thank you!
+
+  - `organization_default_workflow_permissions_read_only` and `repository_default_workflow_permissions_read_only` verify that workflows get a read-only default `GITHUB_TOKEN` at the organization and repository level.
+  - `organization_actions_pull_request_approval_disabled` verifies that organizations prevent GitHub Actions from creating and approving pull requests.
+
+  Explore all GitHub checks at [Prowler Hub](https://hub.prowler.com/check?provider=github).
+
+  #### Microsoft 365
+
+  - `defender_domain_dmarc_records_published` checks that every Exchange Online domain publishes a DMARC record with an enforcing policy (`p=quarantine` or `p=reject`). Thanks to @Rishi943!
+
+  Explore all Microsoft 365 checks at [Prowler Hub](https://hub.prowler.com/check?provider=m365).
+
+  #### Alibaba Cloud
+
+  - `oss_bucket_versioning_enabled` verifies that OSS buckets keep versioning enabled, allowing recovery from accidental or malicious object overwrite and deletion. Thanks to @abidedavana!
+  - `oss_bucket_server_side_encryption_enabled` verifies that OSS buckets define a default server-side encryption rule, either AES256 or KMS. Thanks to @alexchen-sys!
+
+  OSS bucket logging, versioning, default encryption, and ACL configurations are also now read correctly from the Alibaba Cloud SDK, so the checks reading them no longer report every bucket as unconfigured.
+
+  Explore all Alibaba Cloud checks at [Prowler Hub](https://hub.prowler.com/check?provider=alibabacloud).
+
+  #### Huawei Cloud
+
+  - `vpc_security_group_open_egress` flags VPC security groups that allow open egress to the internet. Thanks to @tomitobio!
+
+  Explore all Huawei Cloud checks at [Prowler Hub](https://hub.prowler.com/check?provider=huaweicloud).
+
+  #### STACKIT
+
+  - `ske_cluster_no_public_endpoint` flags SKE clusters whose Kubernetes API endpoint is reachable from the whole internet, because the ACL extension is disabled or its allowed CIDR list contains `0.0.0.0/0` or `::/0`. Thanks to @johannes-engler-mw!
+
+  Explore all STACKIT checks at [Prowler Hub](https://hub.prowler.com/check?provider=stackit).
+
+  ### 🔐 Security Updates
+
+  - The API and SDK container images upgrade OpenSSL to 3.5.7-1~deb13u2, patching ten high CVEs; the UI image upgrades `libcrypto3` and `libssl3` to 3.5.8-r0, patching seven high CVEs; the MCP Server image patches CVE-2026-14456 (OpenSSL), CVE-2026-11822, and CVE-2026-11824 (SQLite).
+  - `sqlparse` upgraded to 0.6.0 in the API, patching CVE-2026-54284, CVE-2026-59893, and CVE-2026-71491.
+
+  ### 🙌 External Contributors
+
+  Thank you to our community contributors for this release!
+
+  - @Edneam: GitHub `organization_default_workflow_permissions_read_only` ([#12122](https://github.com/prowler-cloud/prowler/pull/12122)), `repository_default_workflow_permissions_read_only` ([#12143](https://github.com/prowler-cloud/prowler/pull/12143)), and `organization_actions_pull_request_approval_disabled` ([#12394](https://github.com/prowler-cloud/prowler/pull/12394)) checks
+  - @tamg-aws: four AWS Bedrock checks covering guardrail grounding, CMK encryption, and agent role isolation ([#12459](https://github.com/prowler-cloud/prowler/pull/12459))
+  - @esquaredsec: AWS `ecr_repository_image_no_secrets` check ([#12123](https://github.com/prowler-cloud/prowler/pull/12123))
+  - @Rishi943: Microsoft 365 `defender_domain_dmarc_records_published` check ([#11936](https://github.com/prowler-cloud/prowler/pull/11936))
+  - @abidedavana: Alibaba Cloud `oss_bucket_versioning_enabled` check ([#11913](https://github.com/prowler-cloud/prowler/pull/11913))
+  - @alexchen-sys: Alibaba Cloud `oss_bucket_server_side_encryption_enabled` check ([#11981](https://github.com/prowler-cloud/prowler/pull/11981))
+  - @tomitobio: Huawei Cloud `vpc_security_group_open_egress` check ([#12209](https://github.com/prowler-cloud/prowler/pull/12209))
+  - @johannes-engler-mw: STACKIT `ske_cluster_no_public_endpoint` check ([#11943](https://github.com/prowler-cloud/prowler/pull/11943))
+  - @gabrielfrdev: cluster name in Kubernetes compliance report outputs ([#12506](https://github.com/prowler-cloud/prowler/pull/12506))
+  - @jfgmesquita: AWS FSBP compliance mapping fix for IAM.9 and EKS.1 ([#12372](https://github.com/prowler-cloud/prowler/pull/12372))
+  - @hackertwinten: `ec2_securitygroup_not_used` no longer flags security groups held only by scaled-down AWS Batch compute environments ([#12458](https://github.com/prowler-cloud/prowler/pull/12458))
+  - @0xTaoZ: ECS task-definition checks no longer report PASS when `DescribeTaskDefinition` fails, shipped early in v5.39.1 ([#12217](https://github.com/prowler-cloud/prowler/pull/12217))
+  - @ye11oc4t: `ses_identity_not_publicly_accessible` now evaluates every identity authorization policy, shipped early in v5.39.1 ([#12464](https://github.com/prowler-cloud/prowler/pull/12464))
+  - @Zuhef: IaC provider raises typed exceptions instead of `sys.exit` when cloning the scanned repository or running Trivy fails ([#12227](https://github.com/prowler-cloud/prowler/pull/12227)), Kubernetes kubelet checks no longer disappear from the scan when a `kubelet-config` ConfigMap is broken ([#12225](https://github.com/prowler-cloud/prowler/pull/12225)), and the CLI `--slack` summary is sent for scans with no findings instead of failing with `ZeroDivisionError` ([#12229](https://github.com/prowler-cloud/prowler/pull/12229))
+  - @m-khan-97: NCSC Cyber Essentials 3.3 compliance framework with Azure provider coverage across the five Cyber Essentials themes ([#11588](https://github.com/prowler-cloud/prowler/pull/11588))
+
+  See the [full release notes on GitHub](https://github.com/prowler-cloud/prowler/releases/tag/5.40.0) for the complete list of changes.
+</Update>
+
 <Update label="v5.39.0" description="August 13, 2026">
  ### 🤖 Lighthouse AI — Finding Skills

@@ -225,9 +225,9 @@ Each check **must** populate the report with a unique identifier for the audited
            - `resource_name`: Description of the configuration (e.g., "SharePoint Settings")
 - GitHub
    - Resource ID — `report.resource_id`.
-        - The ID of the Github resource. This is a system-generated integer that uniquely identifies the resource within the Github platform.
+        - The ID of the GitHub resource. This is a system-generated integer that uniquely identifies the resource within the GitHub platform.
    - Resource Name — `report.resource_name`.
-        - The name of the Github resource. In the case of a repository, this is just the repository name. For full repository names use the resource `full_name`.
+        - The name of the GitHub resource. In the case of a repository, this is just the repository name. For full repository names use the resource `full_name`.

 ### Configurable Checks in Prowler

@@ -121,14 +121,14 @@ class NewFeatureTools(BaseTool):

        Returns complete feature details including configuration and metadata.
        """
-        try:
-            response = await self.api_client.get(f"/api/v1/features/{feature_id}")
-            return DetailedFeature.from_api_response(response["data"]).model_dump()
-        except Exception as e:
-            self.logger.error(f"Failed to get feature {feature_id}: {e}")
-            return {"error": str(e), "status": "failed"}
+        response = await self.api_client.get(f"/api/v1/features/{feature_id}")
+        return DetailedFeature.from_api_response(response["data"]).model_dump()
 ```

+There is no `try`/`except` here on purpose. A failed request raises, and
+[Error Handling](#error-handling) explains what turns that raise into a message
+the agent can act on.
+
 ### Step 2: Create the Models

 Create corresponding models in `prowler_app/models/`:
@@ -370,18 +370,62 @@ async def search_items(self, status: str = Field(...)) -> dict:

 ### Error Handling

-Return structured error responses instead of raising exceptions:
+**Raise, never return.** A returned `{"error": ...}` dict is reported to the
+client as `isError: false` -- a *successful* tool call whose payload happens to
+mention a failure. Clients and models read that as success. A raised exception
+becomes a spec-correct tool execution error instead.
+
+The common case therefore needs no handler at all:

 ```python
 async def get_item(self, item_id: str) -> dict:
-    try:
-        response = await self.api_client.get(f"/api/v1/items/{item_id}")
-        return DetailedItem.from_api_response(response["data"]).model_dump()
-    except Exception as e:
-        self.logger.error(f"Failed to get item {item_id}: {e}")
-        return {"error": str(e), "status": "failed"}
+    response = await self.api_client.get(f"/api/v1/items/{item_id}")
+    return DetailedItem.from_api_response(response["data"]).model_dump()
 ```

+`prowler_mcp_server/lib/errors.py` classifies the failures every tool shares --
+a rejected credential, a missing permission, a rate limit, an outage, an
+unreachable API, a bad argument -- and gives each one a message that says what
+went wrong and what to do about it. Anything it does not recognise is masked,
+because `mask_error_details=True` is set on every sub-server and upstream
+response bodies must never be replayed into a model's context.
+
+Three ways to raise, in the order to reach for them:
+
+```python
+from fastmcp.exceptions import ToolError
+
+from prowler_mcp_server.lib.errors import InvalidArgument
+
+# 1. An argument this server rejected before any request went out. The message
+#    is repeated to the agent verbatim, so write it for one to read.
+if not 1 <= page_size <= 1000:
+    raise InvalidArgument("page_size must be between 1 and 1000.")
+
+# 2. A request the API answered or never answered: let it propagate untouched.
+#    `ProwlerAPIError` and `ProwlerAPIUnreachable` are what the classifier keys
+#    on, and the second one is what stops a retry from duplicating a write.
+response = await self.api_client.get(f"/api/v1/items/{item_id}")
+data = response["data"]
+
+# 3. A sentence the classifier cannot know -- a resource name, a precondition,
+#    the next tool to call. NOTE the absent `from` clause: it is what marks the
+#    message as already final. With `from e` the classifier would replace it.
+if not data:
+    raise ToolError(
+        f"No item with the ID {item_id!r} exists. Use prowler_list_items to "
+        "find a valid one."
+    )
+```
+
+The one thing that still *returns* rather than raises is a write whose outcome is
+genuinely unknown. `prowler_send_findings_to_jira` is the worked example: work
+items are created one at a time and Prowler cannot delete them, so a dispatch
+that stopped halfway answers with a result object carrying
+`safe_to_retry: false`. "This may have been applied" is a fact about the world,
+not an error, and squashing it into one loses the only thing that stops a retry
+from duplicating the write.
+
 ### Parameter Descriptions

 Use Pydantic `Field()` with clear descriptions. This also helps LLMs understand
@@ -108,7 +108,7 @@ Once you have decided the provider you want or need to add to Prowler, the next
 - **SDK Providers**: Low complexity. You have mature examples like AWS, Azure, GCP, Kubernetes, etc. that you can leverage to implement your provider.
 - **API Providers**: Medium complexity. You need to implement the authentication and session management, and the API calls to the provider. You now have NHN and MongoDB Atlas as example to follow.
 - **Tool/Wrapper Providers**: High complexity. You need to implement the argument/output mapping to the provider and handle problems that the tool/wrapper may have. You now have IAC and the PowerShell wrapper as example to follow.
- **Hybrid Providers**: High complexity. You need to "customize" your provider, mixing the other types of providers in order to achieve the desired result. You have M365 (msgraph SDK + PowerShell wrapper) and Github (PyGithub SDK + graphql API requests) as examples.
+- **Hybrid Providers**: High complexity. You need to "customize" your provider, mixing the other types of providers to achieve the desired result. You have M365 (msgraph SDK + PowerShell wrapper) and GitHub (PyGithub SDK + graphql API requests) as examples.

 ### Determining Regional vs Non-Regional Architecture

@@ -815,7 +815,7 @@ class YourProviderMutelist(Mutelist):
 Region management is essential for cloud providers that operate across multiple geographic locations. This component handles region validation and provides region-specific functionality.

 <Note>
-Regions are optional, only if the provider has regions, for example Github does not have regions, but AWS does.
+Regions are optional, only if the provider has regions, for example GitHub does not have regions, but AWS does.
 </Note>

 **File:** `prowler/providers/<provider_name>/lib/regions/<provider_name>_regions.py`
@@ -1774,7 +1774,7 @@ The implementation of the mutelist is the same as the [SDK providers](#step-5-im
 Region management is essential for cloud providers that operate across multiple geographic locations. This component handles region validation and provides region-specific functionality.

 <Note>
-Regions are optional, only if the provider has regions, for example Github does not have regions, but AWS does.
+Regions are optional, only if the provider has regions, for example GitHub does not have regions, but AWS does.
 </Note>

 **File:** `prowler/providers/<provider_name>/lib/regions/<provider_name>_regions.py`
@@ -526,7 +526,7 @@ with mock.patch(
 ):
 ```

-As demonstrated in the code above, mocking both the AWS audit information and all utilized services is mandatory for proper test execution.
+As demonstrated in the code above, mocking both the AWS audit information and all used services is mandatory for proper test execution.

 #### Patching vs. Importing

@@ -182,7 +182,8 @@
                "pages": [
                  "user-guide/tutorials/prowler-app-s3-integration",
                  "user-guide/tutorials/prowler-app-security-hub-integration",
-                  "user-guide/tutorials/prowler-app-jira-integration"
+                  "user-guide/tutorials/prowler-app-jira-integration",
+                  "user-guide/tutorials/prowler-app-slack-integration"
                ]
              },
              {
@@ -301,6 +302,15 @@
          {
            "group": "Providers",
            "pages": [
+              {
+                "group": "Organizations",
+                "pages": [
+                  "user-guide/organizations",
+                  "user-guide/providers/aws/organizations",
+                  "user-guide/providers/gcp/organization",
+                  "user-guide/providers/azure/management-groups"
+                ]
+              },
              {
                "group": "Alibaba Cloud",
                "pages": [
@@ -330,6 +340,7 @@
                  "user-guide/providers/azure/getting-started-azure",
                  "user-guide/providers/azure/authentication",
                  "user-guide/providers/azure/use-non-default-cloud",
+                  "user-guide/providers/azure/management-groups",
                  "user-guide/providers/azure/subscriptions",
                  "user-guide/providers/azure/resource-groups",
                  "user-guide/providers/azure/create-prowler-service-principal"
@@ -23,7 +23,7 @@ Google Cloud Security Command Center (Cloud SCC) is a centralized security and r

 - **GCP-Centric:** While Cloud SCC is powerful within the GCP ecosystem, it is primarily focused on GCP and does not natively extend to multi-cloud environments without additional tools or connectors.

- **Cost Considerations:** As a managed service within GCP, costs can scale with the amount of data ingested and the complexity of the environment, especially as additional features or higher volumes of data are utilized.
+- **Cost Considerations:** As a managed service within GCP, costs can scale with the amount of data ingested and the complexity of the environment, especially as additional features or higher volumes of data are used.

 - **Dependency on GCP Services:** Cloud SCC's capabilities depend on other GCP services being enabled, such as Security Health Analytics and Web Security Scanner, which may increase overall complexity and cost.

@@ -129,12 +129,12 @@ To update the environment file:
 Edit the `.env` file and change version values:

 ```env
-PROWLER_UI_VERSION="5.39.0"
-PROWLER_API_VERSION="5.39.0"
+PROWLER_UI_VERSION="5.40.0"
+PROWLER_API_VERSION="5.40.0"
 ```

 <Note>
-  You can find the latest versions of Prowler Local Server in the [Releases Github section](https://github.com/prowler-cloud/prowler/releases) or in the [Container Versions](#container-versions) section of this documentation.
+  You can find the latest versions of Prowler Local Server in the [Releases GitHub section](https://github.com/prowler-cloud/prowler/releases) or in the [Container Versions](#container-versions) section of this documentation.
 </Note>


@@ -46,7 +46,7 @@ To install Prowler as a Python package, use `Python >= 3.10, <= 3.13`. Prowler i
    _Requirements_:

    * Have `docker` installed: https://docs.docker.com/get-docker/.
-    * In the command below, change `-v` to your local directory path in order to access the reports.
+    * In the command below, change `-v` to your local directory path to access the reports.
    * AWS, GCP, Azure and/or Kubernetes credentials

    _Commands_:
@@ -92,6 +92,7 @@ li[id="/user-guide/tutorials/prowler-alerts"] a > div > div > span:first-child::
 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,
 li[id="/user-guide/tutorials/prowler-app-scan-configuration"] a > div > div > span:first-child::after,
+li[id="/user-guide/tutorials/prowler-app-slack-integration"] a > div > div > span:first-child::after,
 li[id="/user-guide/tutorials/prowler-cloud-aws-organizations"] a > div > div > span:first-child::after,
 li[id="/user-guide/tutorials/prowler-cloud-azure-management-groups"] a > div > div > span:first-child::after,
 li[id="/user-guide/tutorials/prowler-cloud-gcp-organizations"] a > div > div > span:first-child::after,
@@ -496,7 +496,7 @@ aws:

  # AWS CloudTrail Configuration
  # aws.cloudtrail_threat_detection_privilege_escalation
-  threat_detection_privilege_escalation_threshold: 0.2 # Percentage of actions found to decide if it is an privilege_escalation attack event, by default is 0.2 (20%)
+  threat_detection_privilege_escalation_threshold: 0.2 # Percentage of actions found to decide if it is a privilege_escalation attack event, by default is 0.2 (20%)
  threat_detection_privilege_escalation_minutes: 1440 # Past minutes to search from now for privilege_escalation attacks, by default is 1440 minutes (24 hours)
  threat_detection_privilege_escalation_actions:
    [
@@ -7,7 +7,7 @@ In certain organizations, the severity of specific checks might differ from the

 The custom metadata option offers a means to override default metadata set by Prowler.

-You can utilize `--custom-checks-metadata-file` followed by the path to your custom checks metadata YAML file.
+You can use `--custom-checks-metadata-file` followed by the path to your custom checks metadata YAML file.

 ## Available Fields

@@ -100,7 +100,7 @@ def get_table(data):

 ## S3 Integration

-If you are using Prowler Cloud with the S3 integration or that integration from Prowler CLI and you want to use your data from your S3 bucket, you can run the following command in order to load the dashboard with the new files:
+If you are using Prowler Cloud with the S3 integration or that integration from Prowler CLI and you want to use your data from your S3 bucket, you can run the following command to load the dashboard with the new files:

 ```sh
 aws s3 cp s3://<your-bucket>/output/csv ./output --recursive
@@ -0,0 +1,58 @@
+---
+title: 'Organizations Across Cloud Providers'
+description: 'Understand organization hierarchies and onboarding across AWS, Google Cloud, and Azure'
+---
+
+Cloud providers use organization-level hierarchies to group accounts, projects, or subscriptions and apply access and governance consistently. Prowler uses these hierarchies to discover cloud targets and help configure multi-account or multi-project scanning.
+
+This guide explains the shared lifecycle and the differences between AWS Organizations, Google Cloud organizations, and Azure Management Groups. Use the provider-specific guides for commands, permissions, and limitations.
+
+## Organization Lifecycle
+
+Organization-level onboarding generally follows these steps:
+
+1. **Identify the hierarchy:** Locate the organization, management account, management group, folder, organizational unit, or equivalent parent node in the cloud provider.
+2. **Grant access:** Assign the provider permissions required to enumerate the hierarchy and read the resources that Prowler scans.
+3. **Discover members:** Use Prowler to retrieve accounts, projects, or subscriptions under the selected hierarchy.
+4. **Select scan targets:** Choose the cloud targets to connect or scan. Discovery does not necessarily make every discovered target a Prowler provider.
+5. **Test access:** Confirm that Prowler can authenticate to each selected target and read its resources.
+6. **Scan and maintain:** Run scans, review findings, and repeat discovery when the provider hierarchy changes.
+
+<Note>
+Organization membership changes are not automatically synchronized in every Prowler workflow. Follow the provider-specific guide to learn when manual rediscovery is required.
+</Note>
+
+## Capability Matrix
+
+| Capability | AWS Organizations | Google Cloud organization | Azure Management Groups |
+| --- | --- | --- | --- |
+| Hierarchy members | AWS accounts grouped in organizational units (OUs) | Projects grouped in folders and nested folders | Subscriptions grouped in management groups |
+| Organization-level discovery | Supported through AWS Organizations APIs | Supported through the Cloud Asset API | Supported through Azure management-group and subscription APIs |
+| Primary scan target | AWS account | Google Cloud project | Azure subscription |
+| Common organization-level permission | IAM role in the management or delegated administrator account | Cloud Asset Viewer or Cloud Asset Owner at the organization node | Appropriate Azure role assignment at the management-group or subscription scope |
+| Provider-specific onboarding | AWS account discovery and optional StackSet role deployment | Project discovery under an organization ID | Subscription discovery under a management group; role assignments inherit to subscriptions |
+| Membership maintenance | Repeat the discovery flow when accounts are added or removed | Re-run organization discovery when projects or folders change | Refresh discovery when subscriptions move between management groups |
+
+## Provider Guides
+
+### AWS Organizations
+
+The [AWS Organizations guide](/user-guide/providers/aws/organizations) covers account details, delegated administration, IAM roles, CloudFormation StackSets, and CLI scanning. For Prowler Cloud onboarding, see [AWS Organizations in Prowler Cloud](/user-guide/tutorials/prowler-cloud-aws-organizations).
+
+### Google Cloud Organization
+
+The [Google Cloud organization guide](/user-guide/providers/gcp/organization) covers scanning projects under an organization ID, organization-level permissions, and Cloud Asset API requirements. For Prowler Cloud onboarding, see [Google Cloud organizations in Prowler Cloud](/user-guide/tutorials/prowler-cloud-gcp-organizations).
+
+### Azure Management Groups
+
+The [Azure Management Groups guide](/user-guide/providers/azure/management-groups) covers hierarchy setup, role assignment, subscription scope, and Azure-specific limitations. For Prowler Cloud onboarding, see [Azure Management Groups in Prowler Cloud](/user-guide/tutorials/prowler-cloud-azure-management-groups).
+
+## Scope Boundaries
+
+The organization concepts in this guide refer only to cloud-provider resource hierarchies:
+
+- **GitHub organizations** group repositories and GitHub resources. They are a separate provider concept and are not part of AWS, Google Cloud, or Azure organization discovery.
+- **MongoDB Atlas organizations** group Atlas projects and teams. They use a separate provider API and authentication model.
+- **Prowler Cloud organizations** are internal tenants that isolate providers, scans, findings, users, and permissions. They are not the same as a cloud-provider organization and do not replace one.
+
+Choose the guide that matches the hierarchy being configured, then use the relevant Prowler Cloud or CLI workflow for the scan targets.
@@ -65,7 +65,7 @@ This method grants permanent access and is the recommended setup for production

    7. Click "Submit" to deploy the stack

-        ![Click on submit](/images/providers/submit-third-page.png)
+        ![Click Submit](/images/providers/submit-third-page.png)
  </Tab>
  <Tab title="Terraform">
    To provision the scan role using Terraform:
@@ -3,7 +3,7 @@ title: 'Scan Multiple AWS Accounts with Prowler'
 description: 'Run Prowler across many AWS accounts sequentially or in parallel using IAM assume role, ideal for auditing several accounts from one entry point.'
 ---

-Prowler enables security scanning across multiple AWS accounts by utilizing the [Assume Role feature](/user-guide/providers/aws/role-assumption) and [integration with AWS Organizations feature](/user-guide/providers/aws/organizations).
+Prowler enables security scanning across multiple AWS accounts by using the [Assume Role feature](/user-guide/providers/aws/role-assumption) and [integration with AWS Organizations feature](/user-guide/providers/aws/organizations).

 This approach allows execution from a single account with permissions to assume roles in the target accounts.

@@ -13,6 +13,8 @@ See [AWS Organizations](/user-guide/tutorials/prowler-cloud-aws-organizations) i

 Prowler can integrate with AWS Organizations to manage the visibility and onboarding of accounts centrally.

+For the cross-provider organization lifecycle and capability comparison, see [Organizations Across Cloud Providers](/user-guide/organizations).
+
 When trusted access is enabled with the Organization, Prowler can discover accounts as they are created and even automate deployment of the Prowler Scan IAM Role.

 > ℹ️ Trusted access can be enabled in the Management Account from the AWS Console under **AWS Organizations → Settings → Trusted access for AWS CloudFormation StackSets**.
@@ -0,0 +1,53 @@
+---
+title: 'Azure Management Groups in Prowler'
+---
+
+Azure Management Groups provide a hierarchy above subscriptions. They allow Azure role assignments and governance policies to apply to multiple subscriptions through a shared scope.
+
+For the cross-provider concepts and lifecycle, see [Organizations Across Cloud Providers](/user-guide/organizations).
+
+## Azure Hierarchy
+
+Azure resources are organized in the following order:
+
+1. Tenant
+2. Management groups
+3. Subscriptions
+4. Resource groups
+5. Resources
+
+Prowler scans Azure subscriptions. Management groups help organize those subscriptions and provide a scope where permissions can be assigned, but a management group is not itself a scan target.
+
+## Create a Management Group
+
+To create a management group, follow the [official Azure guide](https://learn.microsoft.com/en-us/azure/governance/management-groups/create-management-group-portal).
+
+![Create management group](/images/create-management-group.gif)
+
+After creating the management group, add the subscriptions that Prowler should access and scan.
+
+![Add Subscription to Management Group](/images/add-sub-to-management-group.gif)
+
+## Assign Roles
+
+Assign the roles required by Prowler at the management-group scope instead of assigning them separately to every subscription. Role assignments at a management group can inherit to its child subscriptions, subject to Azure role-assignment and inheritance rules.
+
+Use the [subscription scope permissions](/user-guide/providers/azure/authentication#subscription-scope-permissions) guide to identify the permissions required for scans. The identity used by Prowler must be able to read the management-group hierarchy and access each subscription selected for scanning.
+
+## Subscription Scope
+
+Management groups organize subscriptions, but Azure scan results remain scoped to individual subscriptions:
+
+- Prowler Cloud scans one subscription per scan.
+- Prowler CLI can scan multiple subscriptions by using the `--subscription-ids` option.
+- A subscription must be accessible to the configured identity before Prowler can scan it.
+- Moving a subscription between management groups can change the permissions it inherits and may require a connection test or rediscovery.
+
+See [Azure Subscription Scope](/user-guide/providers/azure/subscriptions) for subscription selection and CLI options.
+
+## Limitations
+
+- Management groups do not replace subscription providers in Prowler.
+- Azure role inheritance depends on the management-group hierarchy and the scope of each assignment; verify access on every subscription selected for scanning.
+- The Prowler Cloud workflow is designed around Azure management-group discovery and subscription onboarding. The Prowler CLI workflow still requires explicit subscription selection when restricting scans.
+- Changes to management-group membership or role assignments may not be reflected until the hierarchy is refreshed and access is tested again.
@@ -26,14 +26,4 @@ Check the [Authentication > Subscription Scope Permissions](/user-guide/provider

 ## Recommendation for Managing Multiple Subscriptions

-Scanning multiple subscriptions requires creating and assigning roles for each, which can be a time-consuming process. To streamline subscription management and auditing, use management groups in Azure. This approach allows Prowler to efficiently organize and audit multiple subscriptions collectively.
-
-1. **Create a Management Group**: Follow the [official guide](https://learn.microsoft.com/en-us/azure/governance/management-groups/create-management-group-portal) to create a new management group.
-
-    ![Create management group](/images/create-management-group.gif)
-
-2. **Assign Roles**: Assign necessary roles to the management group, similar to the [role assignment process](#assigning-permissions-for-subscription-scans).
-
-    Role assignment should be done at the management group level instead of per subscription.
-
-3. **Add Subscriptions**: Add all subscriptions you want to audit to the newly created management group. ![Add Subscription to Management Group](/images/add-sub-to-management-group.gif)
+Scanning multiple subscriptions requires creating and assigning roles for each, which can be a time-consuming process. To streamline subscription management and auditing, use [Azure Management Groups](/user-guide/providers/azure/management-groups) to organize subscriptions and assign permissions collectively.
@@ -5,6 +5,8 @@ description: 'Restrict Prowler GCP scans to one organization using --organizatio

 By default, Prowler scans all Google Cloud projects accessible to the authenticated user.

+For the cross-provider organization lifecycle and capability comparison, see [Organizations Across Cloud Providers](/user-guide/organizations).
+
 To limit the scan to projects within a specific Google Cloud organization, use the `--organization-id` option with the GCP organization’s ID:

 ```console
@@ -43,7 +43,7 @@ Required for scanning repository security settings:

 | Permission | Access Level | Purpose | Checks Enabled |
 |------------|-------------|---------|----------------|
-| **Administration** | Read | Branch protection, security settings | All branch protection checks, secret scanning status |
+| **Administration** | Read | Branch protection, security and Actions settings | All branch protection checks, secret scanning status, `repository_default_workflow_permissions_read_only` |
 | **Contents** | Read | File existence checks | `repository_public_has_securitymd_file`, `repository_has_codeowners_file` |
 | **Metadata** | Read | Basic repository information | All checks (automatically granted) |
 | **Dependabot alerts** | Read | Dependency vulnerability scanning | `repository_dependency_scanning_enabled` |
@@ -64,7 +64,7 @@ Required for scanning organization-level security settings:

 | Permission | Access Level | Purpose | Checks Enabled |
 |------------|-------------|---------|----------------|
-| **Administration** | Read | Organization security policies | `organization_members_mfa_required`, `organization_repository_creation_limited`, `organization_default_repository_permission_strict` |
+| **Administration** | Read | Organization security policies and Actions settings | `organization_members_mfa_required`, `organization_repository_creation_limited`, `organization_default_repository_permission_strict`, `organization_default_workflow_permissions_read_only`, `organization_actions_pull_request_approval_disabled` |
 | **Members** | Read | Member access reviews | Organization membership auditing |

 #### Account Permissions (Fine-Grained PAT only)
@@ -84,8 +84,8 @@ With the **Read-only permissions** listed above, Prowler can run:
 | Check Category | Coverage | Notes |
 |----------------|----------|-------|
 | Branch protection checks (12 checks) | ✅ Full | Signed commits, status checks, PR reviews, etc. |
-| Repository security checks | ✅ Full | Secret scanning, Dependabot, SECURITY.md, CODEOWNERS |
-| Organization checks (3 checks) | ✅ Full | MFA, repo creation policies, default permissions |
+| Repository security checks | ✅ Full | Secret scanning, Dependabot, SECURITY.md, CODEOWNERS, default workflow permissions |
+| Organization checks (5 checks) | ✅ Full | MFA, repo creation policies, default permissions, Actions workflow permissions |
 | Compliance frameworks | ✅ Full | CIS GitHub Benchmark and others |
 | Merge settings (`delete_branch_on_merge`) | ⚠️ MANUAL | Requires write permission (see below) |

@@ -172,6 +172,7 @@ Use OAuth App Tokens when building applications that need delegated user permiss

 - `repo`: Full control of repositories
 - `read:org`: Read organization and team membership
+- `admin:org`: Required by `organization_default_workflow_permissions_read_only` and `organization_actions_pull_request_approval_disabled` to read the organization Actions workflow permissions
 - `read:user`: Read user profile data

 **Create an OAuth App:**
@@ -215,7 +216,7 @@ If a GitHub App is required:

 | Permission | Access Level | Purpose | Checks Enabled |
 |------------|-------------|---------|----------------|
-| **Administration** | Read | Branch protection, security settings | All branch protection checks, `repository_secret_scanning_enabled` |
+| **Administration** | Read | Branch protection, security and Actions settings | All branch protection checks, `repository_secret_scanning_enabled`, `repository_default_workflow_permissions_read_only` |
 | **Contents** | Read | File existence checks | `repository_public_has_securitymd_file`, `repository_has_codeowners_file` |
 | **Metadata** | Read | Basic repository information | All checks (automatically granted) |
 | **Dependabot alerts** | Read | Dependency vulnerability scanning | `repository_dependency_scanning_enabled` |
@@ -224,7 +225,7 @@ If a GitHub App is required:

 | Permission | Access Level | Purpose | Checks Enabled |
 |------------|-------------|---------|----------------|
-| **Administration** | Read | Organization security policies | `organization_members_mfa_required`, `organization_repository_creation_limited`, `organization_default_repository_permission_strict` |
+| **Administration** | Read | Organization security policies and Actions settings | `organization_members_mfa_required`, `organization_repository_creation_limited`, `organization_default_repository_permission_strict`, `organization_default_workflow_permissions_read_only`, `organization_actions_pull_request_approval_disabled` |
 | **Members** | Read | Member access reviews | Organization membership auditing |

 **Create a GitHub App:**
@@ -35,4 +35,4 @@ prowler scaleway

 ## Required Scaleway Permissions

-The API key bearer needs read access to the IAM API in order to list users and API keys. The `IAMReadOnly` policy is sufficient. Refer to the [Scaleway IAM policy reference](https://www.scaleway.com/en/docs/identity-and-access-management/iam/reference-content/permission-sets/) for the full list of permissions.
+The API key bearer needs read access to the IAM API to list users and API keys. The `IAMReadOnly` policy is sufficient. Refer to the [Scaleway IAM policy reference](https://www.scaleway.com/en/docs/identity-and-access-management/iam/reference-content/permission-sets/) for the full list of permissions.
@@ -14,7 +14,7 @@ StackIT support in Prowler is community-maintained. For commercial support or to
 Before running Prowler with the StackIT provider, ensure you have:

 1. A StackIT account with at least one project
-2. A StackIT service account key file with permissions on the project (`iaas.viewer` is enough for the currently shipped IaaS checks; `project.owner` works for any future service). See the [Authentication guide](/user-guide/providers/stackit/authentication) for the full setup.
+2. A StackIT service account key file with project permissions for the services to scan. `iaas.viewer` is sufficient for the currently shipped IaaS checks. For SKE, assign the project-scoped `Reader` role as a broad read-only convenience, or create a custom role with `resource-manager.project.get`, `ske.cluster.list`, `ske.cluster.get`, and `ske.version.list`. The `resource-manager.project.get` permission is optional for scanning; it only lets Prowler verify and display the project name. See the [Authentication guide](/user-guide/providers/stackit/authentication) for the full setup.
 3. Access to Prowler CLI (see [Installation](/getting-started/installation/prowler-cli))

 ## Prowler CLI
@@ -125,7 +125,9 @@ Prowler outputs findings to the console and writes reports to the `output/` dire

 | Service | StackIT API | Description | Example Checks |
 |---------|-------------|-------------|----------------|
-| **IaaS** | `iaas` | Virtual machines, network interfaces, security groups | `iaas_security_group_ssh_unrestricted`, `iaas_security_group_rdp_unrestricted`, `iaas_security_group_database_unrestricted`, `iaas_security_group_all_traffic_unrestricted` |
+| **IaaS** | `iaas` | Virtual machines, network interfaces, security groups | `iaas_security_group_ssh_unrestricted`, `iaas_security_group_rdp_unrestricted`, `iaas_security_group_database_unrestricted`, `iaas_security_group_all_traffic_unrestricted`, `iaas_server_public_ip_attached` |
+| **Object Storage** | `objectstorage` | Buckets, object lock, retention policies, access keys | `objectstorage_bucket_object_lock_enabled`, `objectstorage_bucket_retention_policy`, `objectstorage_access_key_expiration` |
+| **Kubernetes Engine** | `ske` | Managed Kubernetes clusters | `ske_cluster_no_public_endpoint` |

 Additional services will be added in future releases. Track progress in the [Prowler release notes](https://github.com/prowler-cloud/prowler/releases).

@@ -137,6 +139,8 @@ If the scan fails with a 401 error, the service account key is no longer valid (

 ### Permission Errors

-If checks fail with a 403 error, the service account is missing the required role on the project. Re-check the role assignment in the StackIT portal (`iaas.viewer` is the minimum for the shipped IaaS checks).
+If the connection probe warns that Resource Manager access could not be verified with a 403 response, Prowler continues to service discovery. Grant the optional `resource-manager.project.get` permission to verify and display the project name.
+
+If a service call fails with a 403 response, the service account is missing a permission required by that service. `iaas.viewer` is sufficient for the shipped IaaS checks. The `ske_cluster_no_public_endpoint` check lists clusters and therefore requires `ske.cluster.list`; STACKIT least-privilege custom-role examples also include `ske.cluster.get` and `ske.version.list`. Service API calls remain authoritative and stop the scan when access is denied.

 For detailed setup steps, see the [Authentication guide](/user-guide/providers/stackit/authentication).
@@ -5,6 +5,8 @@ description: 'Auto-discover every account in an AWS Organization and generate YA

 Prowler offers an automated tool to discover and provision all AWS accounts within an AWS Organization. This streamlines onboarding for organizations managing multiple AWS accounts by automatically generating the configuration needed for bulk provisioning.

+For the cross-provider organization lifecycle and terminology, see [Organizations Across Cloud Providers](/user-guide/organizations).
+
 The tool, `aws_org_generator.py`‎, complements the [Bulk Provider Provisioning](./bulk-provider-provisioning) tool and is available in the Prowler repository at: [util/prowler-bulk-provisioning](https://github.com/prowler-cloud/prowler/tree/master/util/prowler-bulk-provisioning)

 <Note>
@@ -8,7 +8,7 @@ import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"

 <VersionBadge version="5.26.0" />

-Alerts notify recipients by email when security findings match saved filter conditions. Use Alerts to track high-priority findings, monitor specific providers or services, and keep teams informed about scan results that match defined criteria.
+Alerts notify their destinations — email recipients, Slack channels, or both — when security findings match saved filter conditions. Use Alerts to track high-priority findings, monitor specific providers or services, and keep teams informed about scan results that match defined criteria.

 <SubscriptionBanner />

@@ -18,12 +18,13 @@ Before creating Alerts, ensure that:

 * At least one scan has completed and produced findings.
 * The user role includes the `manage_alerts` permission.
+* To deliver Alerts to Slack channels, a Slack workspace is connected, at least one channel is authorized on it, and the integration's connection check has confirmed that channel. See [Slack Integration](/user-guide/tutorials/prowler-app-slack-integration).

 The `manage_alerts` permission is required to create, edit, test, enable, disable, and delete Alerts. See [RBAC Administrative Permissions](/user-guide/tutorials/prowler-app-rbac#rbac-administrative-permissions) for details.

 ## How Alerts Work

-Alerts are created from Findings filters. When an Alert runs, Prowler Cloud evaluates the saved conditions against findings and sends an email digest when matching findings exist.
+Alerts are created from Findings filters. When an Alert runs, Prowler Cloud evaluates the saved conditions against findings and notifies the Alert's destinations when matching findings exist: an email digest to each recipient, a message to each Slack channel, or both. Destination kinds are independent — neither requires the other, and neither displaces the other.

 <Note>
 Alerts evaluate findings with status `FAIL` only. Findings with status `PASS` or `MANUAL`, and muted findings, never trigger an Alert regardless of the saved filters.
@@ -52,6 +53,7 @@ To create an Alert:
    * **Description:** Add optional context for the Alert.
    * **Frequency:** Select when Prowler Cloud should evaluate the Alert.
    * **Recipients:** Select the recipients who should receive the email digest.
+    * **Destination channels:** Select the Slack channels that should receive the Alert. See [Slack Channel Destinations](#slack-channel-destinations).

    ![Create Alert Modal](/images/prowler-app/alerts/create-alert-modal.png)

@@ -85,11 +87,18 @@ Navigate to **Alerts** to review and manage existing Alerts.

 ![Alerts List](/images/prowler-app/alerts/alerts-list.png)

+The **Destinations** column summarizes where each Alert delivers, without the Alert being opened:
+
+* **Email recipients:** The first address, plus a count of the rest, such as `security@example.com +2 more`.
+* **Slack channels:** The first channel, plus a count of the rest, such as `#sec-alerts +1 more`.
+
+Each summary is omitted when that destination kind is empty, and the column reads **No destinations** when an Alert has neither.
+
 Each Alert provides these actions:

 | Action | Description |
 |--------|-------------|
-| Edit | Update name, description, recipients, frequency, or filters. |
+| Edit | Update name, description, recipients, Slack channels, frequency, or filters. |
 | Enable/Disable | Start or stop Alert evaluation without deleting the Alert. |
 | Delete | Permanently remove the Alert. |

@@ -124,6 +133,37 @@ By default, the **organization owner** receives a **daily digest** for **critica

 If a recipient unsubscribes from Alerts, that address stops receiving digests until it is reconfirmed.

+An Alert does not require email recipients: an Alert that targets Slack channels only is accepted with those channels as its sole destinations. An Alert with no destinations at all stays valid and keeps evaluating its filters, but it delivers nothing.
+
+## Slack Channel Destinations
+
+<VersionBadge version="5.40.0" />
+
+An Alert can post to Slack channels alongside its email recipients, or instead of them. The **Destination channels** field sits directly below **Recipients** in the Alert form, both when creating an Alert and when editing one. When the Alert matches findings, Prowler Cloud posts a message to each of its channels and sends the email digest to each of its recipients, independently of each other.
+
+The channels offered are the confirmed channels of the connected Slack integration, never the whole Slack workspace. Widening the pool takes two steps on the integration: authorize the channel there, then run its connection check, which confirms the channel by posting a one-time confirmation message to it. Once confirmed, the channel is selectable on every Alert. See [Slack Integration](/user-guide/tutorials/prowler-app-slack-integration) for connecting a workspace, authorizing its channels, and confirming them.
+
+A channel that was authorized a moment ago but does not appear in the Alert form has not been confirmed yet. Run **Test connection** on the Slack integration, then reopen the Alert form.
+
+Private channels are identified as **Private** both in the open channel list and on the selected channels once the list is closed, so a private destination is never mistaken for a public one.
+
+### When Slack Channels Cannot Be Selected
+
+The field is always present, so channel delivery is never silently missing. It reports why it cannot be used:
+
+| State | What the Alert form shows |
+|-------|---------------------------|
+| No Slack workspace connected | The field is visible but cannot be edited, explaining that posting Alerts to Slack channels needs a connected Slack workspace, with a link to the Slack integration. |
+| Workspace connected, no confirmed channels | A notice that no channels are available yet and that they are authorized and confirmed on the Slack integration, with the same link. |
+
+In both states the rest of the Alert is unaffected: it can still be created or saved with its filters, frequency, and email recipients.
+
+<Note>
+Slack destinations stay in step with the integration. Removing a channel from the integration's authorized set — or disconnecting the Slack integration altogether — removes that channel from every Alert that targeted it, so an Alert never keeps a destination Prowler can no longer deliver to. The Alert keeps its filters, frequency, and email recipients, and future delivery to that channel stops: nothing is posted to announce the removal, and the notifications already delivered stay in the channel. Restoring delivery means authorizing and confirming the channel again on the integration, then selecting it again on the Alert.
+</Note>
+
+Saving an Alert that names a channel which is not a confirmed channel of a connected Slack integration is refused, and the reason is reported on the Alert form. Authorize and confirm the channel on the Slack integration, or remove it from the Alert, and save again.
+
 ## Email Notifications

 When an Alert matches findings, Prowler Cloud sends a security alert email that summarizes the matching findings. The email includes:
@@ -140,6 +180,6 @@ When an Alert matches findings, Prowler Cloud sends a security alert email that

 * **Start with focused filters:** Create Alerts for specific high-priority scopes, such as critical findings, production providers, or important services.
 * **Use clear names:** Choose names that explain the intent of the Alert.
-* **Review recipients regularly:** Keep recipient lists aligned with current ownership.
+* **Review destinations regularly:** Keep recipient lists and channel selections aligned with current ownership.
 * **Test before saving edits:** Use **Test** after changing filters to confirm that the Alert matches the expected findings.
-* **Disable instead of deleting during tuning:** Disable Alerts temporarily when adjusting filters or recipients.
+* **Disable instead of deleting during tuning:** Disable Alerts temporarily when adjusting filters or destinations.
@@ -69,7 +69,7 @@ To remove **another** user from your organization, use the [_Expel from organiza
 #### Inviting Users

 <Note>
-Please be aware that at this time, an email address can only be associated with a single Prowler account.
+Note that an email address can only be associated with a single Prowler account.

 </Note>
 Follow these steps to invite a user to your account:
@@ -0,0 +1,195 @@
+---
+title: "Slack Integration"
+sidebarTitle: 'Slack'
+description: 'Connect a Slack workspace to Prowler Cloud or Prowler Private Cloud, authorize the channels Prowler posts to, and verify the connection.'
+---
+import { VersionBadge } from "/snippets/version-badge.mdx"
+import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"
+
+<VersionBadge version="5.40.0" />
+
+<SubscriptionBanner />
+
+Prowler Cloud and Prowler Private Cloud connect to a Slack workspace so security updates arrive where teams already work. Connecting takes one approval in Slack — there is no bot token to create, copy, or store by hand — and Prowler records the set of channels it is authorized to post to.
+
+Integrating Prowler Cloud or Prowler Private Cloud with Slack provides:
+
+* **Approval-based setup:** Approve Prowler once in Slack instead of building a Slack app and pasting a token.
+* **Confirmed destinations:** The connection check verifies every authorized channel and confirms each new one in the channel itself, so a channel Prowler cannot reach is reported before anything depends on it.
+* **Controlled reach:** Prowler posts only to the channels authorized on the integration, and private channels stay invisible until the Prowler app is invited to them.
+
+<Note>
+This guide covers the Slack integration in Prowler Cloud and Prowler Private Cloud. It is unrelated to the Prowler CLI `--slack` flag, which posts a scan summary from the command line using a self-created Slack app and the `SLACK_API_TOKEN` and `SLACK_CHANNEL_NAME` environment variables — see [CLI Integrations](/user-guide/cli/tutorials/integrations) for that feature.
+</Note>
+
+## How the Slack Integration Works
+
+When connected and configured:
+
+1. A Slack workspace is approved once through Slack's app install flow, and Prowler stores the resulting credential encrypted.
+2. Prowler reads the channels it can post to: the workspace's public channels, plus the private channels the Prowler app has been invited to.
+3. Several of those channels are selected and saved as the integration's authorized channels.
+4. The connection check verifies the credential and every authorized channel, and posts a one-time confirmation message to each channel it has not confirmed yet.
+5. Features that deliver to Slack, such as [Alerts](/user-guide/tutorials/prowler-alerts), choose their destinations from the confirmed channels.
+6. Disconnecting removes the integration from Prowler and attempts to revoke Prowler's access at Slack.
+
+## Prerequisites
+
+The Slack integration is available only in **Prowler Cloud** and **Prowler Private Cloud**. Prowler Local Server does not serve the Slack endpoints at all, so the Slack card does not appear on the Integrations page and the management page redirects away.
+
+Configuring and using the Slack integration requires the **Manage Integrations** permission. The integration is tenant-wide, so it does not require **Unlimited Visibility** or any specific Provider Group.
+
+One Slack workspace connects per tenant. Approving Prowler again in the same workspace refreshes the stored credential and keeps the authorized channels, but it resets their confirmations and the connection state — the connection check has to be run again. Approving Prowler in a *different* workspace is refused until the current workspace is disconnected: a workspace is never swapped out silently.
+
+## Permissions Prowler Requests in Slack
+
+Slack shows a consent screen listing everything the Prowler app asks for. Prowler requests exactly four bot scopes:
+
+| Scope | Why Prowler Requests It |
+|-------|-------------------------|
+| `chat:write` | Post the confirmation message, and any later notification, to the authorized channels. |
+| `chat:write.public` | Post to a public channel without first inviting the Prowler app to it. |
+| `channels:read` | List public channels for the channel selection and resolve the chosen ones. |
+| `groups:read` | List the private channels the Prowler app has been invited to, so they appear in the channel selection. |
+
+Two of these read more broadly than they behave, and both are worth understanding before approving the app.
+
+### What `chat:write.public` Does Not Grant
+
+On the consent screen, `chat:write.public` reads as permission to post in any public channel. Prowler never uses it that way: **Prowler only ever posts to the channels authorized on the integration.** The scope exists so that authorizing a public channel does not also require someone to invite the Prowler app to it first.
+
+### Why a Private Channel Is Missing From the Channel List
+
+`groups:read` reveals only the private channels the Prowler app is already a member of. A private channel therefore appears in the channel list only after someone invites `@Prowler` to it in Slack:
+
+```text
+/invite @Prowler
+```
+
+That invite is issued in Slack, by that channel's own members, and **the invite itself is the permission grant** — no scope bypasses it. Prowler ships no in-product flow to get the app invited, because the decision belongs to the channel's members. After inviting the app, click **Refresh channels** to re-read the list.
+
+## Connecting a Slack Workspace
+
+To connect a Slack workspace to Prowler Cloud or Prowler Private Cloud:
+
+1. In either product, navigate to **Integrations**.
+2. Locate the **Slack** card and click **Manage**.
+
+    ![Slack card on the Integrations page in Prowler Cloud or Prowler Private Cloud](/images/prowler-app/slack/integrations-tab.png)
+
+3. Click **Add to Slack**.
+
+    ![Slack management page before a workspace is connected, showing the Add to Slack action](/images/prowler-app/slack/no-workspace-connected.png)
+
+4. In Slack, select the workspace to connect and approve the permissions listed on the consent screen.
+5. Slack returns to Prowler Cloud or Prowler Private Cloud, which completes the install and shows the connected workspace.
+
+    ![Connected Slack workspace with no channels authorized yet](/images/prowler-app/slack/connected-workspace.png)
+
+The connected card reports the workspace name and a **Not checked yet** status: the connection is checked against the authorized channels, and none are authorized at this point. Authorizing them is the next step. Once at least one channel is authorized, **Test connection** verifies the credential and every authorized channel, and confirms the ones not confirmed yet.
+
+<Note>
+Declining the consent screen creates nothing. Prowler reports that the workspace was not connected and offers to start again.
+</Note>
+
+## Authorizing Destination Channels
+
+Prowler posts to the channels authorized on the integration. Several channels can be authorized at once, and once the connection check has confirmed them they are the pool every consumer of the integration draws from: an [Alert](/user-guide/tutorials/prowler-alerts) picks its Slack destinations from the confirmed channels, never from the whole workspace.
+
+1. Open the **Destination channels** selection. It lists the workspace's public channels, plus the private channels the Prowler app has been invited to, each marked **Private**.
+
+    ![Destination channels selection listing public channels and an invited private channel marked Private](/images/prowler-app/slack/channel-picker.png)
+
+2. Select one or more channels. A selected private channel keeps its lock and **Private** identification with the list closed, so the authorized set stays readable at a glance.
+3. Click **Save channels**.
+
+Prowler validates the selection against Slack and derives each channel name itself, so a recorded name can never drift from the channel it belongs to. Once the set is saved, the page reports where Prowler posts and runs the connection check over it.
+
+If the selection reports that no channels are available, the workspace exposes nothing Prowler can see. Create a public channel, or invite `@Prowler` to a private one, then click **Refresh channels**.
+
+A workspace can hold more channels than Prowler reads in one go. When that happens, the selection says so and lists what was read: every listed channel is usable, and a channel missing from a partial list is not necessarily one `@Prowler` has to be invited to. Only listed channels can be selected: **Refresh channels** repeats the same bounded read rather than reading further, and the selection's search filters what was already read, so neither surfaces a channel the read left out.
+
+Saving a new selection replaces the authorized set: channels left out of it stop being authorized, and channels added to it are authorized but not yet confirmed. Changing which channels are in the set also resets the integration's connection state, so the check runs again over the new set — reordering the same channels does not. Saving an empty selection leaves the integration with no authorized channels, and **Test connection** cannot be run again until at least one channel is authorized.
+
+<Warning>
+Removing a channel from the authorized set also removes it from every Alert that targeted it. Those Alerts keep their filters, frequency, and email recipients, and future delivery to that channel simply stops: nothing is posted to announce the removal, and the notifications already delivered stay in the channel. Disconnecting the integration has the same effect on every channel it had authorized. Restoring delivery means authorizing and confirming the channel again here, then selecting it again on each Alert.
+</Warning>
+
+### Confirming the Authorized Channels
+
+A channel becomes usable as a destination once the connection check has confirmed it. Click **Test connection**: it verifies the stored credential and every authorized channel, and posts a one-time message to each channel it has not confirmed yet.
+
+```text
+✅ Prowler connection verified. Notifications will be delivered to this channel.
+```
+
+Later checks never post that message again to a channel that is already confirmed, so it arrives once per channel. The integration reports as connected only when every check and every required confirmation succeeded; a failure names the channel that failed. The check needs at least one authorized channel — with none authorized, it cannot be run yet.
+
+Confirmation is what makes a channel selectable elsewhere in Prowler Cloud. A channel authorized a moment ago is missing from an Alert's channel list until a connection check confirms it.
+
+## Disconnecting a Slack Workspace
+
+Disconnecting removes the integration from Prowler **and** attempts to revoke Prowler's access at Slack.
+
+1. On the Slack management page, click **Disconnect**.
+2. Review the confirmation, then click **Disconnect workspace**.
+
+    ![Disconnect Slack workspace confirmation dialog](/images/prowler-app/slack/disconnect-confirmation.png)
+
+The page returns to its unconnected state, ready for a new install.
+
+### What Revocation Means
+
+Revocation is attempted at Slack, and it is best-effort:
+
+* **Revocation succeeded:** The stored credential no longer grants Prowler anything, and the integration is gone from Prowler.
+* **Revocation failed:** The integration and the stored credential are gone from Prowler either way, so there is nothing to retry. Slack did not confirm the revocation, which means the Prowler app may still be installed in the workspace. Remove it from that workspace's Slack app settings.
+* **Revocation unreported:** Slack's answer carried no outcome either way. The integration is gone from Prowler, and the disconnect is reported without any claim about revocation. When certainty matters, check the workspace's Slack app settings and remove the Prowler app if it is still installed.
+
+Prowler reports the outcome it received: a failed revocation always names the manual cleanup step, and an unreported one is never presented as revoked.
+
+<Warning>
+Disconnecting cannot be undone, and it removes the Slack channels from every Alert that targeted them. Reconnecting means approving Prowler in Slack again, authorizing the destination channels again, confirming them with a connection check, and selecting them again on each Alert that posts to Slack.
+</Warning>
+
+## Integration Status
+
+The Slack management page reports the state of the connection and offers these actions:
+
+| Button | Purpose | Notes |
+|--------|---------|-------|
+| **Test connection** | Verify the credential and every authorized channel, and confirm the ones not confirmed yet | Posts the confirmation message once per channel and updates the last-checked time. Cannot be run until at least one channel is authorized |
+| **Refresh channels** | Re-read the workspace's channel list | Use after inviting `@Prowler` to a private channel |
+| **Save channels** | Record the selected channels as the integration's authorized set | Enabled once the selection differs from the authorized set |
+| **Disconnect** | Remove the integration and attempt to revoke access at Slack | ⚠️ **Cannot be undone** — confirm before disconnecting |
+
+## Troubleshooting
+
+### Slack Is Not Available in This Environment Yet
+
+The Prowler Slack app is not configured for the deployment being used, so no workspace can be connected. This resolves without any action on the tenant's side — the page starts working as soon as the app is configured.
+
+### A Private Channel Does Not Appear in the Channel List
+
+The Prowler app has not been invited to it. In Slack, run `/invite @Prowler` in that channel, then click **Refresh channels**. Membership is the permission: no scope reveals a private channel the app is not in.
+
+### Connection Test Fails
+
+* Confirm every authorized channel still exists and has not been archived. A failure names the channel Slack refused, and the integration reports as connected only when every authorized channel passes.
+* For a private authorized channel, confirm the Prowler app is still a member of it.
+* Confirm the Prowler app is still installed in the workspace.
+
+### A Channel Is Missing From an Alert's Channel List
+
+The channel is authorized here but not confirmed yet. Click **Test connection**: it confirms every authorized channel it has not confirmed, and confirmed channels become selectable on Alerts.
+
+### Prowler's Access Has Been Revoked
+
+When Slack stops accepting the stored credential — because a workspace administrator revoked it, or the app was removed from the workspace — Prowler reports the workspace as disconnected and offers **Reconnect to Slack**. Approving Prowler in Slack again restores access.
+
+### The Connection Check Fails on a Channel
+
+* Check the outcome reported on the page: it names the channel Slack refused and the reason Slack gave — an archived or deleted channel surfaces here rather than failing silently.
+* Confirm that channel is still one of the intended destinations, and that it has not been archived or deleted in Slack.
+* For a private channel, confirm the Prowler app is still a member of it.
+* One unreachable channel is enough to report the integration as not connected, so removing a retired channel from the authorized set clears the failure — bearing in mind that removing it also removes it from every Alert that targeted it.
@@ -10,6 +10,8 @@ import { SubscriptionBanner } from "/snippets/subscription-banner.mdx"

 Prowler Cloud onboards every AWS account in your Organization through a single guided wizard. Instead of connecting accounts one by one, you can discover every account in your AWS Organization, select the ones you want to monitor, test connectivity, and launch scans — all from the Prowler Cloud UI.

+For the cross-provider organization lifecycle and terminology, see [Organizations Across Cloud Providers](/user-guide/organizations).
+
 <SubscriptionBanner>
 For CLI-based multi-account scanning, see [AWS Organizations in Prowler CLI](/user-guide/providers/aws/organizations).
 </SubscriptionBanner>
@@ -266,7 +268,7 @@ Click **Save**, **Save and launch scan**, or **Launch scan**, depending on the s
 After launching:
 - Scans appear in the **Scans** page as they start and complete.
 - Results populate the **Overview** and **Findings** pages.
- Prowler runs an **automatic sync every 6 hours** to detect accounts added to or removed from your Organization. New accounts under the targeted OU or root are onboarded automatically.
+- To detect accounts added to or removed from the AWS Organization, repeat the discovery flow described in [Add or Remove Organization Accounts](#add-or-remove-organization-accounts).

 ## Manage Your Organization After Onboarding

@@ -288,6 +290,24 @@ Open the row actions menu on the organization row on the **Providers** page.

 Organizational unit rows carry the same **Test Connections** and **Delete Organizational Unit** actions, scoped to the accounts beneath them.

+### Add or Remove Organization Accounts
+
+To refresh the account membership of an existing AWS Organization, repeat the same discovery flow used during onboarding:
+
+1. Navigate to **Providers**, click **Add Provider**, and select **Amazon Web Services**.
+2. Choose **Add Multiple Accounts With AWS Organizations**.
+3. Enter the existing **Organization ID**, proceed to **Authentication Details**, and use the existing deployment account **Role ARN**.
+4. Confirm that the stack is deployed and click **Authenticate**. Prowler reuses the existing organization and starts a new discovery instead of creating a duplicate.
+
+The refreshed tree shows the accounts currently returned by AWS Organizations:
+
+- **New accounts** appear in the tree. Select them, test their connections, and save the configuration to connect them as providers. Existing providers and their historical data are preserved.
+- **Accounts that left the Organization** no longer appear in the tree. Discovery does not automatically delete their existing providers. To remove one, return to the **Providers** page, open the account provider actions, and select **Delete Provider**.
+
+<Danger>
+Deleting a provider permanently removes its scans, findings, resources, and other stored data. Confirm that the account has left the AWS Organization and that its historical data is no longer required before deleting it.
+</Danger>
+
 ### Update Organization Credentials

 Choosing **Update Credentials** re-enters the Authentication Details step. Because the organization already holds a credential, Prowler warns before overwriting it and names how many providers re-authenticate with the new one:
@@ -458,16 +478,17 @@ Deploy the ProwlerScan role to every member account with a [CloudFormation Stack
 </Note>

 1. In your management account, navigate to **CloudFormation > StackSets > Create StackSet** ([open directly](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacksets/create)).
-2. Choose **Service-managed permissions** so AWS Organizations deploys the role automatically across current and future member accounts.
-3. Select **Amazon S3 URL** as the template source and paste:
+2. Choose **Service-managed permissions**.
+3. Enable **Automatic deployment** so CloudFormation deploys the role to accounts added to the targeted root or OUs. Configure the account removal behavior based on whether the stack and its resources should be retained when an account leaves the target.
+4. Select **Amazon S3 URL** as the template source and paste:
   ```
   https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml
   ```
-4. Set the **ExternalId** parameter to the External ID shown in the Prowler wizard.
-5. Choose your deployment targets (entire organization or specific OUs) and regions, then click **Create StackSet**.
-6. Open the **Stack instances** tab and confirm every instance shows **Status: CURRENT** and **Stack status: CREATE_COMPLETE**. Deployment typically takes **2–5 minutes**; large organizations (500+ accounts) may take longer.
+5. Set the **ExternalId** parameter to the External ID shown in the Prowler wizard.
+6. Choose your deployment targets (entire organization or specific OUs) and regions, then click **Create StackSet**.
+7. Open the **Stack instances** tab and confirm every instance shows **Status: CURRENT** and **Stack status: CREATE_COMPLETE**. Deployment typically takes **2–5 minutes**; large organizations (500+ accounts) may take longer.

-The StackSet role uses read-only access only (`SecurityAudit`, `ViewOnlyAccess`, plus a small set of additional read-only permissions). Prowler makes no changes to your accounts. See the [CloudFormation template](https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml) for the full list. When you add new accounts under the targeted OU or root, the StackSet deploys the role automatically, and Prowler's 6-hour sync onboards them end-to-end.
+The StackSet role uses read-only access only (`SecurityAudit`, `ViewOnlyAccess`, plus a small set of additional read-only permissions). Prowler makes no changes to your accounts. See the [CloudFormation template](https://prowler-cloud-public.s3.eu-west-1.amazonaws.com/permissions/templates/aws/cloudformation/prowler-scan-role.yml) for the full list. When **Automatic deployment** is enabled, the StackSet deploys the role to new accounts under the targeted OU or root. Repeat the [organization discovery flow](#add-or-remove-organization-accounts) to connect those accounts in Prowler Cloud.

 ## Key Concepts

@@ -152,6 +152,18 @@ export PROWLER_CLOUD_API_KEY="pk_your_api_key_here"
 prowler aws --push-to-cloud
 ```

+### TLS Certificate Trust
+
+For `--push-to-cloud` uploads, Prowler CLI creates one ingestion-scoped TLS context and validates HTTPS certificates with one handshake and one POST request. The upload does not retry or fall back to another TLS configuration. Redirect responses are rejected.
+
+The ingestion context combines the operating system roots with the default certificate authority (CA) roots bundled with Requests. If `REQUESTS_CA_BUNDLE` is configured, Prowler CLI also loads that file or directory into the ingestion context. Otherwise, Prowler CLI loads `CURL_CA_BUNDLE` when configured.
+
+`REQUESTS_CA_BUNDLE` and `CURL_CA_BUNDLE` can also affect other Requests-based connections throughout the Prowler CLI process, including provider authentication. A bundle containing only a private CA can cause connections to public services to fail before the upload starts. Installing the private CA in the operating system or container trust store is recommended. If a custom bundle is required, it must include both the public CA roots, such as the certifi bundle, and the required private CA certificates.
+
+For Prowler Private Cloud deployments that use an organization CA or a TLS-intercepting corporate proxy, installing the required root CA in the operating system or container store remains the recommended approach. Containers have an isolated system CA store, so add the organization or proxy CA to the container image or runtime, then run the operating system's CA update command, such as `update-ca-certificates`, before starting Prowler CLI. Installing a CA on the container host does not automatically install it inside the container.
+
+Prowler CLI does not create, modify, or remove these environment variables. The custom TLS context created by `--push-to-cloud` applies only to the temporary ingestion session and does not change API, provider, integration, global SSL, or unrelated Requests session behavior.
+
 ### Combining with Output Formats

 When using `--push-to-cloud` with custom output formats that exclude OCSF, Prowler generates a temporary OCSF file for upload: