AWS Well-Architected Security Pillar

Provide developers with secure coding training covering OWASP Top 10, AWS specific risks, IAM least privilege and use of managed security services.

• training curriculum
• completion records by role
• AWS specific modules
• annual refresher schedule

• one off onboarding training only
• no AWS specific content
• completion not tracked

Embed SAST, SCA, IaC scanning, container image scanning and DAST into CI CD pipelines so vulnerabilities are caught and blocked before deployment.

• pipeline configuration with security gates
• scanner findings dashboards
• build failure on critical findings policy
• exception process

• scans run but do not block
• no IaC scanning
• container images deployed without scan

Conduct authorised penetration tests against applications and infrastructure on at least an annual cadence and after significant change, within AWS testing policy.

• pen test reports
• remediation tracker
• scope and methodology document
• AWS notification or policy compliance

• pen tests skipped or scope narrowed
• findings never remediated
• no retest

Require peer review on every code change with explicit security review criteria, and use CodeGuru Reviewer or similar to augment human review.

• branch protection rules
• code review checklist
• CodeGuru Reviewer findings
• review approval logs

• solo commits to main
• review checkboxes not enforced
• security criteria absent

Use private package repositories such as CodeArtifact or ECR with curation, scanning and provenance so applications consume only approved dependencies.

• CodeArtifact domain and repos
• ECR repository policies
• approved package list
• vulnerability scanning on pull

• direct pulls from public registries
• no SBOM
• unpatched transitive dependencies

Deploy through automated pipelines with separation of duties, approvals and audit so no human pushes code or infrastructure directly to production.

• pipeline definitions
• approval gate configuration
• production deploy audit log
• human deploy exception register

• manual deployments to production
• no separation between build and deploy roles
• no audit of deployments

Treat the CI CD pipeline itself as a sensitive workload and review its IAM roles, secrets handling, runner isolation and tamper resistance regularly.

• pipeline threat model
• IAM role review for pipelines
• self hosted runner hardening evidence
• OIDC trust policies

• pipeline roles have AdministratorAccess
• long lived deploy keys
• shared runner pool with no isolation

Establish security champions inside each workload team, give them training and tooling and measure security KPIs alongside delivery metrics.

• security champion roster
• champion charter and time allocation
• team security KPI dashboard
• shared OKRs

• security team owns all risk
• no champions identified
• no security KPIs for product teams

Understand and document the classification scheme that applies to the data the workload processes, including handling requirements, storage locations, owners and the legal obligations attached to each class.

• data classification policy with defined sensitivity levels
• data inventory for the workload mapped to classes, locations and owners
• legal and regulatory obligations mapped to each class
• evidence the scheme is communicated to builders

• classification policy exists but no workload data is mapped to it
• no named data owner so handling decisions stall
• classification levels defined with no handling rules attached

Apply protection controls proportionate to each defined sensitivity level, with published guidance on approved storage services, locations and required configuration per class.

• per-class handling guidance naming approved services and configurations
• policy-as-code or guardrails enforcing the per-class configuration
• exception register for data held outside approved locations
• evidence of periodic checks that controls match classification

• single protection level applied to all data regardless of sensitivity
• guidance published but not enforced by any guardrail
• sensitive data found in stores approved only for lower classes

Use Macie, Glue, Comprehend and lifecycle automation to continuously discover and classify data without relying on manual surveys.

• Macie job schedule and findings
• automated tagging Lambda
• discovery coverage metrics

• Macie disabled or unfunded
• manual annual classification only
• new data stores undiscovered

Define data lifecycle management that scales, covering how data is handled at ingestion, how sensitivity is reduced through masking or tokenisation, retention periods, provenance tracking and destruction.

• retention schedule per data class
• lifecycle policies configured on the storage services
• masking or tokenisation design applied near the point of ingestion
• provenance or lineage records
• evidence of executed deletions

• data retained indefinitely because no schedule exists
• lifecycle rules configured on some buckets only
• deletion claimed but never evidenced
• sensitivity reduction applied late, after wide copying

Centralise key management in AWS KMS or CloudHSM, define key hierarchies, use customer managed keys for sensitive data and rotate keys on policy.

• KMS key inventory with rotation status
• key policies
• CloudHSM cluster configuration
• key owner mapping

• AWS managed keys only for sensitive data
• no rotation
• broad kms:* in key policies

Ensure all data stores encrypt data at rest using KMS keys, enforce by default through account settings, SCPs and Config rules.

• S3 default encryption settings
• EBS encryption by default
• RDS encryption status
• Config rules for unencrypted resources
• SCP denying unencrypted creation

• S3 buckets without encryption
• EBS volumes unencrypted
• RDS snapshots unencrypted

Use automated controls such as Config remediation, EventBridge actions and SCPs to detect and correct unencrypted or improperly protected data automatically.

• Config managed rules and remediation actions
• auto remediation Lambda functions
• remediation success rate

• manual remediation only
• Config rules detect but do not remediate
• no SCP enforcement

Layer IAM, resource policies, KMS grants, S3 Access Points and VPC endpoint policies to enforce least privilege access to data and prevent exfiltration.

• S3 bucket policies with PrincipalOrgID condition
• VPC endpoint policies
• KMS key policies and grants
• Access Points configuration

• bucket policies allow *
• no VPC endpoint policy restriction
• KMS grants left in place after use

Use AWS Certificate Manager and Private CA to issue, deploy and rotate TLS certificates, avoiding manual installation and unmanaged certificate stores.

• ACM certificate inventory
• Private CA hierarchy
• certificate expiry monitoring
• renewal automation logs

• self signed certs in production
• expired certificates
• manual installation

Require TLS 1.2 or higher for all client to service and service to service traffic, including within VPCs, and disable legacy protocols and ciphers.

• ELB security policies
• API Gateway TLS settings
• CloudFront viewer protocol policy
• internal service TLS configuration

• HTTP listeners still open
• TLS 1.0 or 1.1 accepted
• internal traffic unencrypted

Verify the identity of network communications by using protocols that support authentication, such as TLS or IPsec, between services, applications and users.

• inventory of service-to-service flows with the protocol used
• TLS and mutual TLS configuration for internal endpoints
• certificate or identity issuance process for workload identities
• scan results confirming unauthenticated protocols are absent

• internal traffic left unauthenticated on the assumption the network is trusted
• TLS terminated at the edge with plaintext behind it
• certificate validation disabled to work around expiry errors

Enable CloudTrail across all accounts and regions, VPC Flow Logs, application logs and service-specific logs, centralised to a dedicated log archive account.

• organisation CloudTrail configuration
• VPC Flow Log enablement report
• central log archive account design
• CloudWatch log group inventory

• CloudTrail not multi-region
• data events disabled
• logs stored only in source account

Aggregate security telemetry into standardised destinations such as S3 log archive buckets, Security Hub and a centralised SIEM so analysts and automation can correlate across sources.

• S3 log archive bucket policies
• Security Hub aggregator configuration
• Security Lake setup
• SIEM ingestion pipelines

• logs scattered across accounts
• no Security Hub aggregator region
• SIEM missing key sources

Enrich findings with asset, identity, business owner and threat intel context so responders can triage quickly, and correlate signals across GuardDuty, Security Hub and other tools.

• enrichment pipeline architecture
• asset inventory feed to SIEM
• correlation rule documentation
• ownership tags

• raw alerts without context
• no asset to owner mapping
• duplicate alerts across tools

Use automated remediation through EventBridge, Systems Manager Automation or Security Hub custom actions to fix common misconfigurations without manual handoffs.

• EventBridge rule inventory
• SSM Automation runbooks
• remediation success metrics
• exception approval workflow

• manual ticket remediation only
• no auto-remediation for public S3 or open security groups
• remediation untested

Enforce MFA, strong password policies and phishing-resistant authentication factors for all human users accessing AWS, including IAM Identity Center and federated identities.

• IAM Identity Center MFA configuration
• password policy export
• WebAuthn or FIDO2 token inventory
• MFA coverage report

• MFA optional for some users
• SMS only MFA
• no password complexity baseline

Replace long-lived IAM access keys with short-lived credentials issued via IAM roles, IAM Identity Center, STS or workload identity federation.

• IAM access key age report
• IAM Identity Center permission set inventory
• role assumption CloudTrail logs
• key rotation policy

• long-lived keys for human users
• keys older than 90 days
• shared service account keys

Store application secrets, database credentials and API keys in AWS Secrets Manager or Parameter Store with encryption, automatic rotation and least privilege access policies.

• Secrets Manager inventory
• rotation lambda configuration
• secret access IAM policies
• git secret scanning results

• secrets in environment variables or code
• no rotation enabled
• broad read access to all secrets

Federate workforce access to AWS through a single corporate identity provider via IAM Identity Center or SAML so that user lifecycle, MFA and access reviews are centrally governed.

• IAM Identity Center configuration
• SAML or OIDC IdP trust
• SCIM provisioning logs
• joiner mover leaver process

• local IAM users for workforce
• no SCIM deprovisioning
• duplicate identities across accounts

Use IAM credential reports, Access Advisor and Access Analyzer to find unused credentials, rotate keys on schedule and remove stale users and roles.

• IAM credential report
• Access Advisor last used data
• rotation tickets
• stale identity removal log

• no scheduled credential review
• dormant users not disabled
• keys never rotated

Assign permissions via groups, permission sets or attribute-based access control rather than to individual users to simplify management and reduce permission sprawl.

• group and permission set design
• ABAC tag policy
• direct user policy attachment exception list

• policies attached directly to users
• no tagging strategy for ABAC
• permission set sprawl

Document who or what requires access to each resource, what actions are permitted and under what conditions, so least privilege policies can be designed and validated against intent.

• access requirements matrix per workload
• role catalogue
• data classification mapping to roles

• no documented access intent
• policies built ad hoc
• no link from requirement to policy

Author IAM policies that grant only the specific actions, resources and conditions required, refining policies from broad starting points using Access Analyzer policy generation.

• IAM Access Analyzer policy generation outputs
• policy review records
• permissions boundary definitions
• wildcard policy exception register

• AdministratorAccess used broadly
• wildcards in actions and resources
• no permissions boundaries

Define a documented break-glass procedure for emergency access that bypasses normal SSO when the IdP is unavailable, with strong MFA, monitoring and post-use review.

• break glass procedure document
• isolated break glass account credentials in vault
• alerts on use
• post-use review log

• no break glass plan
• credentials stored insecurely
• no alarm on use

Use IAM Access Analyzer unused access findings and Access Advisor service last accessed data to remove permissions that have not been exercised over time.

• Access Analyzer unused access findings closure log
• service last accessed reports
• quarterly permission reduction metrics

• permissions only ever expand
• no cleanup cadence
• unused permissions remain for years

Apply Service Control Policies, resource control policies and declarative guardrails at the organisation or OU level to enforce non-negotiable security boundaries.

• SCP catalogue with rationale
• RCP definitions
• Control Tower guardrail status
• deny region or service evidence

• FullAWSAccess SCP only
• no deny on disabling logging
• no region restrictions

Tie AWS access grant and revocation to HR joiner mover leaver events so permissions update automatically when roles change or employment ends.

• SCIM logs from IdP
• JML workflow document
• deprovisioning evidence within SLA
• access recertification reports

• leavers retain access
• movers accumulate permissions
• no scheduled recertification

Use IAM Access Analyzer to detect resources that grant public or external account access and validate each finding against documented intent.

• Access Analyzer external access findings
• approved sharing register
• S3 public access block status
• finding closure tickets

• public S3 buckets unintentionally
• cross-account trust without business justification
• Access Analyzer disabled in regions

Use AWS RAM, resource policies and Organizations conditions to share resources only within trusted account boundaries, avoiding broad public or cross-org sharing.

• AWS RAM share inventory
• resource policies with aws:PrincipalOrgID condition
• approval workflow for new shares

• resource policies allow *
• shares outside organisation without justification
• RAM shares with stale principals

When granting third-party access use IAM roles with external ID, condition keys, time bound credentials and contractual controls rather than long-lived IAM users.

• third party access role inventory
• external ID enforcement evidence
• vendor contracts with security clauses
• revocation evidence

• IAM users issued to vendors
• no external ID on cross-account roles
• no expiry on vendor access

Maintain an up to date roster of incident responders, executives, legal, comms, AWS support contacts and external IR retainer firms with on call rotations.

• IR contact list
• on call schedule
• AWS support plan
• external IR retainer contract

• stale contact list
• no AWS Enterprise Support
• no IR retainer

Document IR plans covering detection, triage, containment, eradication, recovery and lessons learned, mapped to specific AWS scenarios such as credential compromise.

• incident response plan document
• scenario-specific runbooks (key compromise, data exfil, ransomware)
• RACI matrix

• generic IR plan with no AWS specifics
• no runbooks for cloud scenarios
• plan untested

Pre-provision a forensic account, isolated VPC, tooling AMIs, IAM roles and EBS snapshot procedures so responders can acquire and analyse evidence quickly.

• forensic account design
• evidence acquisition runbook
• forensic AMI inventory
• chain of custody template

• no dedicated forensic account
• evidence collection ad hoc
• no chain of custody process

Develop incident response playbooks giving prescriptive steps for anticipated incident scenarios, and test them so responders follow a known structure rather than improvising.

• playbook set covering anticipated scenarios such as denial of service, ransomware and credential compromise
• playbooks for known finding and alert types
• records of playbook tests or exercises with dates and participants
• playbook revision history after incidents or tests

• a single generic plan with no scenario-specific steps
• playbooks written once and never exercised
• no playbook for the alert types the detection tooling actually raises

Pre-provision the access incident responders need, using temporary credentials and prepared elevation paths so investigation is not delayed by access requests during an event.

• responder role definitions and their permission sets
• pre-provisioned break-glass access procedure and approval path
• evidence that responder access uses temporary rather than long-lived credentials
• access test records confirming responders can reach the needed accounts

• root account used for incident response
• permissions edited by hand during an incident
• responder access never tested so gaps surface mid-incident

Pre-stage IR tooling, IAM roles and accounts before incidents so responders are not racing to deploy capabilities while under attack.

• IaC for IR account
• pre-deployed IR roles
• tool installation evidence
• readiness checklist

• IR tooling deployed reactively
• IR account not pre-provisioned
• roles need approval mid-incident

Conduct regular game days and tabletop exercises for credential compromise, ransomware and data breach scenarios to test plans, tools and team readiness.

• game day schedule and scenarios
• tabletop minutes
• lessons learned register
• remediation actions tracked

• no exercises run
• lessons learned never implemented
• same scenario repeated

Run blameless post-incident reviews, capture root causes and contributing factors, and feed improvements back into controls, runbooks and training.

• post incident review template
• completed PIRs
• improvement backlog and closure
• control changes from PIRs

• no formal PIR process
• PIRs blame individuals
• actions never closed

Design VPCs with separate public, private and restricted subnets per workload tier, isolating data tiers from internet-facing components.

• VPC and subnet design diagrams
• route table configuration
• NACL and security group baselines
• Transit Gateway topology

• flat VPCs with single subnet tier
• databases in public subnets
• no NAT or egress controls

Restrict traffic within each network layer to only the flows each workload component needs, controlling both traffic entering from external systems and traffic between internal components.

• security group and network ACL rule sets with justification per rule
• documented allowed flow matrix for the workload
• evidence of review or automated analysis of overly permissive rules

• wide open internal traffic once inside the perimeter
• 0.0.0.0/0 ingress rules left from testing
• no flow inventory so unused rules are never removed

Use deep packet inspection through AWS Network Firewall, Gateway Load Balancer with third-party appliances or service mesh to inspect and filter traffic for threats.

• inspection VPC design
• Network Firewall stateful rules
• GWLB appliance configuration
• TLS inspection policy

• no inspection on east-west traffic
• egress to internet unrestricted
• inspection bypassed by routing

Manage network controls as code through CloudFormation, Terraform and Firewall Manager so policies deploy consistently and drift is detected automatically.

• IaC repositories for network controls
• Firewall Manager policies
• drift detection alerts
• pipeline scans

• console changes to security groups
• no centralised firewall policy
• drift not detected

Continuously scan EC2 instances, container images and Lambda functions with Amazon Inspector and remediate findings on a risk-prioritised SLA.

• Inspector findings dashboard
• patch SLA policy
• Systems Manager Patch Manager compliance
• ECR scan results

• Inspector not enabled org wide
• critical CVEs older than SLA
• container images unscanned

Provision compute from hardened baseline images and obtain runtime dependencies such as container images and libraries only from trusted registries with verified signatures.

• golden image build pipeline definition and hardening standard applied
• private registry inventory and access policy
• signature verification step in the build or admission path
• image patch and rebuild cadence records

• instances built from unmanaged public images
• container images pulled straight from public registries at deploy time
• no signature verification so tampered artefacts run undetected
• golden images never rebuilt so they drift out of patch

Perform deployment, configuration, maintenance and investigation on compute through automation, restricting interactive human access to emergency or sandbox situations.

• runbooks and automation documents covering routine compute tasks
• break-glass procedure for interactive access with approval steps
• session logs for any interactive access with justification
• metrics on the proportion of tasks executed by automation

• routine SSH or RDP access as normal practice
• break-glass credentials shared and never rotated
• interactive sessions unlogged so actions cannot be reconstructed

Cryptographically verify the integrity of software artefacts the workload consumes and sign software the organisation produces so unauthorised changes are detectable before execution.

• signing key management procedure and key inventory
• signature verification enforcement in the build or admission controller
• record of artefacts rejected for failed verification
• certificate validation policy for vendor download sources

• downloads trusted on source reputation alone
• signing keys held on build agents with broad access
• verification implemented as a warning rather than a hard fail

Automate scanning, patching and remediation of compute resources so protection operations run without human intervention, including dependency freshness checks in the delivery pipeline.

• automated patch schedule and its execution records
• automated remediation rules and their trigger history
• dependency scanning results from the CI/CD pipeline
• mean time to patch measured by severity

• patching raised as tickets that queue behind feature work
• remediation automation built but left in report-only mode
• dependency scanning absent from the pipeline

Use AWS Organizations and multiple AWS accounts to separate workloads, environments and data classifications, enforcing isolation boundaries that contain blast radius and simplify governance.

• AWS Organizations OU diagram
• account inventory with purpose and owner
• SCP policy set
• landing zone design document (Control Tower or custom)
• account vending process

• single monolithic account
• no SCP guardrails
• production and non-prod sharing accounts
• ad hoc account creation without baseline

Protect the root user of every AWS account with strong MFA, no programmatic access keys, monitored email and contact details, and use root only for tasks that explicitly require it.

• root MFA evidence per account
• root access key absence report
• alternate contact configuration
• root usage CloudTrail alerts
• break glass procedure

• no MFA on root
• active root access keys
• shared root email mailbox
• no alarm on root sign in

Derive control objectives from compliance, regulatory and business requirements, document them, and trace each to implemented AWS controls with measurable validation.

• control objectives register
• compliance to control mapping spreadsheet
• validation test results
• Audit Manager assessments

• objectives not documented
• no mapping to specific AWS controls
• controls untested
• drift between policy and implementation

Subscribe to threat intelligence sources, AWS security bulletins and CVE feeds, and incorporate emerging threats into risk assessments and detection rules.

• threat intel feed subscriptions
• AWS Security Bulletin tracker
• CVE triage workflow
• monthly threat review minutes

• no formal threat feed subscription
• AWS bulletins ignored
• no link from intel to detections

Reduce the surface the team must secure itself by preferring AWS managed services that shift provisioning, patching and backup of underlying components to the provider, and weigh that management overhead when selecting services.

• service selection record showing managed versus self-managed options considered
• shared responsibility mapping per service in the workload
• total cost of ownership analysis covering security maintenance effort
• AWS Artifact compliance reports relied on for the managed components

• self-managing databases, queues or key stores with no rationale
• no record of which controls the provider operates
• shared responsibility boundary undocumented so patching ownership is ambiguous

Define standard security controls and configurations as infrastructure as code, version control them, test them in a pipeline and deploy them automatically across environments.

• IaC templates holding the standard security baseline
• version control history for those templates
• CI/CD pipeline definition showing security tests before deploy
• drift detection and alerting configuration

• console-applied security settings that no template reproduces
• no pipeline gate so untested changes reach production
• drift never detected because no baseline comparison runs

Conduct threat modeling for each workload using STRIDE or similar, prioritise mitigations against business impact and review models on significant change.

• threat model documents (STRIDE)
• data flow diagrams
• mitigation backlog with priority
• review cadence record

• no threat models
• models stale after major changes
• threats identified but not tracked to closure

Review new security services and features from the provider and partners on a regular cadence and adopt those that improve the workload's security posture.

• cadence and minutes of the security service review
• backlog or decision log of features evaluated with adopt or defer rationale
• record of features adopted and the posture change measured

• security tooling frozen at launch architecture
• no owner for evaluating new provider capabilities
• adoption decisions taken with no recorded rationale