● INDEPENDENT FRAMEWORK · AWS SECURITY V2

AWS Cloud Security Maturity Model

An independent 801 PLANET reference, informed by the public AWS Security Maturity Model v2 structure, for reviewing the current implementation phase and next conditions across ten security capabilities.

This is not an official AWS translation, assessment tool, certification, or assurance. It is an independently authored self-assessment reference and does not replace a security audit or compliance determination.

Published: Jul 19, 2026
Version: 1.0.0
Publisher: 801 PLANET
Technical review: Jeen Lee
Public sources: 3

● IMPLEMENTATION PATH

Four phases for sequencing action—not scoring organizations

Each phase helps order work by balancing likely security impact with implementation and operating effort. It is not a certification grade.

● PHASE 1
Quick Wins
Immediate risk reduction — Prioritize controls that reduce meaningful risk with limited preparation.
● PHASE 2
Foundational
Operational foundation — Apply ownership, policy, and baseline controls consistently across production.
● PHASE 3
Efficient
Efficient operation — Standardize recurring work and reduce operational load with metrics and automation.
● PHASE 4
Optimized
Continuous optimization — Continuously validate and improve controls as threats and business conditions change.

● SECURITY CAPABILITIES

Review ten security capabilities at organization scope

Choose one organization, project, or AWS environment as the scope, then review ownership, process, and repeatable evidence alongside technical controls.

● CAPABILITY 01

Security governance

The ability to manage security accountability, standards, exceptions, and their connection to business risk.

Implementation phase 1 · Owners and escalation path

Every production account has a security owner and shared escalation channel whose validity was checked within the last 90 days.

Operating evidence to verify: Account inventory, owner register, and the latest contact test record.
Priority action: Assign an owner and backup contact path per account, then test delivery through absence and personnel changes.
Next extension: Add contact validation to account provisioning and personnel-change workflows.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Requirements and policy baseline

Business, contractual, and regulatory obligations are maintained as security requirements linked to owners and in-scope systems.

Operating evidence to verify: Requirements register, scope, control owners, and latest review history.
Priority action: Translate applicable regulations and customer commitments into controls with owners and review cadences.
Next extension: Connect role-based training and exception approval to the requirements register.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Standard architecture and exceptions

Approved cloud security standards are delivered through code or templates, and every exception records an owner and expiry date.

Operating evidence to verify: Approved template repository, deployment history, and exception register with expiry handling.
Priority action: Package recurring designs as standard modules and operate change review and exception expiry workflows.
Next extension: Include standard adoption and expired exceptions in monthly risk metrics.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Business-risk optimization

Security accountability and risk metrics are reviewed with business and product metrics to adjust control investment priorities.

Operating evidence to verify: Executive review records, risk acceptances, and investment decisions tied to metric changes.
Priority action: Integrate RACI, risk-acceptance thresholds, and key security indicators into one decision cadence.
Next extension: Feed lessons from incidents, audits, and business changes into standards and investment planning.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 02

Security assurance

The ability to verify with evidence that controls are deployed and operating effectively.

Implementation phase 1 · Central posture review

All production accounts are covered by a common posture review, and critical findings receive an owner and due date.

Operating evidence to verify: Assessment scope, latest posture results, and owner/due-date records for critical findings.
Priority action: Define account coverage, assess against a common baseline, and assign ownership to critical gaps first.
Next extension: Track uncovered accounts and overdue findings as explicit metrics.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Configuration and asset history

Security-relevant assets and configuration changes are continuously recorded with who, when, and what changed.

Operating evidence to verify: Asset inventory, configuration timeline, collection health, and gap alerts.
Priority action: Centralize asset identities and configuration history, and detect collection gaps.
Next extension: Link acceptable-state rules for critical configurations to change approvals.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Repeatable assurance evidence

Evidence for key controls is regenerated on a defined cadence, with failures, exceptions, and remediation tracked together.

Operating evidence to verify: Control-to-evidence mapping, latest report, and closure records for failed controls.
Priority action: Standardize evidence sources, owners, cadence, and retention for each control.
Next extension: Connect audit report generation and corrective-action tracking in one workflow.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Continuous control validation

Key control evidence is collected automatically, and deviations trigger tracked work and automatic revalidation.

Operating evidence to verify: Automated evidence pipeline, deviation tickets, post-fix pass records, and trend metrics.
Priority action: Automate evidence collection, evaluation, ticket creation, and post-remediation revalidation.
Next extension: Compare control effectiveness with operating cost and retire low-value checks.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 03

Identity and access management

The ability to limit human and workload access to the necessary scope and duration.

Implementation phase 1 · Privileged access protection

All privileged users and emergency accounts use strong multi-factor authentication, and top-level accounts are not used for daily work.

Operating evidence to verify: Privileged-account inventory, MFA coverage report, and top-level account use logs.
Priority action: Identify privileged identities, enforce strong authentication, and restrict top-level accounts to emergency procedures.
Next extension: Adopt a shared identity provider and recurring cleanup of unused access.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Temporary credentials and guardrails

Production workloads use temporary credentials by default, while every long-lived key has an owner, purpose, and expiry or rotation deadline.

Operating evidence to verify: Key inventory, last-used dates, temporary-credential adoption, and guardrail evaluation results.
Priority action: Inventory long-lived keys and migrate them to role-based temporary credentials.
Next extension: Use organization guardrails to block risky permissions and legacy instance credential patterns.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Least-privilege review

Human, workload, and customer access is reviewed against usage and job roles, with unnecessary permissions removed.

Operating evidence to verify: Latest access review, removed permissions, unapproved exceptions, and customer-identity control records.
Priority action: Combine permission-use data and job-role baselines to operate recurring review and revocation.
Next extension: Separate boundaries and ownership for customer identities and internal operational identities.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Contextual just-in-time elevation

High-risk privileges are issued only for an approved time window, and requests deploy only after data-boundary and policy validation.

Operating evidence to verify: Elevation request, approval, and automatic-expiry records plus policy and boundary test results.
Priority action: Build a temporary-elevation workflow covering approval, issuance, expiry, and audit.
Next extension: Combine usage data, data perimeters, and automated tests in the policy delivery pipeline.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 04

Threat detection

The ability to identify suspicious activity across accounts, workloads, and networks and turn it into investigable signals.

Implementation phase 1 · Core activity logging and alerts

Administrative activity from production accounts is centrally retained, and material threat or spend anomalies reach an active response channel.

Operating evidence to verify: Logging coverage, retention settings, and recent alert-delivery and response tests.
Priority action: Verify log coverage and retention, then test routing, ownership, and response for critical signals.
Next extension: Continuously monitor for uncovered accounts and alert-delivery failures.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Detection operating baseline

Each material detection has an owner, severity, response objective, and exception path, with false positives and unattended alerts reviewed regularly.

Operating evidence to verify: Detection catalog, response objectives, tuning history, and unattended-alert trends.
Priority action: Create a detection catalog and severity standard, then review handling quality monthly.
Next extension: Automatically enrich alerts with asset criticality and identity/network context.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Correlation and custom detection

Multiple security signals are correlated centrally, while organization-specific attack scenarios are managed as tested detection rules.

Operating evidence to verify: Data-source inventory, custom-rule repository, test results, and detection-quality metrics.
Priority action: Define a common security data schema and priority detection scenarios for central analysis.
Next extension: Regression-test rule changes with historical replay and simulated events.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Threat-informed adaptation

External threat intelligence, internal network flows, and incident lessons continuously influence detection priorities and rule improvements.

Operating evidence to verify: Threat-source assessments, flow-analysis results, and detections added or revised after incidents.
Priority action: Score threat intelligence for confidence and relevance, then connect it to internal telemetry.
Next extension: Turn detection, investigation, and retirement of threat hypotheses into a measurable feedback loop.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 05

Vulnerability management

The ability to discover infrastructure and software vulnerabilities and reduce them in time according to business risk.

Implementation phase 1 · Exposure and critical flaw inventory

Internet-exposed assets and critical vulnerabilities are inventoried with an owner, severity, and remediation deadline.

Operating evidence to verify: External asset list, latest scan, and owner/deadline/status for critical findings.
Priority action: Scan externally exposed assets first and assign owners and deadlines using exploitability and business criticality.
Next extension: Connect new-asset provisioning to vulnerability coverage so assets cannot be omitted.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Recurring infrastructure and application review

Supported infrastructure and applications are covered by recurring vulnerability review and tracked against risk-based remediation objectives.

Operating evidence to verify: Asset-to-scan coverage, SLA performance, exceptions, and overdue trends.
Priority action: Define coverage and risk-based SLAs across operating systems, containers, dependencies, and applications.
Next extension: Require compensating controls and expiry for exceptions, and escalate overdue remediation.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Prevention in delivery workflows

High-risk vulnerability checks are embedded in build and release workflows, with team security owners reviewing exceptions and recurrence prevention.

Operating evidence to verify: Pipeline scan results, block/exception records, and recurring-vulnerability trends.
Priority action: Establish pre-release checks and risk-based gates, supported by security owners within development teams.
Next extension: Remove recurring defects through secure templates, libraries, and developer education.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Risk-based continuous improvement

Dedicated ownership continuously reprioritizes remediation using exploitability, asset value, and exposure paths, with outcomes measured.

Operating evidence to verify: Risk-ranked backlog, mean exposure time, recurrence rate, and remediation-effectiveness records.
Priority action: Operate on actual risk reduction and mean exposure time rather than raw vulnerability counts.
Next extension: Improve automated prioritization and validation using attack paths and compensating controls.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 06

Infrastructure protection

The ability to reduce network, compute, and account exposure while providing safe operational paths.

Implementation phase 1 · Remove risky administration exposure

Internet-exposed administration ports and remote-management endpoints are inventoried, with no unapproved exposure.

Operating evidence to verify: Public-endpoint inventory, approvals, and latest external-exposure review.
Priority action: Review all administration exposure and move access to private, centrally managed paths.
Next extension: Block newly introduced public administration paths before deployment through policy.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Account and network baseline boundaries

Accounts and networks are separated by environment and business criticality, and operational access uses only audited management paths.

Operating evidence to verify: Account structure, network flows, administration logs, and boundary exceptions.
Priority action: Separate production, non-production, and security functions with account and network boundaries.
Next extension: Automatically apply common account-provisioning and administration-access policies.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Verified images and runtime protection

Compute images are built and verified through an approved pipeline, with runtime threats and anomalous outbound traffic monitored.

Operating evidence to verify: Image build/sign/scan history, deployed versions, and runtime detection and action records.
Priority action: Automatically build patched baseline images and observe integrity, malicious behavior, and outbound communication.
Next extension: Automatically quarantine or replace stale images and unapproved runtime environments.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Continuously verified access

User, device, and workload context is verified for each access request, while operational risk is reduced through managed abstractions where appropriate.

Operating evidence to verify: Contextual access decision logs, policy tests, and recorded risk reduction from managed-service adoption.
Priority action: Adopt access policies that do not trust network location alone and validate device and workload posture.
Next extension: Continuously assess risk and cost of self-managed infrastructure and migrate to managed alternatives where justified.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 07

Data protection

The ability to understand data sensitivity, location, and flow and prevent exposure or loss.

Implementation phase 1 · Prevent unintended public exposure

Important data stores are private by default, and any public exception has approval, an owner, and an expiry date.

Operating evidence to verify: Data-store exposure status, policy results, and public-exception approval and expiry records.
Priority action: Review public data stores and apply default-deny controls with an exception workflow.
Next extension: Prioritize automatic discovery and alerting for public stores containing sensitive data.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Encryption, backup, and sensitivity baseline

Important data has known sensitivity and ownership, encryption at rest, recoverable backups, and recorded restore tests.

Operating evidence to verify: Data inventory, encryption coverage, backup policies, and latest restore-test results.
Priority action: Classify important data by location, sensitivity, and retention, then apply consistent encryption and backup baselines.
Next extension: Review key and backup access plus restore success rates on a defined cadence.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Transit and lifecycle controls

Important data flows are protected in transit, with retention, deletion, and access policies applied automatically by classification.

Operating evidence to verify: Data-flow map, encryption policy checks, retention/deletion execution, and violation records.
Priority action: Map data flows and apply strong transport protection and classification-based lifecycle policies.
Next extension: Detect policy violations and unknown data movement and route them to an owner.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · AI data boundaries and continuous validation

Data-use paths, including generative AI, validate input, output, and training-data boundaries and repeat sensitive-data leakage tests.

Operating evidence to verify: AI data-flow inventory, policy checks, leakage tests, and blocking/improvement records.
Priority action: Inventory AI data flows and external model transfers, then enforce allowed-data, retention, and masking rules.
Next extension: Continuously test prompts, responses, and retrieved data for leakage and policy bypass.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 08

Application security

The ability to reduce application risk throughout design, development, delivery, and operation.

Implementation phase 1 · Baseline protection for public applications

Internet-facing applications use a managed web-attack baseline, with detection and blocking results reviewed by an owner.

Operating evidence to verify: Public application inventory, protection coverage, and detection/blocking/false-positive review records.
Priority action: Inventory public endpoints and introduce a common managed web-protection baseline, starting in observation mode.
Next extension: Progressively enable blocking after false-positive review and test bypass paths as well.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Secure development baseline

Security participates in design and change review for important applications, and long-lived secrets are not stored in code or configuration.

Operating evidence to verify: Security design reviews, secret-scan results, and central secret-store adoption.
Priority action: Define changes requiring security review and move secrets to central storage or short-lived credentials.
Next extension: Automatically scan code and build artifacts for secrets and high-risk patterns.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Threat-model-driven defenses

Threat models for important features evolve with changes and directly inform custom defenses, DDoS response, and security tests.

Operating evidence to verify: Current threat models, mitigation owners, and custom-rule, load, and security test results.
Priority action: Analyze assets, trust boundaries, and abuse cases to define priority mitigations and validation methods.
Next extension: Link threat-model mitigations to delivery policies and regression tests.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Continuous adversarial validation

Independent adversarial validation runs regularly, and findings feed design standards, detections, and engineering backlogs.

Operating evidence to verify: Attack simulation plans/results, remediation validation, and resulting design and detection changes.
Priority action: Run attack simulations against important paths with defined scope, safeguards, and success criteria.
Next extension: Improve not only the defect but also missed detection and underlying design causes.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 09

Incident response

The ability to classify, contain, and recover from security events and turn lessons into control improvements.

Implementation phase 1 · Critical finding handling

Critical security findings are acknowledged within a defined time, with containment, mitigation, and closure evidence recorded.

Operating evidence to verify: Critical alert tickets, acknowledgement times, and containment/closure approvals and evidence.
Priority action: Define criticality, first responder, response objective, and authority for immediate containment.
Next extension: Sample recent critical alerts to close gaps in ownership and closure evidence.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Role-based response procedures

Response procedures for major incident types define technical, legal, executive, and customer-communication roles and contact paths.

Operating evidence to verify: Incident playbooks, role matrix, contact tests, and latest revision history.
Priority action: Document decision, containment, evidence preservation, recovery, and communication for priority incident types.
Next extension: Test contacts and authority through staff absence and third-party participation.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Exercises, automation, and causal analysis

Recurring exercises validate playbooks, repeatable actions are automated, and post-incident causes and recurrence prevention are tracked.

Operating evidence to verify: Exercise results, playbook changes, automated-action logs, and completed causal and recurrence-prevention actions.
Priority action: Run quarterly scenario exercises and reviews, automating safe repetitive actions first.
Next extension: Connect lessons from exercises and incidents to detection, architecture, and training backlogs.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Integrated security orchestration

Detection, investigation, approval, containment, and configuration recovery operate as an integrated workflow improved through outcome metrics.

Operating evidence to verify: Integrated response flow, approval/action/rollback logs, and response-time and quality trends.
Priority action: Define approval boundaries and failure recovery for automated actions, integrating security operations with work tracking.
Next extension: Optimize playbooks using mean detection, containment, and recovery time plus automation success rates.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

● CAPABILITY 10

Resiliency

The ability to sustain critical services through failures and attacks and recover within objectives.

Implementation phase 1 · Recovery objectives and single points of failure

Critical services have business-approved recovery-time and data-loss objectives, with major single points of failure and current mitigations known.

Operating evidence to verify: Service impact analysis, approved RTO/RPO, and single-point-of-failure mitigation backlog.
Priority action: Set impact and recovery objectives for critical services and record human, system, and third-party single points of failure.
Next extension: Assign owners and short-term mitigations to the largest objective gaps.
Implementation check: Do not treat a setting in a few accounts as organization-wide completion.

Solution categories to consider

Implementation phase 2 · Availability-zone failure readiness

Critical production services are designed to tolerate a single availability-zone failure, with failover and data restoration tested.

Operating evidence to verify: Architecture, failover tests, restore results, and measured recovery time and data loss.
Priority action: Validate multi-zone design and backup recovery for both stateful and stateless components.
Next extension: Compare test results with objectives and reduce manual steps and bottlenecks.
Implementation check: Verify actual coverage and exception records, not only the existence of policy documents.

Solution categories to consider

Implementation phase 3 · Validated disaster recovery plan

Service disaster-recovery plans include dependencies, priorities, and decision authority, and are validated through recurring exercises.

Operating evidence to verify: Current DR plan, exercise results, RTO/RPO performance, and corrective actions.
Priority action: Document recovery order and external dependencies and exercise the plan regularly in realistic environments.
Next extension: Prioritize automation and capacity/data validation for steps that miss objectives.
Implementation check: Measure repeatable operating outcomes rather than treating tool adoption as maturity.

Solution categories to consider

Implementation phase 4 · Automated recovery and chaos validation

Multi-region recovery procedures are automated, and controlled failure experiments continuously validate assumptions, alerts, and automatic recovery.

Operating evidence to verify: Automated DR run logs, chaos experiment plans/stop conditions/results, and resulting improvements.
Priority action: Make recovery environment creation, data transition, traffic cutover, validation, and return repeatable through automation.
Next extension: Run safe failure experiments regularly and backlog hidden coupling and recovery automation failures.
Implementation check: Pair automation with approval boundaries, stop conditions, and post-action review.

Solution categories to consider

Which prerequisite controls should your environment close first?

Review 40 pieces of operating evidence to see the current phase across ten capabilities and the first priorities for the next 90 days.

Assess cloud security maturity →

Turn the self-assessment into a security baseline and delivery plan

Review your AWS account structure and operating evidence to define prerequisite controls, completion criteria, and a practical 90-day scope.

● Already trusted by teams across finance · healthcare · media · public

Review a cloud security improvement path →

AWS Cloud Security Maturity Model

Four phases for sequencing action—not scoring organizations

Quick Wins

Foundational

Efficient

Optimized

Review ten security capabilities at organization scope

Turn the self-assessment into a security baseline and delivery plan