Root access management enabled in AWS Organizations. Where that is not possible, root multi-factor authentication (MFA) is enabled, access keys are deleted and root is used only for emergency break-glass access (a last-resort login for when normal routes fail).

IAM users and roles follow the principle of least privilege with no overly permissive policies (e.g. *:* on resources).

EC2, Lambda and ECS service roles are scoped to specific resources, not the entire account.

Human access goes through IAM Identity Center or federated roles with temporary credentials. Long-lived IAM access keys exist only where unavoidable, are rotated at least every 90 days and are deactivated when unused.

MFA enforced for every human user, whether IAM users or IAM Identity Center users, with phishing-resistant methods (passkeys or FIDO2 keys) preferred.

Cross-account roles follow least privilege. Third-party roles require an ExternalID unique to you, with source-account conditions where applicable.

No security groups allow inbound traffic from 0.0.0.0/0 or ::/0 (the entire internet) on sensitive ports (22, 3389, 3306, 5432, 1433: the ports used for remote administration and direct database access).

Private subnets used for databases and application tiers, public subnets only for load balancers and NAT gateways. Administrative access via SSM Session Manager or EC2 Instance Connect Endpoint rather than internet-facing bastion hosts.

Egress traffic restricted to approved destinations using AWS Network Firewall, prefix lists for AWS services or third-party appliances. Default-deny egress policy in place.

VPC Flow Logs enabled for all VPCs, logs retained for a minimum of 90 days.

IMDSv2 required on all EC2 instances and set as the account default so new instances cannot launch without it.

A web application firewall (AWS WAF, Akamai, Cloudflare or similar) protecting all public-facing endpoints, with rules covering the OWASP Top 10 (the standard list of common web application attacks).

Block Public Access enabled at account level. HTTPS-only access enforced, per bucket or organisation-wide with a Resource Control Policy. SSE-KMS with customer-managed keys where key control or cross-account access requires it.

All RDS and Aurora instances encrypted at rest using AWS KMS, automated backups and snapshots encrypted.

Application secrets held in AWS Secrets Manager or Parameter Store, never in code, environment variables or machine images, with rotation enabled for database credentials.

TLS 1.2+ enforced for all public endpoints, internal communication encrypted where sensitive data flows.

Customer-managed KMS keys used only where a requirement demands them (cross-account sharing, custom key policies or cryptographic erasure: destroying data by destroying its key). AWS-managed keys with automatic rotation everywhere else.

CloudTrail enabled in all regions, logs encrypted, integrity validation enabled, centralised to a security account.

Alarms configured for unauthorised API calls, IAM policy changes, security group modifications and root account usage.

AWS Config enabled in all regions, recording all resource types, with baseline rules active: as a minimum the AWS Foundational Security Best Practices standard or the CIS AWS Foundations Benchmark (the Center for Internet Security's widely used baseline for AWS).

Amazon GuardDuty enabled in all regions, findings integrated with your incident response workflow.

Security logs centralised in a dedicated security account, cross-account access restricted, logs retained per your obligations.

AWS Security Hub CSPM (or an equivalent cloud security posture management tool) aggregating findings across all accounts, scored against the AWS Foundational Security Best Practices standard, with CIS as an optional second benchmark.

Amazon Inspector scanning EC2, ECR and Lambda for known published vulnerabilities (CVEs) and network exposure, findings remediated to an agreed timescale.

AWS Backup policies configured, cross-region replication for critical data, recovery procedures tested.

Documented incident response procedures for AWS-specific scenarios (compromised IAM credentials, S3 data leak, GuardDuty alerts).

Amazon Bedrock and SageMaker endpoints secured with IAM and VPC controls. Bedrock Guardrails configured to filter harmful content and mask sensitive data.

Bedrock model invocation logging enabled, capturing prompts and responses to S3 or CloudWatch with appropriate access controls.

AWS Organizations AI services opt-out policy configured. Data-sharing terms reviewed for each third-party foundation model in use on Bedrock.

AI agents (Bedrock Agents, AgentCore or custom) run under their own scoped identity with least-privilege access to tools and data. Consequential actions need human approval and every session is logged.

AI systems tested against prompt injection, jailbreaks and data leakage before go-live and after significant changes, with evidence retained.

Inventory of all cryptographic algorithms in use (TLS, database encryption, application-level crypto), with an assessment of quantum vulnerability and a migration plan.