Skip to main content

Policy Anatomy

This guide describes the main components of a Cloudaware Compliance Engine policy and how they work together to evaluate compliance.

At a high level, each policy defines:

  • Target (input object type) – the CMDB class being evaluated (for example, AWS Account, EC2 Instance, S3 Bucket, Azure Subscription, Google Project).
  • Output object type – the object used to store results (for example, CloudAware Policy Violation or CloudAware Benchmark Check).
  • Scope query – which instances of the target class are in scope (for example, only production accounts, only resources with specific tags, or only resources in certain regions).
  • Evaluation logic – the condition under which a resource is considered compliant, incompliant, or inapplicable.
  • Lifecycle configuration – how and when findings are created, updated, closed, or deleted.
  • Metadata – severity, category, labels, and descriptive text for use in dashboards and reports.

Targets and Outputs​

Policies operate on CMDB object types. For each policy you choose:

  • A single input object type the policy evaluates.
  • An output object type that will store evaluation results for each matching input object.

Most general‑purpose controls use CloudAware Policy Violation as the output object. CIS benchmark policies typically use CloudAware Benchmark Check objects. These objects are then available for dashboards, reports, and workflows.

Once a policy is deployed, the input and output object types are fixed to preserve data integrity.

Scope and Queries​

Each policy includes a query that defines which objects it will evaluate. This can reference:

  • Environment (for example, production vs. non‑production).
  • Account, subscription, or project.
  • Region or location.
  • Tags and labels (for example, application, owner, data sensitivity).
  • Other configuration attributes stored in CMDB.

Thoughtful scoping helps you avoid noisy findings and align policies to how your organization segments risk.

Evaluation Logic​

Within the policy code, you define how each input object is evaluated. Common patterns include:

  • Checking for the presence or absence of specific configuration flags or tag values.
  • Evaluating numeric thresholds (for example, password age, key rotation interval, backup retention).
  • Aggregating related objects (for example, ensuring all volumes attached to a critical instance are encrypted).

Based on this logic, the policy assigns one of three statuses to each output object:

  • Compliant
  • Incompliant
  • Inapplicable

See State Model for more on how these statuses behave over time.

Lifecycle and Batch Processing​

Policy lifecycles control when findings are created, closed, or deleted. Examples include:

  • Creating findings only when resources are incompliant.
  • Closing findings when resources become compliant or move out of scope.
  • Deleting long‑closed findings after a certain number of days to reduce clutter.

Policies process input objects in batches. Cloudaware provides configurable batch size settings so that you can balance throughput against platform limits.

Metadata and Labels​

Finally, each policy includes descriptive metadata used throughout Compliance Engine:

  • Name and description – what the control checks and why it matters.
  • Severity and category – used to sort and prioritize findings.
  • Labels – used to group policies into packs, frameworks, or initiatives.

Good metadata makes it easier for owners, auditors, and stakeholders to understand the impact of each policy and to filter dashboards and reports.