Cyber Essentials Plus on AWS: A Pre-Audit Controls Checklist

Jerzy Kopaczewski 15 septiembre 2026 7 min read
Contents
This is a pre-audit checklist: work through it before your Cyber Essentials Plus assessor arrives, and you will not be surprised on the day. It maps the five NCSC controls to concrete checks on an AWS environment, with commands to verify each. For the background on what each control means, read our Cyber Essentials Plus for AWS guide first; this page is the hands-on version.

Cyber Essentials Plus is verified by a hands-on audit: the assessor port-scans your internet-facing services, checks patch levels, tests access controls, and samples the devices your team uses. Everything below is something the assessor can and will check. Run these yourself first.

Control 1: Firewalls and internet gateways

The assessor port-scans anything internet-facing. The goal: only ports 443 (and 80 redirecting to 443) reachable from the internet, everything else private.

  • No security group allows 0.0.0.0/0 on SSH (22) or RDP (3389)
  • Only an ALB or CloudFront is internet-facing; compute and data sit in private subnets
  • No public IPs on RDS instances, ECS tasks, or backend services
  • Default VPC is unused for production (or deleted)
# Security Groups open to the world on ports other than 80/443
aws ec2 describe-security-groups \
  --filters Name=ip-permission.cidr,Values='0.0.0.0/0' \
  --query 'SecurityGroups[].{Name:GroupName,ID:GroupId,Rules:IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]].{Port:FromPort,Proto:IpProtocol}}' \
  --output table

# RDS instances that are publicly accessible (expect: none)
aws rds describe-db-instances \
  --query 'DBInstances[?PubliclyAccessible==`true`].DBInstanceIdentifier' --output table

Most common finding: a leftover 0.0.0.0/0 on port 22 from an old bastion. Even if unused, the assessor flags it. Remove it before the audit.

Control 2: Secure configuration

No default credentials, no unnecessary services, hardened to AWS best practice.

  • No default or hardcoded credentials anywhere (all secrets in AWS Secrets Manager)
  • No forgotten dev or test resources exposed to the internet
  • AWS Config recording configuration drift
  • Container images built from minimal bases (distroless or Alpine)
# Is AWS Config recording? (expect: recording=true)
aws configservice describe-configuration-recorders \
  --query 'ConfigurationRecorders[].{Name:name,Recording:recording}'

# Look for the classic forgotten resource: running EC2 instances by tag/age
aws ec2 describe-instances \
  --query 'Reservations[].Instances[?State.Name==`running`].{ID:InstanceId,Launched:LaunchTime,Name:Tags[?Key==`Name`]|[0].Value}' \
  --output table

Most common finding: a test instance or open admin panel nobody remembers. The assessor scans everything internet-facing on the account, not just what you think is in scope.

Control 3: User access control

Least privilege, MFA enforced, leavers removed.

  • MFA enforced for all human access (ideally via IAM Identity Center / SSO)
  • No long-lived IAM access keys for workloads (use roles / OIDC federation)
  • No shared IAM users; no service accounts with AdministratorAccess
  • Documented joiners / movers / leavers process
  • CloudTrail logging all API activity, multi-region
# Generate and read the credential report (check MFA + key age columns)
aws iam generate-credential-report >/dev/null
aws iam get-credential-report --query 'Content' --output text | base64 --decode | \
  cut -d, -f1,4,8,9,10,14,15

# Anyone still holding AdministratorAccess directly?
aws iam list-entities-for-policy \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
  --query '[PolicyUsers[].UserName, PolicyGroups[].GroupName, PolicyRoles[].RoleName]'

# CloudTrail active and multi-region?
aws cloudtrail describe-trails \
  --query 'trailList[].{Name:Name,MultiRegion:IsMultiRegionTrail}'

Most common finding: one shared IAM user or a personal access key that should have been retired. Clean up dormant identities before the audit.

Preparing for a Cyber Essentials Plus audit on AWS?

Book a free 30-min call

Control 4: Malware protection

Covers both the infrastructure and, crucially, your team’s devices.

  • Endpoint protection active on every laptop used to access production (this is tested)
  • Amazon GuardDuty enabled in every region in use
  • Container images scanned (Amazon Inspector / ECR scanning) before deploy
# GuardDuty enabled? (expect a detector id per region in use)
aws guardduty list-detectors --query 'DetectorIds'

# ECR scan-on-push configured on your repositories?
aws ecr describe-repositories \
  --query 'repositories[].{Repo:repositoryName,ScanOnPush:imageScanningConfiguration.scanOnPush}' \
  --output table

Most common finding: developers accessing production from a laptop with no endpoint protection. CE Plus tests the devices, not just the servers, and this catches teams off guard every time.

Control 5: Patch management

Critical and high-severity patches applied within 14 days.

  • Managed services in use where possible (Fargate / RDS / Lambda: AWS patches the platform)
  • Container base images rebuilt and redeployed on a schedule (automated in CI/CD)
  • Dependency scanning (Dependabot / Renovate / Snyk) auto-flagging vulnerable libraries
  • Amazon Inspector continuously scanning running workloads for known CVEs
# Inspector coverage: are your resources actually being scanned?
aws inspector2 batch-get-account-status \
  --query 'accounts[].resourceState.{EC2:ec2.status,ECR:ecr.status,Lambda:lambda.status}'

Most common finding: a container image built months ago and never rebuilt, carrying a known critical CVE. Automate image rebuilds so this cannot happen.

Before the assessor arrives

  • Scope agreed with the assessor (exclude unrelated systems, e.g. a marketing site on a separate platform)
  • Every item above checked and any findings remediated
  • Evidence ready: Terraform / IaC for the controls, process docs for joiners/leavers and patching
  • A clean run of our AWS security audit checklist for the deeper technical baseline

If your infrastructure is defined as code, most of this evidence is a code review rather than a document hunt: the assessor can see the firewall rules, the Secrets Manager configuration, and the IAM permission sets directly in Terraform.

Frequently asked questions

What does a Cyber Essentials Plus assessor actually test on AWS?

The assessor port-scans your internet-facing services, verifies that critical patches are applied within 14 days, tests user access controls (MFA, least privilege, account lifecycle), and samples the laptops your team uses to access production for endpoint protection. On AWS they are checking your security groups, IAM configuration, CloudTrail, and container image freshness against the five NCSC controls. They test live systems, not documentation.

What is the most common reason cloud teams fail Cyber Essentials Plus?

Two recurring ones: forgetting that endpoint scope includes the laptops used to access production (not just the servers), and leftover internet-facing resources, such as a `0.0.0.0/0` rule on SSH from an old bastion or a forgotten test instance with a default password. The assessor scans everything internet-facing on the account, so unmanaged or forgotten resources are the usual source of findings.

If you want help working through this checklist and getting audit-ready on AWS, our cloud security and compliance services cover Cyber Essentials Plus preparation end to end.

Jerzy Kopaczewski

Getting ready for Cyber Essentials Plus on AWS?

Book a free 30-minute call. We'll review your AWS environment against the five controls and tell you honestly how audit-ready you are and what needs to change.

Book a call
Cyber Essentials AWS UK compliance security checklist

Read also:

Previous post Next post