Skip to main content

Compliance Engine FAQ

This FAQ answers common questions about Cloudaware Compliance Engine.

What Types of Controls Does Compliance Engine Provide Out of the Box?​

Cloudaware ships Compliance Engine with:

  • Benchmark‑based packs such as CIS Benchmarks for AWS, Azure, and GCP.
  • Hundreds of Cloudaware‑authored policies that check security, reliability, operational excellence, and cost controls.
  • Additional controls mapped to common frameworks such as PCI, HIPAA, NIST, ISO, GDPR, and others.

You can enable these packs as‑is, selectively deploy specific policies, and add your own custom policies where you have organization‑specific requirements.

How Does Compliance Engine Decide Which Resources Are in Scope?​

Scope is defined by each policy:

  • Every policy targets one or more CMDB object types (for example, AWS Account, EC2 Instance, S3 Bucket, Azure Subscription, Google Project).
  • Policies typically include a filter or query to restrict evaluation to specific environments, tags, regions, or ownership groups.
  • Policy packs provide default scoping that you can tighten or relax based on your risk appetite.

If an object no longer meets the policy’s scoping criteria (for example, it is deleted or moved out of scope), its corresponding finding is closed as “out of scope” while preserving history for reporting.

See Scoping & Targeting and Status Transitions for details.

How Often Are Policies Evaluated?​

Each policy can be:

  • Run on a schedule (for example, hourly, daily, weekly) for continuous monitoring.
  • Run on demand to validate changes or perform spot checks.

Organizations often run high‑impact, low‑volume policies more frequently and batch‑heavy policies (for example, large benchmark packs) less frequently to balance freshness and cost.

See Evaluation Cadence for guidance.

What Statuses Can a Finding Have?​

Compliance Engine uses a state model that distinguishes:

  • Compliant – the asset currently satisfies the policy’s conditions.
  • Incompliant – the asset violates the policy’s conditions.
  • Inapplicable – the policy does not apply (for example, prerequisites are not met).
  • Closed / Out of Scope – the asset is no longer in scope for the policy (for example, deleted or moved).

Findings track start/end timestamps for each status to support KPIs such as mean time to remediate and exception aging.

How Are False Positives and Exceptions Handled?​

Cloudaware supports several patterns:

  • Tuning policies – adjust filters and conditions so that genuinely non‑applicable resources are excluded.
  • Exceptions and risk acceptance – record why a violation is acceptable for a given resource, for how long, and who approved it.
  • Temporary suppressions – suppress findings while remediation is in progress or a change is being validated.

Exceptions can be time‑boxed, reviewed periodically, and reported separately so that auditors can distinguish between unresolved risks and consciously accepted ones.

How Does Compliance Engine Integrate With Tickets and Workflows?​

Policy violations and benchmark checks are stored as first‑class objects in Cloudaware. You can:

  • Create and synchronize tickets in systems like Jira and ServiceNow based on new or updated violations.
  • Use email alerts and workflow rules to notify distribution lists or teams.
  • Trigger automation and remediation playbooks via webhooks or integrations.

Review Ticketing, Email Alerts, and Automation for patterns.

Can Auditors and Customers Access Compliance Evidence?​

Yes. Compliance Engine findings and benchmark checks can be:

  • Surfaced via dashboards that show control pass rates, open violations, and remediation trends.
  • Exported to reports or evidence packs for specific audits, customers, or regulators.
  • Scheduled as recurring posture summaries delivered to stakeholders.

Because findings are stored as structured objects with timestamps and history, they provide traceable evidence of when a control failed, when it was fixed, and how long it remained incompliant.

What Happens If We Later Move to Compliance Engine v2?​

This documentation describes Compliance Engine v1. Cloudaware’s Compliance Engine v2 offering introduces a new architecture and UI while preserving the core idea of CMDB‑backed, policy‑driven compliance.

Existing v1 findings and policies remain as historical evidence. Your Cloudaware representative can help you plan a migration path that preserves required data for auditors while enabling new capabilities in v2.