Skip to content
Sencai.docs

Cloud policies

Cloud policies are the guardrail rules Sencai evaluates against your cloud resources. They’re what turns “we have a security standard” into something enforced automatically, rather than something written down and hoped for.

The scoring dashboard is at Compliance & Audit → Compliance in the app (/gravity/inventory/compliance). The policy list itself - where you create and manage individual policies - is at /gravity/policies; it isn’t currently part of the main navigation menu, so open it directly by that URL within the app.

What a policy is

Section titled “What a policy is”

A policy is a named rule with:

  • A severity - block or warn (see below for what each does)
  • A provider scope - a specific cloud provider, or “all providers”
  • An optional resource type scope - narrow it to a specific kind of resource, or leave it unset to apply to all resource types the provider scope covers
  • A condition (optional) - the logic that decides whether the policy triggers. A policy with no condition triggers on every matching resource.

Built-in vs. custom policies

Section titled “Built-in vs. custom policies”

The Compliance screen shows two separate lists:

  • Built-in policies - a platform-wide, CIS-aligned default set. These are read-only: you can see them and see whether they’re active, but you can’t edit or delete them from this screen.
  • Custom policies - rules your organization defines. You can create, activate/deactivate, and delete these.

Creating a custom policy

Section titled “Creating a custom policy”

Creating a policy requires the Member role or above; changing an existing one’s settings (including toggling it active or deleting it) requires Admin or Owner.

From the Custom policies panel, choose New policy and fill in:

  1. Name and an optional description.

  2. Severity - block or warn.

  3. Provider - a specific provider or “All providers”.

  4. Resource type - e.g. an instance type keyword, or leave it to cover everything the provider check applies to.

  5. Condition - a small JSON structure describing what to check. Conditions combine comparisons with and/or:

    {"and":[{"field":"config.public_access","op":"eq","value":true}]}

    Each comparison is {"field": "<dot-path into the resource's configuration>", "op": "<eq|neq|contains|exists|not-exists|gt|lt>", "value": <expected value>}. Leaving the condition empty makes the policy trigger on every resource it applies to (useful for a blanket warn on a whole resource type, less useful for a block).

There’s no separate rule-builder UI beyond this form - the condition is authored directly as this JSON structure. If you need help constructing one, your account team can review a condition with you before you switch it to block.

  1. Toggle Active, and save.

Scoping a policy

Section titled “Scoping a policy”

A policy applies to the intersection of its provider and resource type fields, plus whatever its condition checks. There’s no separate resource-picker or tag-based targeting - if you need a policy to apply only to a subset of resources beyond provider/type, express that inside the condition (for example, a condition checking a specific tag value).

How scoring works

Section titled “How scoring works”

The Compliance dashboard aggregates every active policy against your current inventory and shows:

  • An overall score (percentage of evaluations passing) with the count of resources and evaluations behind it
  • Findings - every resource that currently fails an active policy, with the policy name, the affected resource, its provider and region, severity, and (where applicable) which compliance framework controls the finding maps to
  • A per-framework breakdown (the built-in set is aligned to CIS AWS Foundations, ISO 27001, and NIS2) and a per-provider breakdown
  • CSV and PDF export of the findings, for attaching to an audit package

Findings reflect your current inventory against currently active policies - the score is a live snapshot, not a historical trend line kept per policy version.

What happens on violation: report vs. block

Section titled “What happens on violation: report vs. block”

This is the part worth understanding precisely, because the two severities behave completely differently:

  • block policies are evaluated before a new provisioning or update job runs. If a request would violate a block policy, the job is refused and nothing is created or changed - the guardrail acts before the fact.
  • warn policies also run at provisioning time, but only log the violation and let the job proceed.
  • Policies against your existing inventory (resources that already existed, or that were created before a policy became active) don’t get retroactively blocked - they show up as findings on the Compliance dashboard instead, which is how you find and fix already-drifted resources.

Exceptions

Section titled “Exceptions”

There’s no separate exception or waiver workflow today - a policy applies to everything that matches its provider/resource-type/condition scope, for every resource in your organization. If a specific resource genuinely needs to be exempt, the available options are to narrow the policy’s own scope (a tighter resource type or condition), lower its severity from block to warn, or deactivate it. There’s no per-resource “except this one” toggle.

How policy results feed evidence

Section titled “How policy results feed evidence”

Every policy creation, update, and deletion - and every block/warn decision made during provisioning - is written to Sencai’s audit log. The compliance score you see on this page is the current snapshot; the NIS2 evidence timeline is where you go for the underlying history of what changed and when.

What’s next

Section titled “What’s next”