Compliance reference

Frameworks, the agreed comparison table, your own requirements, the 22 controls, finding families, finding to incident, risk decisions, attestations, the scanner pull, scores and audit.

Reference · Updated 2026-10-28 · Describes release 0.1.164

Exact facts about the compliance pillar. The procedures are in Turn on compliance and Security posture; who may approve a risk decision or release a compliance fix is owned by Approval policy and change tiers.

Frameworks and requirements

Two frameworks ship in full, as paraphrased requirement rows (never the standard's own text): 154 rows — 61 SOC 2 Trust Services Criteria and 93 ISO/IEC 27001:2022 Annex A controls. A requirement with no automated check mapped onto it is shown as a manual-attestation row, never a silent gap and never a fake pass.

Scope lives in tenant.settings['compliance']:

The mapping from requirement to check is this platform's interpretation; the interpretation sheet (POST …/compliance/interpretation-export, audit compliance.interpretation_exported) renders every control's stated basis for the customer's security or legal team to approve. Passing scans do not by themselves constitute SOC 2 or ISO 27001 compliance; every unmapped requirement needs human attestation and auditor-accepted evidence.

Agreed comparison table

The comparison table is the version of this mapping the customer accepts before onboarding: when the posture says compliant, it means compliant against that accepted version. It lists every requirement row, in scope or not, then the workspace's own rows. Under Agreed comparison table on the Frameworks page: Download table (CSV), Download table (Markdown) and Record acceptance.

A cloud column is blank where no public mapping names a rule. AWS publishes no sample conformance pack for ISO 27001 or SOC 2 (a customer may author its own), and Security Hub has no ISO 27001 or SOC 2 standard; Audit Manager is closed to new customers, so its mapping is a reference. The scanner, AWS Config and Azure Policy columns of a catalogue row are not scored by the platform: they name the rules that evidence the same requirement in your cloud.

Your own requirements

A workspace may add requirements of its own, such as "highly available: every applicable resource runs in at least two Availability Zones". Each row is judged by platform rules and/or scanner controls, or by an attestation when it names neither; it joins the comparison table (and changes its version) and the posture as the custom framework, shown as Workspace requirements. Add or remove them under Your own requirements in the Agreed comparison table card (Save requirement, Remove).

Automated controls

22 controls, each mapped many-to-many onto requirement refs. Check kinds in cost order — the order a scan evaluates them: deterministic (platform rows only, keyless), script (a direct read-only probe through the workspace's own connectors), lake (SQL over collected telemetry; no control uses it today), agent (one bounded run, the model residue — at most 5 per scan). Severity sets the compliance incident's severity on a fail: high → error, medium → warning, low → info.

EST-01 to EST-06 read AWS and Azure through the workspace's own connectors (GCP: probe pending — the control reports unknown with a connect hint). A control whose data category is not connected reports unknown, never a fail. The "Mirrors" column names the AWS Foundational Security Best Practices / CIS AWS Foundations control the basis prose cites; it is also the join between a scanner finding's control (S3.1 fails) and the platform control it evidences (EST-02).

How a scan runs

A control:<id> incident (the platform's own probe) and a service=control:<id> incident (a scanner finding) are analysed on the incident pillar when it is enabled — only that pillar carries the wrap-up contract, the planning block and the write capabilities; the compliance pillar's own run ends as a generic wrap-up with no plan.

Schedule

Finding families

A scanner finding is classified offline and deterministically — the model is never asked what a control means, so the same finding always gets the same stance, which is what makes "may this auto-remediate?" auditable. Match order: an exact control id (or id prefix) a family lists; then an id contained by a listed sibling (a guessed family never hands out the auto stance); then the product token; then title / description patterns; then the scanner product; else other.

A vulnerable-package finding that lists its packages reaches the analysis with each package's installed and fixed version (the vulnerable_packages annotation, refreshed by every re-send). The analysis only drafts the fix: its steps are carried into the change request, where the remediation is reviewed, approved and released — nothing in the run changes the estate. The scanner clearing the finding is the plan's verification, never an extra step, and a package with no fixed version gets a compensating control instead of an upgrade.

What the analysis is told, per resource type — one section per type the findings name, each once, in this order:

Any other resource type upgrades each package through its own package manager or build. When the image's repository, owner or consumers are not evidenced, the plan names the read permission or connection that would supply them instead of guessing.

Every family carries a prevention hint (the guardrail that keeps it closed) and an action sentence. method is the kind of fix that closes the family: patch, config-change, policy, block, or accept-only where the platform holds no fix path at all. Resource types are the coarse buckets coverage is reported on: ec2, container, lambda, s3, ebs, rds, network, iam, logging, other.

Typed fixes: a few exact controls map to one compiled posture operation — EC2.2/13/14/18/19 → aws.security_group.revoke_ingress; S3.1 → aws.s3control.put_public_access_block; IAM.7 and IAM.10–17 → aws.iam.update_account_password_policy; EC2.8 → aws.ec2.require_imdsv2; the Defender assessment "Storage account public access should be disallowed" → azure.storage_account.disallow_blob_public_access. A finding with a typed fix carries the remediation_operation label; the fix is still human-released (stance and tier stay the family's).

Remediation stance and escalation

Escalation is monotonic (rules only raise, never lower; a marker records that they ran once):

settings['risk_context'] also has internal_patterns (fills exposure: internal only when nothing derived internet). A declaration can fill an unknown or raise exposure to internet; it can never talk a derived internet-facing resource back down. settings['workspace_scope'].tags (up to 10 tags, case-insensitive, all-of) limits a workspace to its own tag slice of a shared account; a scoped workspace treats an untagged resource as out of scope.

The deterministic risk block a person reads before deciding (risk): factors[] (internet-facing / internal-only, sensitive data, env, CVSS with fix availability, CVE count, the escalations), a one-line summary, exposure, data_sensitivity, env, cvss, epss, fix_available (YES / NO / PARTIAL), prevention, method, resource_types.

From a scanner finding to an incident

Security Hub (ASFF) and Defender for Cloud findings arrive pushed (/webhook/securityhub/<slug>/<token> and /webhook/defender/<slug>/<token>, usually behind SNS or an action group) or pulled by the scanner sync. Both go through the same normaliser and land as alerts:

Pillar: threat-detected → SecOps; every other family → Compliance (an alert whose severity is literally security also goes to SecOps). Correlation key service=control:<id>, so a new resource failing the same control joins the open incident; the scanner's own RESOLVED / PASSED state is the clear. The CloudFinding register row (source, finding_key, control, family, stance, tier, CVE columns, context, risk, status open / cleared, seen_count, suppressed_count, incident_id, the raw ASFF kept scrubbed) is upserted on the same ingest.

Priority is derived from severity, never by a model: critical → P1, error → P2, warning → P3, info → P4; one level up (floor P1) when the blast radius reaches two services, one more for a mission-critical resource. Severity is the maximum of the correlated alerts and upgrades on join.

Pushed versus pulled:

Hold reasons shown on the incident: "no prepared fix for this finding type, and its priority is below P2 (automatic analysis covers P1/P2)"; "… and automatic P1/P2 analysis is off for this workspace"; "a prepared fix is available, but its priority is below P2 (automatic analysis covers P1/P2)" — the incident then reads A prepared fix is available — waiting for a person to start it, and Analyse starts the analysis that drafts it (no paid run for a P3/P4 until a person asks, 22-Oct); "automatic analysis is off, paused or over budget". A held finding is analysed with the Analyse button. The switches:

A re-send the scanner observed before the fix recorded on the row (remediated_at) is stale and does not reopen; for Defender only within 48 hours of the fix.

Pulling findings from Security Hub and Defender

Security Hub and Defender findings can also be pulled instead of pushed: a workspace owner sets how often under Security posture → Posture → Scanner sync → Pull from scanners automatically (every 15 minutes by default; off, or every 5 minutes up to daily — through the API, scanner_sync_interval_s in seconds, 300 to 86400 or 0 = off, on PATCH /api/aiops/{tenant_id}/guardrails, stored as the workspace setting aiops_scanner_sync_interval_s, null = back to the platform default), the platform then reads them on that schedule through your read AWS / Azure connection, and Sync now on the same card pulls the last 24 hours on demand. A pull only reads the scanners: a finding that is already open stays on its incident, so re-reading it opens nothing and costs no model time, and a Security Hub or Defender re-send observed before a recorded fix is skipped (for Defender, an assessment whose verdict last changed before the fix, and only within 48 hours of the fix). Security Hub must be enabled in each region on the connection — "Security Hub is not enabled on <connection>" means it is not, not that the credential is wrong. On Azure the subscription needs Defender for Cloud, that is the Microsoft.Security resource provider registered: without it Azure lists no assessments at all, and the sync reads "Defender for Cloud is not enabled on <connection>" rather than 0 findings. Pull and webhook share the same deduplication, so using both is safe. With several AWS accounts, each read connection asks Security Hub for its own account's clears; a connection into the workspace's only AWS account — for example the Security Hub administrator account — asks for every account's. Only connections that run Security findings sync count: several of them into one account count once, and an access-key connection counts as an account of its own until a passing Test confirms which account it is in. A pull asks about up to 500 open findings at a time; with more open, each pull asks the next 500 and the line says so, for example 500 of 1240 open findings re-checked with Security Hub, the rest at the next syncs — or press Sync now again for the rest while the scheduled pull is off, since nothing else asks. Defender returns every assessment in one listing, so all its open findings are checked on each pull. A pull paces its reads to at most about three a second (Security Hub's limit for reading findings) and asks a throttled read again after 1, 2 and 4 seconds; the connection's line then says throttled, retried. A Security Hub region still throttled after that reads partial (rate limited) while the other regions land; when every region, or the Defender list, stays throttled, the line reads rate limited, retried at the next sync, or rate limited — press Sync now again in a minute while the scheduled pull is off. Sync now needs pillars.manage, so for anyone without it those two lines say a workspace owner can press Sync now again instead. A Sync now across many accounts can outlast the request: the card then says Still running on the server and shows the report when the sync finishes.

Risk decisions

The agent prepares (finding + deterministic risk impact); a human decides; the register records it. A decision is a request first.

Rules:

Control exceptions: for the estate controls EST-01 to EST-06 a person accepts the risk on some of a control's offenders (POST …/compliance/controls/{id}/exceptions, same requester rule): one anchor CloudFinding per (control, resource) with source: compliance, then an ordinary accept request — supersede, default expiry, audit and the register come with it. Only resources the platform showed in the latest evidence can be accepted; a control with no per-resource evidence is marked not applicable instead. An exception decided after the scan shows on the posture at once; the control's incident moves at the next probe.

Attestations and overrides

Mute list (legacy)

settings['aiops_compliance_muted'] — [{control_id, resource, note, by, at}], at most 200 entries — mutes a (control, resource) pair for change-triggered checks: a live match is skipped before the probe (no probe, no result, no incident) but never silently — one compliance.rule_muted_hit audit row per pair per tick. An entry stops muting aiops_risk_accept_days after its at (the acceptance clock); only POST …/incidents/muted-rules/unmute (approvals.decide) removes one (audit compliance.rule_unmuted). Nothing writes the list any more: an accepted exception replaced "Suppress this finding".

Change-triggered checks

Every harvested cloud change is judged, deterministic first:

Posture scores

Two different numbers, two different questions.

The findings trend: the last 30 days by default (days, or an inclusive start_date / end_date range up to 366 days, or 12 ISO weeks / calendar months with interval). Each day comes from its saved daily snapshot when one exists (snapshot), else it is reconstructed from the current records (live for a day that has not closed); the first snapshot run reconstructs up to 366 days back. Neither score is a remediation rate: scan completeness is unknown, days without recorded findings do not prove a clean scan, a suppression is not remediation, and scanner clearance does not establish who performed a fix. POST …/findings/posture-export (report.view, audit risk.posture_exported) renders it.

GET …/findings/coverage (report.view) lists the observed findings by family, stance and resource type, with which families have a typed fix — the Coverage tab.

Score per standard, patching and backup

Security posture → Audit & coverage → Scores shows three reports read from your AWS accounts through the read connections the platform checks use (a connection with platform_checks: false is left out). The scheduler reads them once a day per workspace (AIOPS_COMPLIANCE_REPORT_INTERVAL_S, 86400; 0 = only the button); Refresh reports reads now (incidents.act). One row is saved per workspace per UTC day — a second read the same day replaces it — and the trend draws one point per saved day. A denied or failed AWS call is listed under the card; what was read still counts.

Read permissions: the read role created by the guided AWS setup carries config:DescribeConformancePacks, config:DescribeConformancePackCompliance, ssm:DescribeInstanceInformation, ssm:DescribeInstancePatchStates and backup:ListBackupJobs since 0.1.144 (re-run the setup to add them); a role built on ReadOnlyAccess already has them. No call writes anything. Azure (Defender regulatory compliance, Update Manager, Azure Backup) is not read yet.

Audit actions

Settings

API summary

Next steps

• Next: Permissions
• All Reference pages
• Documentation home