Compliance & Policies

Sencai includes a built-in policy engine that evaluates your cloud resources against rules you define. Violations are surfaced through compliance scoring, and policy checks run automatically whenever a cloud resource is provisioned or updated.

Policy engine

Policies are guardrail rules that apply to cloud resources. Examples:

“All EC2 instances must have a cost-center tag”
“No S3 buckets should be publicly accessible”
“VMs in the production environment must run in the EU region”

Policies are defined using a simple JSON DSL — not OPA/Rego or Cedar. A policy expression is a tree of and / or nodes with leaf conditions:

{
  "and": [
    { "field": "config.public_access", "op": "eq", "value": true },
    { "field": "config.region", "op": "neq", "value": "eu-central-1" }
  ]
}

Each leaf node has the shape:

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

field — a dot-path into the resource payload submitted with the provisioning/update request (e.g. config.public_access)
op — one of eq, neq, contains, exists, not-exists, gt, lt
value — the value to compare against (omitted for exists / not-exists)

Author and manage policies at Cloud Instances → Policies (/gravity/policies). This page provides a form for the policy’s name, severity, provider, resource type, and active flag, plus a text field for the JSON DSL expression itself — there is currently no separate visual drag-and-drop policy builder; the expression is written directly as JSON.

Sencai ships a set of built-in, platform-wide CIS-aligned policies (read-only, cannot be edited or deleted by organisation users) alongside any custom policies you create for your organisation.

Enforcement modes

Each policy has exactly one severity value, which doubles as its enforcement mode — there is no separate “set severity” step distinct from enforcement:

Severity	Behaviour
block	The triggered condition rejects the provisioning/update request outright — the resource is not created or modified, and the caller receives an error
warn	The request proceeds, but the match is recorded as a warning in the audit trail

When policies run

Policy evaluation is synchronous, not a periodic scan. Every provisioning or update request submitted to cloud-connector is checked against the applicable policies (platform-wide + your organisation’s custom policies for the given provider/resource type) at the moment the request is made:

If any matching policy has severity block, the request is rejected immediately and the resource is never created/modified.
If the only matches are warn policies, the request proceeds and each match is logged to the audit trail.
If nothing matches, the request proceeds normally.

There is no fixed re-scan interval for already-provisioned resources tied to this mechanism — evaluation happens at request time.

You can dry-run a policy expression against a sample resource payload before saving it, to check what it would match.

Compliance scoring

View your organisation’s compliance score at Cloud Instances → Inventory → Compliance (/gravity/inventory/compliance).

The dashboard shows:

An overall score (0–100) for the organisation
A breakdown by cloud provider
A breakdown by compliance framework (iso27001, nis2, soc2, gdpr)
Finding count and critical-finding count
A filterable table of findings (by severity — block/warn — and by provider), each showing the affected asset, the policy that matched, and the framework controls it maps to

The score is a plain 0–100 value computed from how many evaluated assets pass the active policies; there are no officially documented percentage bands (e.g. no fixed “90–100% = Compliant” cutoffs) — treat the number as a relative trend indicator rather than a certified compliance status. The dashboard supports exporting the findings as CSV, and a printable report via the browser’s print-to-PDF.

Tag governance

Tag compliance is tracked at Cloud Instances → Inventory → Tags (/gravity/inventory/tags). This page lists cloud assets with missing required tags, sourced from unacknowledged drift-event records (the same drift-detection mechanism used elsewhere in inventory, filtered to tag-related findings) rather than a dedicated mandatory-tag configuration screen.

From this page you can select one or more affected assets and submit the missing tag values in bulk; this is sent asynchronously to cloud-connector, which applies the tags to the underlying cloud resources and reports back. There is no separate autonomy-level gate specific to tag remediation beyond the standard write-access requirements of your BYOC credentials.

Tag rules themselves are expressed using the same cloud-policy JSON DSL described above — there is no separate mandatory-tags content type.

Data Classification

Every resource can be marked with a sensitivity level (Public, Internal, Confidential, Restricted) via a data-classification tag. Custom policies can reference this field (e.g. { "field": "tags.data-classification", "op": "eq", "value": "restricted" }) to enforce controls such as requiring encryption at rest or blocking public endpoints for sensitive resources — this is implemented as ordinary policy expressions, not a separate built-in classification engine.

Right-sizing recommendations

Sencai monitors resource utilization and recommends cost optimizations:

Underutilized instances — CPU/RAM usage below 20% for 14+ days
Oversized databases — low query volumes relative to instance size
Idle load balancers — no traffic for 7+ days
Unattached storage — volumes not mounted to any instance

View recommendations at FinOps → Right-sizing. Each shows:

Current resource and cost
Suggested alternative and estimated monthly savings
One-click “Accept recommendation” (executes automatically if autonomy level allows)

NIS2 evidence

NIS2 gap tracking is currently an internal/admin tool, not yet a self-service feature available to organisation users. NIS2 gap records (nis2-gap) are plain CRUD entries — requirement, article, annex, status, target date, owner, and evidence links — managed by platform administrators; there is no PDF/JSON report-generation pipeline behind this data today.

If you need NIS2-related evidence as an organisation user, the closer available feature is the compliance scoring dashboard described above (Cloud Instances → Inventory → Compliance), which includes an nis2 framework score breakdown and exportable findings. For formal NIS2 gap-analysis reporting, contact your Sencai account representative — this workflow is not yet exposed in the customer-facing UI.

Policy alerts and notifications

When a policy match occurs:

If the policy is block, the underlying provisioning/update request fails and the caller sees the error immediately.
If the policy is warn, the request succeeds and the match is recorded in the audit trail.
Matches are reflected in the compliance score and the findings table at Cloud Instances → Inventory → Compliance.

Troubleshooting

Q: A policy is blocking a legitimate resource

A: Go to Cloud Instances → Policies, find the custom policy, and either edit its severity from block to warn, or adjust the JSON DSL expression so the condition no longer matches that resource. Built-in platform-wide policies cannot be edited by organisation users.

Q: Compliance score is 0 for a new resource type

A: No policies currently apply to that resource type/provider combination. Add a custom policy at Cloud Instances → Policies covering it.

Q: Tag governance is showing violations for resources I can’t modify

A: Read-only imported resources may not have write permissions. Check your BYOC credentials — they need write access for the bulk-tag remediation to succeed on the underlying cloud provider.