AWS compliance integration:
15 read-only checks, 16 read actions.

The AWS integration runs 15 read-only checks against one AWS account: root-user MFA and access keys, MFA for every IAM user with console access, the password policy, access-key age, account-level S3 Block Public Access, a logging multi-region CloudTrail trail with log file validation, RDS encryption, backups, deletion protection, Multi-AZ and public access, and GuardDuty and Security Hub in every enabled region. It calls 16 read actions and nothing else.

These are the account-level questions an auditor asks first: who can act as root, whether people sign in with MFA, whether activity is recorded, whether databases are encrypted, backed up and private, and whether threat detection is switched on everywhere. Every request is SigV4-signed and calls a Get, List or Describe action; the connector has no AWS SDK and no write path.

A check over several resources passes only if every resource passes. One that could not be read makes the whole check could not verify, not a pass on the rest.

Each check returns one of four results: pass, fail, not applicable (nothing of that kind exists, or a plan limit makes the setting unavailable) or could not verify (the call was refused or failed). A check over several resources shows a value such as 6/8 passing and names every resource it looked at. Nothing is simulated, and a check that could not look is never shown as a pass.

Only passing checks become evidence: one evidence item for each reference in the last column, so a single pass can evidence SOC 2, ISO/IEC 27001 and the DPDP Act at once. Each item expires after 90 days and every sync renews it, so evidence from a connection that has stopped syncing stops counting. A failing result is shown on the connected account with the resources that caused it, and is not filed as evidence.

Each check belongs to a shared control in the TryTrustable control library, and is filed only under requirements the library maps to that control. The same control answers the requirements below in other frameworks; the references are read from the library. The cross-framework mapping page explains how one result reaches several frameworks.

Requirement references are read from the TryTrustable control library. A dash means the library maps no requirement in that framework to this control.

Exactly the 16 read actions the checks call: sts:GetCallerIdentity, ec2:DescribeRegions, iam:GetAccountSummary, iam:GetAccountPasswordPolicy, iam:ListUsers, iam:ListAccessKeys, iam:ListMFADevices, iam:GetLoginProfile, s3:GetAccountPublicAccessBlock, cloudtrail:DescribeTrails, cloudtrail:GetTrailStatus, rds:DescribeDBInstances, rds:DescribeDBClusters, guardduty:ListDetectors, guardduty:GetDetector, securityhub:DescribeHub. sts:GetCallerIdentity needs no permission and is listed so the policy documents every request. None of the actions can change anything in the account.

The policy for a dedicated IAM user, exactly as the product shows it:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "TryTrustableReadOnlyAudit",
      "Effect": "Allow",
      "Action": [
        "sts:GetCallerIdentity",
        "ec2:DescribeRegions",
        "iam:GetAccountSummary",
        "iam:GetAccountPasswordPolicy",
        "iam:ListUsers",
        "iam:ListAccessKeys",
        "iam:ListMFADevices",
        "iam:GetLoginProfile",
        "s3:GetAccountPublicAccessBlock",
        "cloudtrail:DescribeTrails",
        "cloudtrail:GetTrailStatus",
        "rds:DescribeDBInstances",
        "rds:DescribeDBClusters",
        "guardduty:ListDetectors",
        "guardduty:GetDetector",
        "securityhub:DescribeHub"
      ],
      "Resource": "*"
    }
  ]
}