Cloud security posture,
checked every six hours, kept as evidence.

• Read-only connectors for AWS, Google Cloud and GitHub, listed check by check on each integration page
• Re-synced every six hours; each passing check becomes a dated evidence item valid for 90 days
• Failing checks name the resource and move readiness and residual risk at once
• Connector credentials encrypted at rest with AES-256-GCM
• Nothing we run changes state in your accounts

Cloud security posture management for compliance means checking cloud configuration continuously against the controls a framework asks for, such as MFA on privileged accounts, audit logging and encryption, and keeping the results as evidence. It replaces the screenshot of a console taken in audit week with a dated record covering the whole observation period.

Each connector's page lists every check: what it reads, how it decides pass or fail, and the requirement it files evidence against. See AWS, Google Cloud and GitHub.

1. Connect with read-only accessGrant a read-only role or token for each provider: a scoped token for GitHub, an IAM policy of read actions for AWS, and eight viewer and reviewer roles for Google Cloud. The exact permissions are listed on each integration page.
2. Run the checksThe platform calls the provider's own APIs and evaluates each check against a written rule. A check returns pass, fail, not applicable, or could not verify when the permission it needs is missing.
3. Keep passing results as evidenceEach passing check is stored as a dated evidence item against the SOC 2, ISO 27001 and DPDP requirements it supports. Evidence is valid for 90 days and renews on every sync.
4. Show what failedA failing result names what it found, such as the account, instance or service and the setting that caused it, so an engineer can fix it without repeating the investigation.
5. Re-run every six hoursConnectors re-sync every six hours, so a setting that drifts is caught the same day, and the evidence shows continuous coverage across the audit period instead of one date.

Because a compliance tool with write access to production is itself a risk an auditor has to assess. Every connector uses read-only roles or scopes, and remediation stays with your engineers, who have the authority to change your infrastructure.

Cloud posture monitoring evidences the technical controls auditors sample most: access control, logging, encryption, backup and change management. In ISO/IEC 27001:2022 Annex A that is 5.15 to 5.18 for access, 5.23 for the use of cloud services, 8.5 for secure authentication, 8.9 for configuration management, 8.13 for backup, 8.15 for logging, 8.16 for monitoring and 8.24 for cryptography.

For SOC 2, the same results support CC6.1 (logical access), CC6.6 and CC6.7 (boundary protection and data in transit), CC7.2 (monitoring) and CC8.1 (change management). Under the DPDP Act and Rule 6 of the DPDP Rules 2025, they show the reasonable security safeguards section 8(5) requires, including encryption, access control and logs kept for a year.

Because each check maps to shared controls rather than to one framework, one passing result counts for every framework you run. That is the reason the same CloudTrail check does not have to be collected three times for three audits.

Failing results matter because an auditor sampling a twelve-month period wants to see how drift was caught and fixed, not a record that was green every day. A dated failure followed by a dated fix is evidence that monitoring works. An unbroken run of passes during a period when the team remembers an incident invites questions.

So a failing check is never hidden or converted into a pass. It shows on the account with what it found, and the next sync after the fix records the pass. Checks that cannot run because a permission is missing say could not verify, which is different from passing.

This is posture monitoring for compliance evidence, not a full cloud security posture management product. A dedicated CSPM tool may evaluate hundreds of rules across every service. The checks here are a focused set chosen because auditors ask for them, each with a written rule and a requirement it files evidence against.

If you already run a CSPM tool, the two work side by side: the CSPM tool for breadth, these checks for evidence that lands against the right control without exporting screenshots.

A connector needs read-only credentials and nothing more. AWS uses an IAM policy of read and list actions; Google Cloud uses viewer and security-reviewer roles that cannot read your data; GitHub uses a token that reads metadata, not file contents. Credentials are encrypted at rest with AES-256-GCM.

Nothing the platform runs changes a setting, rotates a key or deletes a resource. Remediation stays with your engineers. That keeps the compliance tool from becoming a privileged system an auditor has to assess in its own right.

• Evidence that privileged accounts use MFA, across the whole observation period
• Audit logging that is on, tamper-evident and retained for the period your policy states
• Encryption of data at rest and in transit for databases holding customer data
• Backups that are taken, retained and protected from deletion
• Change management: protected branches, required review and approval by someone other than the author
• How configuration drift is detected and how quickly it was fixed

• It does not change, fix or delete anything in your accounts
• It does not cover Azure, Okta, GitLab or Google Workspace with checks yet; the last three have a connect screen only
• It does not read your data, database contents or source files
• It does not replace a full CSPM tool's breadth of rules
• It does not file a failing result as evidence; failures show on the account until fixed

Every result here is a control result on the same graph as the rest of the platform, so it reaches each framework that asks for it without being gathered again. Coverage lists the regimes.

Related reading: all integrations and the evidence ledger.