AWS Landing Zone Checklist for Regulated Industries

Building an AWS landing zone for a regulated industry is fundamentally different from setting up infrastructure for a startup that can iterate on compliance later. In fintech, iGaming, healthcare, and financial services, compliance is not a feature you bolt on after launch — it is a structural requirement that shapes every architectural decision from the first account you create.

This checklist is drawn from dozens of landing zone implementations we have delivered for clients subject to PCI-DSS, SOC 2 Type II, ISO 27001, and GDPR. Use it as a blueprint, not a menu. In regulated environments, skipping items creates audit findings that are expensive to remediate retroactively.

Account Structure

A well-designed multi-account strategy is the foundation of every compliant landing zone. It enforces blast radius isolation at the AWS account boundary — the strongest isolation primitive available.

Checklist

• Management account reserved exclusively for AWS Organizations administration and billing. No workloads run here.
• Security account for centralized security tooling: GuardDuty delegated administrator, Security Hub aggregation, detective controls.
• Log archive account with immutable storage for CloudTrail, Config, VPC Flow Logs, and application logs. This account should have the most restrictive access in your entire organization.
• Shared services account for CI/CD pipelines, artifact repositories, shared DNS, and internal tooling.
• Network account (hub) for Transit Gateway, centralized egress, DNS resolution, and network firewall.
• Separate workload accounts per environment (dev, staging, production) and per compliance boundary. PCI-DSS scoped workloads must be in their own accounts to minimize the Cardholder Data Environment (CDE).
• Sandbox accounts for experimentation, isolated from production with strict SCPs.

PCI-DSS note: The PCI Council requires clear scoping of the CDE. Placing PCI workloads in dedicated accounts with no connectivity to non-PCI environments is the cleanest way to demonstrate scope boundaries to your QSA.

SOC 2 note: Auditors want to see logical separation between environments. Account-level isolation is the most defensible control you can present.

Service Control Policies

SCPs are the guardrails that prevent well-meaning engineers from accidentally creating compliance violations. They operate at the AWS Organizations level and cannot be overridden by IAM policies within member accounts.

Checklist

• Deny disabling CloudTrail in all accounts. This is non-negotiable for every compliance framework.
• Deny disabling GuardDuty, Config, and Security Hub in member accounts.
• Region restrictions — limit workloads to approved regions. GDPR requires data processing within the EU for EU citizen data; restrict EU-scoped accounts to eu-west-1, eu-central-1, and other approved regions.
• Deny creation of IAM users with console access in workload accounts. All human access flows through IAM Identity Center.
• Deny public S3 buckets at the organization level (with exceptions for specific accounts like a static website hosting account).
• Deny launch of non-approved instance types if your compliance framework restricts compute resources.
• Deny modification of security baseline resources (log buckets, CloudTrail trails, Config recorders).
• Require encryption on EBS volumes, RDS instances, and S3 buckets through condition keys.

ISO 27001 note: Annex A.12.1.4 requires separation of development, testing, and operational environments. SCPs that prevent cross-environment access are a strong implementation of this control.

Identity and Access Management

Identity is the most common source of compliance findings. Federated identity with short-lived credentials is the gold standard.

Checklist

• AWS IAM Identity Center (SSO) as the single entry point for all human access. Federate with your corporate IdP (Okta, Azure AD, Google Workspace).
• MFA enforced on all human identities. Hardware security keys (FIDO2) for administrative access to the management and security accounts.
• Permission sets following least privilege. Use AWS managed policies as a starting point, then scope down based on actual usage (IAM Access Analyzer).
• No long-lived access keys in production accounts. CI/CD pipelines use OIDC federation with IAM roles; applications use instance profiles or ECS task roles.
• Privileged access management for break-glass scenarios: a documented, auditable process for temporary elevated access, with automatic expiration.
• Regular access reviews — quarterly at minimum, automated with IAM Access Analyzer to identify unused permissions.

PCI-DSS Requirement 7: Restrict access to cardholder data by business need to know. Permission sets for CDE accounts should grant the minimum access needed for the specific job function.

GDPR Article 32: Appropriate technical measures to ensure security of processing. Federated identity with MFA and least-privilege access is a direct implementation.

Network Segmentation

Network architecture in regulated environments must enforce segmentation that maps to your compliance boundaries.

Checklist

• Transit Gateway as the central hub for all inter-account connectivity. Tag and document every attachment.
• Network Firewall or third-party NGFW for centralized egress inspection. PCI-DSS requires stateful inspection of all traffic leaving the CDE.
• VPC design with private subnets by default. Public subnets only where absolutely required (load balancers, bastion hosts).
• CIDR planning with room for growth. Document the allocation scheme. Overlapping CIDRs are a painful problem to fix later.
• Security groups as the primary workload-level firewall, with NACLs as a secondary defense layer.
• VPC endpoints for AWS service access (S3, DynamoDB, KMS, CloudWatch, SSM) to keep traffic off the public internet.
• DNS resolution centralized in the network account using Route 53 Resolver with forwarding rules.
• No direct internet access from workload accounts. All egress routes through the network account’s inspection layer.

PCI-DSS Requirement 1: Install and maintain network security controls. Your Transit Gateway route tables and firewall rules are the primary evidence for this requirement.

Logging, Monitoring, and Audit Trail

In regulated environments, logging is not just for troubleshooting — it is evidence. Every action must be recorded, stored immutably, and retained for the required period.

Checklist

• CloudTrail organization trail logging all management events and data events for critical services (S3, Lambda, KMS). Logs delivered to the log archive account.
• CloudTrail log file integrity validation enabled. This proves logs have not been tampered with — a specific requirement under multiple frameworks.
• AWS Config enabled in all accounts and regions with conformance packs for your target frameworks (CIS Benchmarks, PCI-DSS, SOC 2).
• VPC Flow Logs enabled on all VPCs, delivered to the centralized log archive.
• GuardDuty enabled organization-wide with a delegated administrator in the security account.
• Security Hub aggregating findings from GuardDuty, Config, IAM Access Analyzer, Inspector, and Macie.
• Log retention configured to meet framework requirements: PCI-DSS requires 12 months readily available and 3 years archived; SOC 2 typically requires 12 months; ISO 27001 requires retention aligned with your documented policy.
• S3 Object Lock on log archive buckets in compliance mode. This makes logs immutable for the lock period — even the root account cannot delete them.
• Alerting on critical security events: root account usage, IAM policy changes, SCP modifications, security group changes, encryption key deletion.

SOC 2 CC7.2: The entity monitors system components for anomalies. GuardDuty plus Security Hub with automated alerting directly satisfies this criterion.

Encryption

Encryption at rest and in transit is a baseline requirement across all regulated frameworks. The question is not whether to encrypt, but how to manage the keys.

Checklist

• AWS KMS with customer-managed keys (CMKs) for all sensitive data. Use separate keys per account and per workload classification.
• Key rotation enabled (annual automatic rotation for symmetric keys).
• Key policies that restrict key usage to specific accounts and roles. No wildcard principals.
• EBS encryption by default enabled in all accounts via account-level settings.
• RDS encryption enabled on all instances. This cannot be enabled retroactively — it must be set at creation.
• S3 default encryption with SSE-KMS using customer-managed keys for regulated data. SSE-S3 is acceptable for non-sensitive logs.
• TLS 1.2 minimum enforced on all load balancers, API Gateways, and CloudFront distributions. Remove support for deprecated ciphers.
• Certificate management through AWS Certificate Manager with automated renewal.

PCI-DSS Requirement 3.5: Protect stored cryptographic keys. KMS with strict key policies and no exportable key material is the cleanest implementation.

Incident Response Automation

Regulated frameworks require not just incident response plans, but evidence that they are exercised and effective.

Checklist

• Automated remediation for common security findings: auto-revoke public S3 bucket access, auto-quarantine compromised instances, auto-disable exposed access keys. Use Security Hub custom actions with Step Functions or Lambda.
• Runbooks for each incident type documented in Systems Manager Automation or a runbook platform. Include severity classification, communication templates, and escalation paths.
• Incident response roles defined and tested. Who is the incident commander? Who communicates with stakeholders? Who handles the forensics?
• Regular tabletop exercises — quarterly at minimum. Document the exercise, findings, and improvements.
• Forensic readiness: pre-configured forensic account with VPC peering to production for snapshot analysis. EBS snapshots of compromised instances should be automatic.
• Evidence preservation: automated collection of CloudTrail logs, memory dumps, and network captures when an incident is declared.

ISO 27001 A.16.1: Management responsibilities and procedures should be established to ensure a quick, effective, and orderly response. Automated runbooks with documented escalation paths directly satisfy this control.

Evidence Collection and Audit Readiness

The landing zone should produce audit evidence as a byproduct of normal operations, not as a manual exercise before the auditor arrives.

Checklist

• AWS Config conformance packs aligned to your target framework, producing continuous compliance status.
• AWS Audit Manager assessments running continuously for SOC 2, PCI-DSS, or custom frameworks.
• Automated evidence collection: Config snapshots, Security Hub findings, IAM credential reports, and CloudTrail digests — all delivered to a dedicated S3 bucket in the log archive account.
• Dashboard showing real-time compliance status across all accounts. Security Hub’s compliance standards view is a good starting point.
• Change management records: every infrastructure change tracked through IaC pull requests with approval workflows. This provides the change management evidence auditors require.
• Access review reports generated quarterly from IAM Access Analyzer and Identity Center.

SOC 2 CC8.1: The entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure. A GitOps workflow with PR approvals, automated testing, and deployment logs provides complete evidence for this criterion.

Implementation Priority

If you are building from scratch, implement in this order:

1. Account structure and SCPs (week 1)
2. Identity federation and access management (week 1-2)
3. Logging, monitoring, and alerting (week 2)
4. Network architecture (week 2-3)
5. Encryption baseline (week 3)
6. Incident response automation (week 3-4)
7. Evidence collection and Audit Manager (week 4)

A production-ready, compliant landing zone can be operational in four weeks with an experienced team. Retrofitting compliance onto an existing environment takes two to four times longer.

---

Remangu builds compliant AWS landing zones for fintech, iGaming, and enterprise clients through our professional services practice. If your organization needs a landing zone that passes audits from day one, let’s talk.