Sysdig’s Compliance feature continues to evolve and the new Compliance module represents the next phase of maturity, as well as the first to support CSPM/KSPM. The Compliance module now relies on persisting the resources in an inventory; this enhanced resource visibility and full-context prioritization drives remediation and resolution of violations.

  • If you are an on-prem Compliance user, see Legacy Compliance.

  • Compliance is not available for Managed Falco (secure light).

What’s New with Compliance

  • Compliance that is Actionable
    • The new CSPM Compliance lets you manage your risks if you have the required permissions:
      • Remediate
      • Accept the risk
      • Open a Pull Request in your code repository - if Git IaC integration is enabled
  • Collected Violations
    • The resources of your zones are evaluated against compliance policies; the violations are collected into tiles and shown on the Compliance page.

    • The new approach relies on the common process of fetching the resources once per day into the backend and performing the relevant analysis of policies.

    • You can create custom policies or use Sysdig out-of-the-box policies.

  • Click the resource itself, rather than a list of violations.
  • A variety of terminology changes
  • Downloadable reports and the APIs to support reporting

For Legacy Compliance Users:

Note that Compliance and (legacy) Unified Compliance can be run in parallel. When the benchmarks have reached End of Life (EOL), the data collection will be only on Compliance and the Legacy Reports will be available on the interface for a year from creation date.

There is no plan to transfer data between compliance versions.

Typical Use Cases

Compliance/Security Team Members

Will want to:

  • Check the current compliance status of their business zones against predefined policies
  • Demonstrate to an auditor the compliance status of their business zone in a specific point in time (the audit)
  • Create a report of the compliance status of their business zone, and share it with their auditors and the management team
  • Understand the magnitude of the compliance gap

DevOps Team Members

Will want to:

  • Identify the compliance violations of a predefined policy applied on their business zones
  • Manage the violations according to their severity
  • Easily fix the violation
  • Document exceptions and accept risk according to the risk management policy of their organization

Path from Detection to Remediation

Below is a quick overview of how users work through the Compliance screens to detect prioritized vulnerabilities, analyze them, and remediate them.

  1. Compliance Page: Get high-level posture performance indicators (PPIs) on each of the policies applied applied on your zones:

    Your zones are ordered alphabetically. The results under each zone are ordered by the passing score, lowest first, to help you focus on improving your scores.

  2. Select a Policy to see its Results and select a failing requirement to see the Controls and failing resources that comprise it.

  3. Start Remediation to open the Remediation panel.

  4. Begin remediation (where possible). The remediation flow allows you to understand exactly what the issue is, to review the remediation that Sysdig created specifically for the problem, and choose how to apply a fix (manually or in your Git repository).

    • Manually, you can copy the code and apply it in production.
    • To remediate in the code repository, you can choose the relevant Git source and Compliance will create a pull request integrating the fix (as well as checking for code formatting cleanup). You can review all the changes in the PR before you merge.
  5. You can Accept the Risk (temporarily or forever) and remove the violation from the failed controls. Risk can be accepted at the level of an individual resource, or globally on a control for all resources that match a given zone.

  6. Download a report as a CSV/spreadsheet of your compliance results for development teams, executives, or auditors (optional).

The rest of the page describes the screens and actions in detail.


Follow the installation guide to connect new cloud accounts or Kubernetes clusters to Sysdig Secure.

Make sure to include --set global.kspm.deploy=true \ while installing Sysdig Agent.

CSPM Zones Management

On the Compliance landing page, a default Entire Infrastructure zone is automatically created. CIS policies and the Sysdig Kubernetes policy are automatically added to the Entire Infrastructure zone.

To see results from any of the dozens of out-of-the-box policies provided with the Compliance module, or for any custom policies, you must apply them to a zone.

Go to Policies > Risk and Compliance > Zones to create, edit, and/or apply policies to Zones.

  1. Select Posture > Compliance.

  2. Review the compliance posture for each of your zones. Each row or tile shows the compliance results of a policy that is applied to your zone.

    The zones are ordered alphabetically. The default Entire Infrastructure zone was created by Sysdig. Edit the default applied posture policies for this zone, and create your own zone on the Zones management page.

    The rest of the tiles are ordered alphabetically until custom filters are applied.

    • Zones / Policies: This is the lens to evaluate your compliance results through your zones and the policies you applied to them.

    • Passing Score: The number of requirements passing for this policy view, expressed as a percent. The higher the better.

    • Requirements Failing: The number of requirements remaining to fix to get to 100% for a view, listed as a bar chart of the past 7 days’ results. The smaller the number, the better. Requirements are made up of one or more controls, so requirements will be the smaller number.

    • Controls to Fix: The number of controls to fix to achieve a perfect score. The smaller the better. (Multiple controls make up a single requirement, so the control count will be larger than the requirement count).

    • Resources Passing: The percent of resources passing (or accepted) out of all resources evaluated. Resources are the most granular of your results. The higher the percentage, the fewer individual resources failing, the better.

    • Violations by Severity: Every control has a Severity (high/medium/low) set by Sysdig. Resource Violations are the number of resources failing, organized by severity. One resource can be counted multiple times if it’s failing multiple controls. The lower, the better.

    • Starred Views: Select/deselect stars to add or remove from Favorites. You can filter the policy list by Favorites and favorited policies affect the Posture policy data on the Home page. See Star Favorite Compliance Views, below.

  3. Select a tile to drill into the results of a particular policy.

Star Favorite Compliance Views

Starred (favorite) views of policies and zones affect the compliance results trend displayed on the Home page.

To use:

  1. Select Posture > Compliance

  2. Click the stars beside any policy/zone view you would most like to see reported on the Home page.

  3. Select Home and scroll to the Posture section to see the results.

    If no views are starred, the three with the lowest scores will be shown. If there are more than three with the same lowest scores, then they are listed alphabetically by policy name.

Additionally, when returning to the Compliance landing page:

  • Click My Favorites to see only the starred policies on the Compliance Overview.

Review and Filter Results

  1. Select Posture > Compliance, then select a particular tile to see the Results page.

    The failed requirements are sorted by severity and importance. See at a glance:

    • Controls Failed: controls that failed out of total controls
    • Policy/Control Type: Including logos for visual cues and hover-over for all available types
    • Severity: High/Medium/Low columns
    • Accepted: Number of accepted risks
    • Passing: Number of passing controls
    • Accept Risk: Global risk acceptance for the control
  2. You can edit the filters to focus on the compliance results that are relevant to you. The Compliance results page presents the policy requirements for the selected zones and policies, and the controls under each requirement.

Accept Risk Globally on a Control

Ensure that you have the required permission to use this feature.

In addition to accepting the risk on a single resource, you can accept risk for an entire control, affecting all resources that match the given zone.

  1. Select Posture >Compliance, then select a particular tile to see the Results page.

  2. Hover over a control to display the Accept Risk button on the Results list and click.

  3. Fill out the required fields to comply with audit best practices and click Save.

    Reason: Risk Owned, Transferred, Avoided, Mitigated, Not Relevant, or Custom. See also: Reasons for Accepting Risk.

    Reason: Explain to an auditor the reason for accepting the risk or select the risk management action taken.

    Expires In: Select when you want this acceptance to expire and the resource to fail. Options: 7/30/60/90 days, Custom time frame, Never.

    Expiration Date: Enter manually when Expires In is set to Custom, otherwise autocompleted.

Later, you can filter violations by Accepted status to address them or go to the Accept Risk management panel. A global accept appears on the Accept Risk management page under “Context” showing Where: All Resources.

Reasons for Accepting Risk

Owned: Accept cybersecurity risk within risk tolerance levels. No additional risk response action is needed except for monitoring.

Transferred: For cybersecurity risks that fall outside of tolerance levels, reduce them to an acceptable level by sharing a portion of the consequences with another party (e.g., cybersecurity insurance). While some of the financial consequences may be transferrable, there are often consequences that cannot be transferred, like the loss of customer trust. (Sometimes referenced as Sharing.)

Avoided: Take actions to eliminate the activities or conditions that give rise to risk. Avoiding risk may be the best option if there is no cost-effective method for reducing the cybersecurity risk to an acceptable level. The lost opportunity cost associated with such a decision should also be considered.

Mitigated: Apply actions that reduce a given risk’s threats, vulnerabilities, and impacts to an acceptable level. Responses could include those that help prevent a loss (i.e., reducing the probability of occurrence or the likelihood that a threat event materializes or succeeds) or that help limit such a loss by decreasing damage and liability.

Not Relevant: The risk does not pose a threat or impact that warrants any specific action or response. Organizations may decide that certain risks are outside the scope of their operations, or that the likelihood or potential impact of the risk is negligible compared to other priorities. However, it’s important to thoroughly assess and document the rationale behind deeming a risk Not Relevant to ensure comprehensive risk management.

Custom: This involves devising unique strategies to address cybersecurity risks that don’t align with standard response types. Tailored to fit the organization’s specific circumstances and risk tolerance, these responses may combine existing measures with innovative approaches to effectively mitigate identified risks.

Drill Down to the Control Pane

From the Results page, open a requirement to see the individual failing controls. Click a control to open the Control pane on the right and review the resources that were evaluated by the control.

Here you can see:

  • A description of the control
  • An overview of all resources that have passed, failed, or had their risks temporarily accepted
Filters in the Control Pane

The Control pane shows the top 50 results. Use filters to find additional resources.

You can construct filter expressions in the Control pane on all resource fields:

For each of the following Control Types, you can refine your search in the mini-inventory using the associated attributes:

Kubernetes Identity

  • Cluster
  • Labels
  • Name
  • NamespaceType (= Resource Type in Inventory) - ex: Group, ServiceAccount, User

Kubernetes Resource

  • Cluster
  • Labels
  • Name
  • Namespace
  • Type (= Resource Type in Inventory) - ex: Deployment, Daemonset, StatefulSet, ReplicaSet, Pod, Job, CronJobHost (K8s, Linux, Docker)

Host (K8s, Linux, Docker)

  • Cluster
  • Name
  • OS (= Operating System in Inventory)
  • OS Image

Managed Cloud Identity & Resource (AWS, GCP, Azure)

  • Account
  • Location (= Region in Inventory)
  • Name
  • Organization

Select a failing resource to review its remediation guidelines and take action toward its remediation.

Evaluate and Remediate

The remediation solutions are under continued development in the product.

Some remediation flows are manual, while others offer different degrees of automation.

Sysdig can present a fix to be manually applied to production, or it can fix the resource via the creation of a Pull Request with the required changes directly in the Git repository that has been previously configured as an IaC integration.

Currently, most risk response actions are for a single resource for a single violation. Several types of risk responses are supported:

  • Manual Remediation: Playbook text to remediate the violation is presented
  • Automatically generate a patch (with or without user input): Patch code is presented with an input field if new values are required, and the user downloads the patch and copy/pastes the patch application code.
  • Set up an Automatic Pull Request (with or without user input): Patch code is presented, with an input field if new values are required, and the user opens a PR. Ensure that you have the required permission to use this feature.
  • Accept the Risk on a resource.

Remediation: How Do Source Detection and Fixing Work?

Source Detection

When applying remediation to a resource, Sysdig tries to identify the matching source file from your configured Git integrations. If there are multiple candidates, or if finding the matching source file is impossible, you can use the search field to manually explore and select the relevant file from the connected Git repositories.

Pull Requests (PRs)

When using Pull Request for remediation, Sysdig will create a branch directly in your Git repository, fixing the offending resource with corrective changes. You can review all the suggested changes in the PR before you merge it.

For more information, see IaC integration configuration instructions.

Review the Remediation Pane

Select a Resource to open the Remediation pane on the right. This pane will differ depending on the specific control and resource evaluation.

If remediation code is available, and Git integration has been set up, then the full remediation pane will be displayed. If there is more than a single possible matching file for the resource, all the candidates are displayed as “Suggested Sources”. If no candidates are displayed or you want to choose a different file, you can click the “Search Source” button to manually select from the list of possible files in the connected Git repositories.

Review Issues

Here you see the impact of the remediation, review the resource attributes, and, if relevant, enter a necessary Value that will be incorporated into the patch code.

If a required value can be autodetected, it will be auto-inserted and the Value input field will be read-only.


The code is presented for review when there is a remediation that can be applied manually or used in a Pull Request to remediate the IaC file. In most cases, it is recommended to download the code in the Continue Remediation section, but you can also copy/paste it.

Continue Remediation - Manual

If you have not integrated your Git repository with Sysdig’s IaC Scanning, or if creating a pull request is not required in a particular resource failure, then you can perform remediation manually.

Use the button to download and apply the provided code.

Continue Remediation - Pull Request

Ensure that you have the required permission to use this feature.

After configuring IaC Scanning in your account, Sysdig will scan and analyze the manifests and modules from your defined Git sources, and scrape resources declared in your source files. The scan process runs daily or whenever a new Git source is added.

Sysdig tries to match and identify the resources discovered from the IaC Scanning with the deployed and evaluated resources.The best matches are listed under “Suggested Sources” in the Remediation pane when setting up a Pull Request.

You can also search manually for sources by their full URL path.

Use the button to Open a Pull Request.

  • Workflow Name Selector for Helm/Kustomize:

    What is it: You select a source of type Helm/Kustomize. You can type a selector for the workload name. Why: In Helm, in most cases, workload names are derived from the release name, which means that they change with every new release. The selector is a regular expression that matches workloads by prefix/suffix (or a more complex pattern). With that selector in place, the remediation can be used for the workloads generated from the same chart, regardless of the release.

    Note that Sysdig will create a new Pull Request in your repository with the suggested fixes, and depending on your Git source configuration, Sysdig can run a Pull Request Policy Evaluation that might report other unfixed control violations.

    See also: Pull Request Policy Evaluation.

Option: Accept Risk on a Resource

Ensure that you have the required permission to use this feature.

A failing control can be temporarily accepted so the resource will pass and the compliance score will improve. To do so:

  1. Click the Accept Risk button on the remediation pane.

  2. Fill out the required fields, to comply with audit best practices, and click Save.

    Reason: Risk Owned, Transferred, Avoided, Mitigated, Not Relevant, or Custom. See also: See also: Reasons for Accepting Risk.

    Details: Explain to an auditor more details about the reason for accepting the risk

    Expires In: Select when you want this acceptance to expire and the resource to fail. Options: 7/30/60/90 days, Custom time frame, Never

    Expiration Date: Manually entered when Expires In is set to Custom, otherwise autocompleted

  3. Later, you can filter violations by Accepted status to address them or go to the Accept Risk management panel.

Create and Download a Report

To meet compliance goals, an organization may need to generate output to be shared with other stakeholders, such as executives or auditors, to show point-in-time compliance/violations.

Reports could also be used for sharing compliance results with your development teams. Also consider using APIs. For details, see CSPM APIs .

You can download ad hoc reports as CSV files from the Compliance Results page or from an individual control.

To generate a report of Compliance results:

  1. Select Posture > Compliance.

  2. Select a tile of a requirement under one of your zones.

  3. Optional: filter as desired. For example: by dates, by pass/fail status, by controls, and so on. You can select more than one policy for a single zone. The maximum report size of 10 MB.

  4. Click Download Report.

    A file is downloaded in a CSV (Comma-Separated-Values) format and can be used as a spreadsheet.

To generate a report from an individual control:

  1. Select Posture > Compliance.

  2. Select a tile of a policy under one of your zones.

  3. Select a control to open the control pane, filter the resources if desired, and click the “Download Report” button.

    The maximum report size is 10 MB.

Use the CSPM API

When your organization uses a third-party system to receive remediation reports and create tasks, consider using the CSPM APIs.

These are documented online along with the rest of the Sysdig Secure APIs.

For API doc links for additional regions or steps to access them from within the Sysdig Secure UI, see the Developer Tools overview.

Compliance Results API Call (Requirements)
  • Please specify a zone in the request. If a zone is not specified in the request, results will be returned for policies applied on the default “Entire Infrastructure” zone.
  • If no policy is applied on the default “Entire Infrastructure” zone, you will receive empty results.
  • Note that URL Links to every Control Resource List API call are contained in the Compliance Results Response.

Terminology and Policies

Terminology Changes

Previous TermNew Term
Framework, BenchmarkPolicy
The policy is a group of business/security/compliance/operations requirements that can represent a compliance standard (e.g. PCI 3.2.1), a benchmark (e.g. CIS Kubernetes 1.5.1), or a business policy (e.g. ACME corp policy v1).

You can review the available policies and create custom CSPM/Posture policies under Policies
A business group of resources for a specific customer, defined by a collection of Scopes of various resource types, calculated by “OR” operators
ControlRequirement (or Policy Requirement)
A requirement exists in a single policy and is an integral part of the policy. The requirement represents a section in a policy with which compliance officers & auditors are familiar.
FamilyRequirements Group
Group of requirements in a policy
A control defines the way we identify the issue (check) and the playbook(s) to remediate the violation detected.
Vulnerability ExceptionRisk Acceptance
The new module now includes the ability for a user to review a violation or vulnerability, not yet remediate it, and acknowledge it without making it fail the policy.

Posture Policies Included

The following posture policies are included out of the box:

  • National Institute of Standards and Technology (NIST)

    • NIST SP 800-53 Rev 5
    • NIST SP 800-53 Rev 5 Privacy Baseline
    • NIST SP 800-53 Rev 5 Low Baseline
    • NIST SP 800-53 Rev 5 Moderate Baseline
    • NIST SP 800-53 Rev 5 High Baseline
    • NIST SP 800-82 Rev 2
    • NIST SP 800-82 Rev 2 Low Baseline
    • NIST SP 800-82 Rev 2 Moderate Baseline
    • NIST SP 800-82 Rev 2 High Baseline
    • NIST SP 800-171 Rev 2
    • NIST SP 800-190
    • NIST SP 800-218 v1.
  • Federal Risk and Authorization Management Program (FedRAMP)

    • FedRAMP Rev 4 LI-SaaS Baseline
    • FedRAMP Rev 4 Low Baseline
    • FedRAMP Rev 4 Moderate Baseline
    • FedRAMP Rev 4 High Baseline
  • Defense Information Systems Administration (DISA) Security Technical Implementation Guide (STIG)

    • DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG)
    • DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category I (High)
    • DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category II (Medium)
    • DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category III (Low)
    • DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6
    • DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6 Category I (High)
    • DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6 Category II (Medium)
  • Center for Internet Security (CIS) Benchmarks

    • CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.2.0
    • CIS Amazon Web Services Foundations Benchmark v1.5.0
    • CIS Azure Kubernetes Service (AKS) Benchmark v1.3.0
    • CIS Critical Security Controls v8
    • CIS Distribution Independent Linux Benchmark (Level 1 - Server) v2.0.0
    • CIS Distribution Independent Linux Benchmark (Level 2 - Server) v2.0.0
    • CIS Distribution Independent Linux Benchmark (Level 1 - Workstation) v2.0.0
    • CIS Distribution Independent Linux Benchmark (Level 1 - Workstation) v2.0.0
    • CIS Docker Benchmark v1.5.0
    • CIS Google Cloud Platform Foundations Benchmark v2.0.0
    • CIS Google Kubernetes Engine (GKE) Benchmark v1.4.0
    • CIS Kubernetes V1.15 Benchmark v1.5.1
    • CIS Kubernetes V1.18 Benchmark v1.6.0
    • CIS Kubernetes V1.20 Benchmark v1.0.0
    • CIS Kubernetes V1.23 Benchmark v1.0.0
    • CIS Kubernetes V1.24 Benchmark v1.0.0
    • CIS Microsoft Azure Foundations Benchmark v2.0.0
    • CIS Red Hat OpenShift Container Platform Benchmark v1.2.0
  • Amazon Web Services (AWS) Best Practices

    • AWS Well Architected Framework
    • AWS Foundational Security Best Practices
  • Regulatory Compliance Standards

    • System and Organization Controls (SOC) 2
    • Health Insurance Portability and Accountability Act (HIPAA)
    • Payment Card Industry Data Security Standard (PCI DSS) v3.2.1
    • Payment Card Industry Data Security Standard (PCI DSS) v4.0
    • NSA/CISA Kubernetes Hardening Guide
    • General Data Protection Regulation (GDPR)
    • ISO/IEC 27001:2013 v2
    • ISO/IEC 27001:2022 v1
    • Health Information Trust Common Security Framework (HITRUST CSF) v9.4.2
  • Risk Frameworks

    • All Posture Findings
    • MITRE ATT&CK for Enterprise v10.1
  • Sysdig Best Practices

    • Sysdig Kubernetes - based on Sysdig’s security research and best practices
    • Sysdig IBM Cloud Kubernetes Service (IKS) Benchmark
    • Sysdig Mirantis Kubernetes Engine (MKE) Benchmark
    • Sysdig Rancher Kubernetes Engine (RKE2) Benchmark
  • Other Policies

    • Lockheed Martin Cyber Kill Chain
    • OWASP Kubernetes Top Ten

Cloud Coverage

The following cloud services are covered:

  • Amazon Web Services (AWS)

    • Amazon CloudFront
    • Amazon CloudWatch
    • Amazon DynamoDB
    • Amazon EC2
    • Amazon EC2 Auto Scaling
    • Amazon Elastic Block Store (EBS)
    • Amazon Elastic Container Registry (ECR)
    • Amazon Elastic Container Service (ECS)
    • Amazon Elastic File System (EFS)
    • Amazon Elastic Kubernetes Service (EKS)
    • Amazon ElastiCache
    • Amazon Elasticsearch Service
    • Amazon OpenSearch Service
    • Amazon RDS
    • Amazon Redshift
    • Amazon Simple Notification Service (SNS)
    • Amazon Simple Storage Service (S3)
    • Amazon VPC
    • AWS Account
    • AWS CloudFormation
    • AWS CloudTrail
    • AWS CodeBuild
    • AWS Config
    • AWS Identity and Access Management (IAM)
    • AWS Key Management Service (KMS)
    • AWS Lambda
    • AWS Region
    • AWS Secrets Manager
    • AWS VPN
    • Elastic Load Balancing (ELB)
  • Google Cloud

    • Anthos
    • API Gateway
    • App Engine
    • Artifact Registry
    • Assured Workloads
    • BeyondCorp Enterprise
    • BigQuery
    • Certificate Authority Service
    • Cloud Bigtable
    • Cloud Composer
    • Cloud Data Fusion
    • Cloud Data Loss Prevention
    • Cloud DNS
    • Cloud Domains
    • Cloud Functions
    • Cloud Healthcare API
    • Cloud Intrusion Detection System (IDS)
    • Cloud Key Management Service (KMS)
    • Cloud Logging
    • Cloud Monitoring
    • Cloud Resource Manager
    • Cloud Run
    • Cloud Spanner
    • Cloud SQL
    • Cloud Storage
    • Cloud TPUs
    • Compute Engine
    • Container Engine
    • Container Registry
    • Database Migration Service
    • Dataflow
    • Dataplex
    • Dataproc
    • Datastream
    • Deployment Manager
    • Dialogflow
    • Document AI
    • Eventarc
    • Filestore
    • Firestore
    • Game Servers
    • Google Cloud Billing API
    • Google Cloud Virtual Network
    • Google Kubernetes Engine (GKE)
    • Identity and Access Management (IAM)
    • Integration Connectors
    • Managed Service for Microsoft Active Directory (Managed Microsoft AD)
    • Memorystore
    • Network Connectivity
    • Network Management
    • Network Services
    • Organization Policy API
    • Pub/Sub
    • Secret Manager
    • Service Directory
    • Service Management API
    • Speech-to-Text
    • Transcoder API
    • Vertex AI
    • Virtual Private Cloud (VPC)
    • Workflows
  • Microsoft Azure

    • AKS
    • AppService
    • Authorization
    • Compute
    • Event Hub
    • Key Vault
    • Logging
    • Managed Identity
    • Monitor
    • MySQL
    • Network
    • Operational Insights
    • Operations Management
    • PostgreSQL
    • Security
    • Service Bus
    • SQL
    • Storage
    • Subscription
    • Web

Legacy Compliance Versions

  • Users running older versions of Sysdig Secure may encounter different Compliance UI and features.

  • For on-prem and legacy Compliance Versions, see Unified Compliance.

Migration Guide

For users migrating to the Compliance module, released January 2023:

  • Starting January 17th, SaaS users that connect new data sources for Sysdig cloud accounts or Sysdig agents will automatically have the new Compliance module (previously known as “Actionable Compliance”) enabled.

    Resources of the connected data sources will be evaluated according to CSPM/Risk and Compliance policies that are applied to zones. Results are displayed about 5-10 minutes after connection, varying by the scale of the resources.

  • If you were using Unified Compliance:

    • On existing Kubernetes clusters, ensure the applied helm charts are updated according to the KSPM Components guide.
    • For Existing GCP cloud accounts, enable the Cloud Asset API.
    • The new Compliance module will be auto-enabled on your existing Cloud accounts by January 26th.
  • Currently, the new CSPM Compliance module is not available for on-prem users; they could continue using Unified Compliance

Topics in This Section
Compliance Legacy Versions