Skip to main content

Compliance Engine Requirements

This page summarizes what you need in place before enabling Cloudaware Compliance Engine across your environment.

Prerequisites​

Before you begin, ensure that:

  • Cloudaware CMDB is populated.
    Core cloud accounts, subscriptions, projects, and on‑prem sources should be onboarded so that the assets you want to govern (accounts, instances, storage, databases, identities, and so on) appear in CMDB.

  • Cloud integrations are healthy.
    AWS, Azure, GCP, and other integrations must be configured with least‑privilege roles or service accounts that allow Cloudaware to discover resources, read configuration and tags, and store inventory in CMDB.

  • Compliance Engine is enabled for your tenant.
    Your Cloudaware organization must have Compliance Engine licensed and turned on. Coordinate with your Cloudaware representative if you are unsure about entitlement.

Cloud Permissions (AWS Example)​

For AWS, the IAM role or user used by Compliance Engine typically requires permissions to:

  • Discover configuration – Describe* APIs for accounts, EC2, RDS, S3, IAM, and other services in scope for policies.
  • Read tags and metadata – access to resource tags, configuration details, and relationships required by policy logic.
  • Write findings – create and update Salesforce‑backed objects representing policy violations and benchmark checks (handled via the Cloudaware connector).

Cloudaware provides reference IAM policies and can help you review them for least privilege.

Similar principles apply to Azure, GCP, and other providers: Compliance Engine needs enough read access to evaluate controls and, where relevant, the ability to resolve relationships and ownership.

Supported Platforms and Scope​

Compliance Engine v1 is designed for:

  • Public cloud platforms – AWS, Azure, and GCP via Cloudaware integrations.
  • On‑prem and other sources – where assets are represented as CMDB classes with the necessary attributes for evaluation.

Policies operate at the CMDB layer, so any class that exposes the right fields (for example, configuration flags, tags, owners, environments) can participate in compliance checks.

Roles and RBAC​

To operate Compliance Engine safely, you should define:

  • Policy authors and approvers – users allowed to create and modify policies and policy packs.
  • Operators – users allowed to schedule evaluations, manage exceptions, and coordinate remediation.
  • View‑only consumers – auditors, application owners, and stakeholders who can view findings, dashboards, and reports but cannot change policy code.

Cloudaware roles and permission sets should be configured so that only appropriate users can deploy or modify policies that affect large portions of your environment.

See Compliance Engine for more details.

Network and Connectivity​

In addition to provider permissions, ensure that:

  • Cloudaware can reach cloud control plane APIs for all regions where you plan to run evaluations.
  • Any integrations used for remediation or notifications (for example, Jira, ServiceNow, Slack, SIEM/SOAR endpoints) are reachable from the Cloudaware platform.
  • Egress controls, firewalls, and proxies are configured to allow the necessary outbound connections.

Coordinate required endpoints and IP ranges with your security team if you operate in a restricted network environment.

Scale and Performance​

Compliance Engine is built to evaluate large environments, but you should account for:

  • Policy batch size and limits – each policy processes input objects in batches; Cloudaware recommends staying within documented limits for batch size to avoid platform timeouts.
  • High‑volume policies – broad benchmark packs and tag‑based controls can touch many objects; schedule them thoughtfully and split into multiple policies where appropriate.
  • Job concurrency – Cloudaware throttles concurrent evaluation jobs to respect provider and platform limits.

If you plan very large benchmark rollouts or heavy historical backfills, coordinate cadence and concurrency settings with Cloudaware Support.

Optional Components​

You may also want:

  • ITSM integrations (for example, Jira, ServiceNow, ServiceDesk) to turn violations into tracked tickets.
  • Collaboration integrations (for example, Slack or Teams) for near real‑time notifications.
  • SIEM/SOAR integrations to stream findings and events into your security tooling; see SIEM/SOAR.
  • Reporting and analytics tooling to build dashboards and evidence packs using Compliance Engine data; see Compliance Engine.

These components are not required to start using Compliance Engine but significantly improve how compliance work is tracked and communicated.