CloudTrail must-haves: an organization trail and an SCP to protect it

Two AWS changes in 2026 shape how teams should plan audit logging. AWS closed CloudTrail Lake to new customers on 31 May 2026 (existing customers continue as normal, and CloudTrail trails and Insights are unaffected). On 20 July 2026 AWS added filtering of CloudTrail network activity events by the calling IAM identity, so you can log only access-denied events from callers outside a trusted set. Plain trails are the stable base, and most estates still do not have them set up well.

What's affected

New AWS accounts that planned to start with CloudTrail Lake need a trail-based design instead, or the CloudWatch options AWS points to in its migration page. For everyone, the baseline below applies. The AWS docs say an organization trail must be created from the management account or a delegated administrator account, and logs events for the management account and every member account.

A May 2026 change helps too: since 28 May the management account receives CloudTrail events when accounts join or leave the organization, named AccountJoinedOrganization and AccountDepartedOrganization, which can drive alarms or EventBridge rules.

How to check if you're exposed

From the management account, list trails and confirm one is multi-region, organization-wide and validated:

aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail,IsOrganizationTrail,LogFileValidationEnabled,KmsKeyId]' --output table
aws cloudtrail get-trail-status --name org-trail

If no row shows True for multi-region and organization, you have gaps. Also check that logging is actually on in the status output, and that the destination bucket belongs to a separate log archive account.

What to do now

1. Create one organization trail. The create-trail documentation lists the flags for multi-region, organization scope, log file validation and a KMS key:

aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name my-org-log-archive \
  --is-multi-region-trail --is-organization-trail \
  --enable-log-file-validation --kms-key-id alias/org-trail-key
aws cloudtrail start-logging --name org-trail

2. Send logs to a bucket in a dedicated log archive account with no human write access and a lifecycle rule that matches your retention requirement.
3. Verify log integrity on a schedule. The validate-logs command checks digest files for a time range:

aws cloudtrail validate-logs --trail-arn arn:aws:cloudtrail:us-east-1:123456789012:trail/org-trail --start-time 20261001T00:00:00Z

4. Protect the trail with a service control policy. This is adapted from the AWS sample repository, which denies changes to a named trail except for a privileged role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:PutEventSelectors",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "arn:aws:cloudtrail:*:*:trail/org-trail",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/SecurityAdmin"
        }
      }
    }
  ]
}

5. Remember the SCP limit: the AWS docs say SCPs do not affect users or roles in the management account. Keep that account nearly empty and tightly restricted.
6. Add an alert for StopLogging, DeleteTrail, and the two new membership events, delivered to a channel someone watches.
7. If you use network activity events, add identity filters so you log denied requests from unknown callers instead of paying to log everything.

Why it matters

When an incident starts, the first question is what happened and who did it. A trail that is regional, per account or deletable by the same people who might be compromised cannot answer that. The organization trail, a separate archive account, validation and a protective SCP are what make the logs evidence rather than hope.

The CloudTrail Lake change is a reminder to design audit logging around durable primitives. Features come and go, and a trail with validated files in your own bucket is the piece auditors and responders both understand.

Try it yourself

In your management account, run the describe-trails command and write down which of the four properties (multi-region, organization, validation, encryption) each trail has. Then create the missing alert for StopLogging. After that, see how logs and settings become audit evidence automatically.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• AWS What's New: Selectively log network activity events by identity in AWS CloudTrail (20 July 2026)
• AWS What's New: AWS Organizations emits CloudTrail events for account membership changes (28 May 2026)
• AWS CloudTrail docs: CloudTrail Lake availability change
• AWS CloudTrail docs: Creating a trail for an organization
• AWS CLI reference: cloudtrail create-trail
• AWS CLI reference: cloudtrail validate-logs
• AWS Organizations docs: Service control policies
• AWS sample SCPs: deny modifications to specific CloudTrail trails