AWS Security Checklist (FSBP and CIS v5.0.0 Mapped)

Most AWS incidents start with a basic that was assumed rather than checked: a root access key nobody deleted, an IAM user key from years ago, a bucket outside Block Public Access, or a trail that stopped logging in a new Region. This template is a tickable checklist for verifying those basics across an AWS estate, organised as organisation, root, identity, logging, detection, network, compute and data. Every check carries the AWS Security Hub control ID from the AWS Foundational Security Best Practices (FSBP) standard and, where AWS maps one, the CIS AWS Foundations Benchmark v5.0.0 recommendation, so you can verify it automatically and quote it to an auditor. It is written for cloud security engineers, platform teams and auditors reviewing new or existing accounts. For why each control matters, read the AWS Security Guide; this page verifies.

This is an independent guide from NHI Mgmt Group, based on AWS's public documentation as of November 2026. It is not sponsored or reviewed by AWS. Product features change, so confirm settings against AWS's current documentation.

How to use this template

Replace text in square brackets, such as [Organisation], [log archive account] and [SIEM], with your own details.
Control IDs such as IAM.4 or S3.1 are Security Hub CSPM control IDs from the FSBP standard (version 1.0.0). CIS numbers are CIS AWS Foundations Benchmark v5.0.0 recommendations as mapped by AWS. Checks without an ID are manual or organisation-level.
Enable FSBP and CIS v5.0.0 in Security Hub across all accounts and Regions first; many checks below can then be read from findings rather than inspected by hand. AWS recommends CIS v5.0.0 among the four versions Security Hub supports (v5.0.0, v3.0.0, v1.4.0, v1.2.0).
Mark each line Pass, Fail, Partial or Not applicable, record the accounts checked and attach evidence (finding export, CLI output, screenshot).
Run the full list for every new account before workloads go in, and at least [quarterly] across the estate.

1. Review record

Field	Entry
Organisation ID and management account	[o-xxxxxxxxxx], [account ID]
Accounts and Regions in scope	[All / list]; Regions in use: [list]
Security tooling account and log archive account	[account IDs]
Security Hub standards enabled	[FSBP v1.0.0, CIS v5.0.0]
Reviewer, date, result	[Name], [date], [Pass / Pass with findings / Fail]

2. Organisation and account structure

#	Check	Control	Result and evidence
2.1	All accounts belong to one AWS Organization with all features enabled; workloads run in member accounts, never the management account.	Manual	[ ]
2.2	Separate accounts exist for security tooling (delegated administrator for Security Hub, GuardDuty, Config, IAM Access Analyzer) and for log archive. See the AWS Multi-Account Security Reference Architecture Guide.	Manual	[ ]
2.3	Service control policies deny leaving the organisation, disabling CloudTrail, GuardDuty, Config and Security Hub, and use of unapproved Regions. Remember SCPs do not grant permissions and do not restrict the management account. See the AWS Organizations and SCPs Guide.	Manual	[ ]
2.4	Where data must stay within the organisation, resource control policies or a data perimeter restrict access to trusted identities and networks. See the AWS Resource Control Policies and Data Perimeter Guide.	Manual	[ ]
2.5	Security contact information is set for every account.	Account.1	[ ]

3. Root user

#	Check	Control	Result and evidence
3.1	No root access keys exist in any account.	IAM.4; CIS 1.3	[ ]
3.2	Management account root has MFA, preferably a FIDO security key or hardware token; AWS allows up to eight MFA devices, so register at least two.	IAM.9 (CIS 1.4); IAM.6 hardware MFA (CIS 1.5)	[ ]
3.3	Member accounts use centralised root access: root credentials (password, access keys, signing certificates, MFA) removed, privileged root tasks performed centrally from the management account or IAM delegated administrator. If root credentials are kept instead, each has MFA.	Manual	[ ]
3.4	Root email addresses are business-managed group addresses not tied to one person; the recovery email inbox and phone number are held by two different groups.	Manual	[ ]
3.5	Root sign-in and usage raise an alert (EventBridge rule with SNS, or GuardDuty) with a documented response procedure.	Manual	[ ]

4. Identity and access management

#	Check	Control	Result and evidence
4.1	Human access uses IAM Identity Center (or SAML federation) with MFA at the identity provider; IAM users for people exist only as documented exceptions. See the AWS IAM Identity Center Guide.	Manual	[ ]
4.2	Any IAM user with a console password has MFA.	IAM.5	[ ]
4.3	No IAM user has policies attached directly; permissions come through groups or roles.	IAM.2	[ ]
4.4	No customer managed policy grants full `"*"` administrative privileges, and none allows wildcard actions for a service.	IAM.1; IAM.21	[ ]
4.5	IAM user access keys are rotated within 90 days, and unused credentials are removed. Prefer replacing keys with roles. See How to find unused AWS IAM roles and access keys.	IAM.3; IAM.8	[ ]
4.6	Workloads use IAM roles (instance profiles, task roles, Lambda execution roles); CI/CD uses OIDC federation rather than stored access keys. See How to set up workload identity federation for GitHub Actions to AWS.	Manual	[ ]
4.7	IAM Access Analyzer external access analysers run at organisation level, and findings for public or cross-account access are triaged. See the IAM Access Analyzer Guide.	Manual	[ ]
4.8	Cross-account role trust policies name specific principals and use an external ID or organisation condition for third parties. See How to review AWS cross-account trust policies for confused deputy.	Manual	[ ]
4.9	No IAM policy allows decryption actions on all KMS keys.	KMS.1; KMS.2	[ ]
4.10	Any remaining IAM user password policy has strong settings.	IAM.7	[ ]

5. Logging

#	Check	Control	Result and evidence
5.1	At least one multi-Region CloudTrail trail records read and write management events; an organisation trail is preferred. See the AWS CloudTrail Guide.	CloudTrail.1; CIS 3.1	[ ]
5.2	CloudTrail log file validation is enabled.	CloudTrail.4; CIS 3.2	[ ]
5.3	CloudTrail logs are encrypted at rest with KMS.	CloudTrail.2; CIS 3.5	[ ]
5.4	Trail logs land in the [log archive account] in a bucket that workload accounts cannot delete from, with retention of [12 months] or more.	Manual	[ ]
5.5	CloudTrail data events are enabled for S3 buckets and Lambda functions holding [Restricted] data.	Manual	[ ]
5.6	AWS Config is enabled in every account and Region in use, using the service-linked role. See the AWS Config Guide.	Config.1	[ ]
5.7	VPC flow logs are enabled for production VPCs, and S3 server access logging for sensitive buckets.	S3.9	[ ]
5.8	CloudTrail, GuardDuty and Security Hub findings are forwarded to [SIEM] within [15 minutes].	Manual	[ ]

6. Threat detection

#	Check	Control	Result and evidence
6.1	GuardDuty is enabled in every account and Region through the delegated administrator, with auto-enable for new accounts. See the Amazon GuardDuty Guide.	GuardDuty.1	[ ]
6.2	GuardDuty protection plans relevant to the estate are on: S3 Protection, EKS Audit Log Monitoring, Runtime Monitoring, Malware Protection for EC2, RDS Protection, Lambda Protection.	GuardDuty.10, .5, .11, .8, .9, .6	[ ]
6.3	Security Hub CSPM is enabled with central configuration, and critical and high findings have an owner and an SLA. See the AWS Security Hub Guide.	Manual	[ ]
6.4	Alerts exist for: root use, IAM policy changes, CloudTrail or Config being stopped, security group changes, console sign-in without MFA, and new access keys on IAM users.	Manual	[ ]

7. Network and compute

#	Check	Control	Result and evidence
7.1	Security groups allow unrestricted inbound traffic (0.0.0.0/0 or ::/0) only on authorised ports, and never on high-risk ports such as 22 and 3389.	EC2.18; EC2.19	[ ]
7.2	Network ACLs do not allow ingress from 0.0.0.0/0 to port 22 or 3389.	EC2.21	[ ]
7.3	EC2 instances and launch templates require IMDSv2. See the EC2 Instance Metadata Service Hardening Guide.	EC2.8; EC2.170	[ ]
7.4	Administrative access to instances uses Systems Manager Session Manager or a bastion with MFA, not SSH or RDP open to the internet. See the AWS Systems Manager Security Guide.	Manual	[ ]
7.5	Internet-facing applications sit behind AWS WAF or an equivalent, and RDS instances are not publicly accessible.	RDS.2	[ ]
7.6	Instance roles carry only the permissions the workload needs, especially for internet-facing proxies, firewalls and front ends.	Manual	[ ]

8. Data protection

#	Check	Control	Result and evidence
8.1	S3 Block Public Access is on at account level and on every general purpose bucket, except documented public website buckets. See the Amazon S3 Security Guide.	S3.1; S3.8	[ ]
8.2	Buckets block public read and write access and do not use ACLs to manage user access.	S3.2; S3.3; S3.12	[ ]
8.3	Bucket policies require TLS for requests.	S3.5	[ ]
8.4	EBS default encryption is enabled in every Region, and attached volumes are encrypted.	EC2.7; EC2.3	[ ]
8.5	RDS snapshots are private.	RDS.1	[ ]
8.6	KMS keys are not publicly accessible and are protected from unintended deletion; key policies separate key administrators from key users. See the AWS KMS Security Guide.	KMS.5; KMS.3	[ ]
8.7	Backups of critical data are in AWS Backup with vault lock or a separate account, and restore has been tested in the last [6 months].	Manual	[ ]

9. Findings and sign-off

Finding	Check #	Accounts affected	Severity	Owner	Due date
[Description]	[ ]	[ ]	[Critical / High / Medium / Low]	[ ]	[ ]

Sign-off: Cloud platform owner [name, date] · Security [name, date].

Implementation guidance

Turn on visibility before fixing. Enable CloudTrail, Config, GuardDuty and Security Hub (FSBP and CIS v5.0.0) organisation-wide first. When upgrading CIS versions, enable v5.0.0 before disabling the older one so coverage never lapses.
Fix root and keys first. Sections 3 and 4.5 remove the credentials attackers most often find: root keys, old IAM user keys and keys in code.
Then scope machine roles. Role credentials obtained through the metadata service, from a role that can read far more S3 buckets than it needs, are a common path to data exposure. Checks 7.3 and 7.6 address both halves.
Prevent, then detect. Move fixes into SCPs, account baselines (for example AWS Control Tower or infrastructure as code) and Config rules so new accounts are compliant from creation. Test new SCPs on a sandbox organisational unit first, and keep the previous policy version to roll back if a deny breaks deployments.
Size to the estate. A single-account startup can complete this checklist by hand in a day, then move to two or three accounts. A large organisation should rely on Security Hub findings and Config aggregators, reviewing exceptions rather than every resource.
Measure. Track Security Hub security score per account, the number of IAM user access keys older than 90 days (target zero for root, falling for users), accounts without GuardDuty or Config (target zero), publicly accessible buckets outside the approved list (target zero), and mean time to close critical findings.

Framework mapping

Checklist section	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
2. Organisation and accounts	CM-6, SC-7	PR.PS-01, PR.IR-01	8.9, 8.22
3 and 4. Root and IAM	AC-2, AC-6, IA-2, IA-5	PR.AA-01, PR.AA-05	5.15, 5.17, 8.2, 8.5
5. Logging	AU-2, AU-12	PR.PS-04	8.15
6. Threat detection	SI-4, AU-6	DE.CM-09	8.16
7. Network and compute	SC-7, CM-7	PR.IR-01	8.20
8. Data protection	SC-28, CP-9	PR.DS-01, PR.DS-11	8.24, 8.13

Attack techniques these checks address include MITRE ATT&CK T1078.004 Cloud Accounts, T1552.005 Cloud Instance Metadata API, T1098.001 Additional Cloud Credentials and T1530 Data from Cloud Storage.

Standards and references

This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: AWS Security Guide · Top 10 AWS IAM Mistakes · AWS Access Keys Security Guide · Cloud IAM Review Checklist · Google Cloud Security Checklist

AWS Security Checklist: Account, Identity and Logging Basics Verified