By Martin Keller · Reepa Solutions
The majority of serious cloud incidents at mid-market companies do not stem from a technical weakness in AWS itself, but from avoidable configuration errors on the customer side — a publicly accessible S3 bucket, missing multi-factor authentication on the root account, forgotten test databases exposed to the internet, unchecked IAM permissions with full access. For management, CFOs and IT leadership this creates a double burden: on one hand, GDPR fines loom in the event of a data breach; on the other, the NIS2 directive has required many mid-market companies since 2024 to demonstrate concrete technical measures for their cloud environments. This checklist summarises the twelve most important controls that deliver the greatest security leverage for AWS environments in companies with 50 to 2,000 employees — with cost ranges, compliance mapping and a vendor overview. For a more detailed look at how these fit into the overall strategy, see our Cybersecurity Guide for the Mid-Market.
Why AWS Security is a Board-Level Topic in 2026
Gartner's widely cited analysis of the shared responsibility model concluded that by 2025, an estimated 99 percent of all cloud security incidents would be caused by customer errors — not by vulnerabilities in the AWS platform itself. This finding has a direct consequence for every mid-market company: AWS provides the security building blocks, but the correct configuration, data classification and ongoing monitoring are entirely your responsibility. Whoever delegates this responsibility without actively managing it builds up systematic risk.
For supervisory boards and management, three regulatory amplifiers add further urgency. First, the GDPR, which under Article 32 requires that technical and organisational measures meet the state of the art — and in the event of a data breach in a publicly accessible cloud storage, this requirement is difficult to defend. Fines in the six- to seven-figure range have been documented in practice, including by the Berlin data protection authority. Second, NIS2, which has been in force since October 2024 and for the first time subjects a large portion of the German mid-market to structured security reporting obligations. Management is personally liable if it fails in its supervisory duty. Third, the expectations of major customers and insurers are rising — supplier audits on cloud security are now standard across many sectors, from manufacturing and logistics to healthcare.
On the operational side, the ransomware threat adds further pressure, as attackers increasingly target cloud identities and cloud backups. A single compromised IAM key can be enough to drain production AWS accounts, delete backups and demand a ransom. Insurance providers have responded accordingly: cyber policies today typically require evidence of basic cloud controls — MFA, logging, backup restore tests — as a prerequisite for coverage. Those who cannot demonstrate these controls either cannot obtain insurance at all or pay significantly higher premiums.
The 12 Essential Controls — Overview
The following list summarises the twelve controls that deliver the highest security leverage in most mid-market AWS environments. Each entry describes what the control achieves and why it matters — the specific implementation is worked through in a follow-up step with your team or an advisor.
- IAM Least Privilege and MFA for RootThe AWS root account must be protected with multi-factor authentication, as must all administrative IAM accounts. Day-to-day operations never run via root. Permissions follow the principle of least privilege, ideally role-based via AWS IAM Identity Center.
- CloudTrail Active in All RegionsCloudTrail records every API action in AWS — who changed what, when. Without these records, forensic analysis after an incident is virtually impossible, and NIS2 evidence of activity logging is absent.
- GuardDuty and Security Hub EnabledGuardDuty detects anomalous behaviour in IAM, EC2, S3 and containers. Security Hub aggregates the findings and maps them to compliance frameworks such as CIS and NIST. Both can be activated in under an hour and provide measurable visibility.
- S3 Public Access Block at Account LevelThe most common cause of cloud data incidents is an accidentally public S3 bucket. The Public Access Block at account level prevents this systematically — even if an individual configuration is wrong, access remains blocked.
- KMS for Sensitive DataPersonal data, trade secrets and backup data must be encrypted with AWS Key Management Service. Key rotation and access logging happen automatically. Without KMS, demonstrating "encryption in line with the state of the art" in audits is difficult.
- VPC Flow Logs in Centralised StorageFlow logs record network traffic within your AWS networks — who communicated with whom on which port. They are the foundation for anomaly detection, forensic analysis and audit evidence.
- Backup Strategy with Restore TestsAWS Backup orchestrates consistent backups across multiple services. What matters is not the existence of backups, but the regular restore test — at least quarterly. Backups that fail when needed are not backups.
- AWS Config with Conformance PacksAWS Config records every configuration change and continuously checks it against security rules. Conformance Packs deliver pre-built rule sets for CIS, PCI-DSS, BSI IT-Grundschutz and other frameworks. This makes compliance continuously measurable rather than point-in-time.
- EBS and EFS Encryption EnforcedDisks and file systems do not encrypt themselves. The account-wide default of "encryption mandatory" prevents development teams from accidentally creating unencrypted storage. The effort: minutes. The benefit in a GDPR audit: substantial.
- Secrets Manager Instead of Embedded CredentialsDatabase passwords, API keys and tokens do not belong in source code, configuration files or environment variables. AWS Secrets Manager stores them centrally, rotates them automatically and logs every access. One of the most effective single measures against credential leaks.
- IMDSv2 Mandatory on All EC2 InstancesThe Instance Metadata Service provides temporary cloud credentials on every EC2 instance. In the older version 1 it can be retrieved passively via HTTP GET; in version 2 it is token-based only. Switching to IMDSv2 prevents one of the most common paths by which cloud credentials leak from web applications.
- Container and Kubernetes HardeningAnyone running Amazon EKS or ECS needs additional controls: private API endpoints, Pod Security Standards, image scanning with Amazon Inspector, and a clear separation between cluster-admin and application roles. Containers without this hardening are a common initial entry point for attackers.
Free AWS Security Initial Assessment
Would you like to know how your AWS environment measures up against these twelve controls today? We offer a free initial assessment: a 30 to 45 minute conversation, a focused inventory review, a clear traffic-light status per control and a written summary afterwards.
Request a Free AWS Security Initial Assessment
A compact starting point at no cost and with no obligation. You receive a well-grounded outside view of your AWS accounts and concrete recommendations on which of the twelve controls should take priority.
Request a free AWS security assessmentCompliance Mapping: GDPR, NIS2, ISO 27001
The twelve controls have not only a technical but also a regulatory benefit. The mapping below shows which control addresses which requirement in GDPR Article 32, NIS2 Article 21 and ISO 27001 Annex A. This table is deliberately high-level — in practice the requirements are more detailed, but it provides the most important overview for board-level communication and for audit preparation.
| Control | GDPR Art. 32 | NIS2 Art. 21 | ISO 27001 Annex A |
|---|---|---|---|
| IAM Least Privilege and Root MFA | Access and authorisation concept | Access control | A.5.15, A.5.16, A.8.2 |
| CloudTrail in All Regions | Traceability | Activity logging | A.8.15, A.8.16 |
| GuardDuty and Security Hub | Incident detection | Detection, incident handling | A.8.16, A.5.24 |
| S3 Public Access Block | Confidentiality, integrity | Protection against unauthorised access | A.8.3, A.5.10 |
| KMS Encryption of Sensitive Data | Encryption | Cryptographic measures | A.8.24, A.5.33 |
| VPC Flow Logs | Detectability of unauthorised access | Network security, logging | A.8.15, A.8.20 |
| Backup Strategy with Restore Tests | Recoverability | Business continuity | A.8.13, A.5.30 |
| AWS Config with Conformance Packs | Regular review of TOMs | Risk management | A.5.36, A.5.7 |
| EBS and EFS Encryption | Encryption | Cryptographic measures | A.8.24 |
| Secrets Manager | Access security | Authentication | A.8.24, A.5.17 |
| IMDSv2 Mandatory | State of the art | Hardening | A.8.9 |
| Container and EKS Hardening | State of the art | Secure configuration | A.8.9, A.8.27 |
This mapping does not replace a full compliance analysis — it is a starting point to make visible at management level that each of the twelve controls addresses multiple regulatory requirements simultaneously. Whoever implements all twelve consistently already closes a substantial portion of the most common audit findings. For a detailed look at the ISO 27001 mechanics, see our cluster on ISO 27001 certification costs.
What Does Implementation Cost?
The cost of implementing the twelve controls depends heavily on the starting position and the number of accounts. The table below shows typical ranges for mid-market companies with a manageable AWS landscape (one to five accounts, fewer than 100 production workloads). It is intended as a guide — precise proposals require a short scoping workshop.
| Measure Cluster | Effort (person-days) | External Consultant (€) | In-House Reality |
|---|---|---|---|
| Activation block (CloudTrail, GuardDuty, Security Hub, S3 Block, IMDSv2) | 3–6 | from €3,500 | One experienced person, one to two days |
| IAM concept and Identity Center | 6–12 | from €6,500 | Multiple workshops with stakeholders |
| KMS and data classification concept | 5–10 | from €5,500 | Close coordination with data protection |
| Backup and restore concept including tests | 4–8 | from €4,500 | Quarterly restore test as an ongoing task |
| VPC Flow Logs and centralised logging | 3–6 | from €3,500 | Calculate ongoing storage costs |
| AWS Config + Conformance Packs | 2–5 | from €2,500 | Quarterly maintenance |
| Container and EKS hardening (if applicable) | 5–10 | from €5,500 | Together with the platform team |
On top of this come ongoing AWS service costs: CloudTrail storage, GuardDuty processing, Security Hub compliance checks, Config Recorder. For a mid-market environment with a few accounts, experience shows these service costs typically run between €150 and €800 per month — a moderate item given the damage potential of an incident. Those working in-house should plan not just for the effort itself, but also for the opportunity cost: every day a senior cloud architect spends on security hardening is a day missing from the product backlog.
Vendor Landscape
The twelve controls can be implemented either entirely with AWS-native tools or supplemented with additional platforms that provide extra convenience and cross-platform visibility. Which path makes sense depends on the size, architecture and maturity of the team.
AWS-native toolchain. For mid-market companies with a pure AWS landscape, it is sufficient in most cases.
- AWS Security Hub — centralised aggregation and compliance reporting
- Amazon GuardDuty — anomaly detection across IAM, EC2, S3, EKS
- Amazon Inspector — vulnerability scanning for EC2 and container images
- Amazon Macie — automatic detection of sensitive data in S3
- Amazon Detective — forensic analysis of incidents
Third-party cloud security platforms. Worth considering for multi-cloud, many accounts and a higher maturity level.
- Wiz — agentless cloud security platform with strong visualisation
- Lacework — behaviour-based anomaly detection across multiple cloud providers
- Palo Alto Prisma Cloud — broad platform for CSPM, CWPP and container security
- Orca Security — agentless security visibility without network intervention
- Datadog Cloud Security — worthwhile when there is an existing Datadog observability platform
The choice is not a matter of "better or worse" but "does it fit your architecture or not". We recommend that mid-market companies start with the AWS-native toolchain — it is quick to activate and costs little — and only then evaluate supplementary platforms when the operational visibility from the AWS stack alone is no longer sufficient. From our own experience with recent engagements: in mid-market environments with fewer than 200 employees, the AWS-native stack has proven adequate in 80 percent of cases, provided the twelve controls are implemented cleanly.
Frequently Asked Questions
How quickly can a mid-market company implement the 12 essential AWS controls?
In typical mid-market environments with one to five AWS accounts, the twelve controls can be implemented within two to four months with a dedicated team of two to three people. Six of the twelve controls can be completed within the first two weeks — they are essentially activations of native AWS services. The other six require architectural decisions, data classification and process changes and take correspondingly longer. If the project has to run in parallel with day-to-day operations, organisations should plan for six to nine months.
Is AWS Security Hub alone sufficient to secure the cloud?
No. AWS Security Hub aggregates findings from GuardDuty, Inspector, Macie and external sources and maps them to compliance frameworks such as CIS or NIST. It is an important visibility tool, but not a substitute for hardening. A Security Hub with 1,200 open findings is just as insecure as an environment without Security Hub — the only difference is that you know about it. The twelve essential controls close the gaps that Security Hub surfaces.
What happens in a GDPR audit if these controls are missing?
Data protection supervisory authorities assess in practice under Article 32 GDPR whether the technical and organisational measures meet the state of the art. Missing AWS baseline controls such as CloudTrail, encryption of sensitive data or an S3 Public Access Block are hard to defend in an audit, because they are regarded as standard recommendations and can be activated with minimal effort. Fines in the six- to seven-figure range have been documented for mid-market companies in cases involving personal data in a publicly accessible S3 bucket.
Do we also need a third-party cloud security platform such as Wiz or Prisma Cloud?
For organisations with only one AWS account and fewer than 100 employees, the AWS-native toolchain (Security Hub, GuardDuty, Config, Inspector, Macie) is usually sufficient. Once you operate more than three AWS accounts, multi-cloud setups or container workloads in production, a third-party platform becomes worthwhile — it delivers cross-account visibility, multi-cloud coverage and better prioritisation. The typical break-even point is around 50 AWS accounts or 500 workloads.
Which of the twelve controls should be implemented first?
The first three are always the same: MFA for the root account and all IAM accounts with administrative rights, enabling CloudTrail in all regions, and the S3 Public Access Block at account level. These three measures address the most common causes of AWS incidents in mid-market companies and can be implemented within hours. GuardDuty, encryption and the rest of the list follow in order of their respective risk rating.
How often should the AWS security checklist be reviewed?
A quarterly review is the minimum standard — typically using AWS Config Conformance Packs that continuously check against the twelve controls. Additional reviews are warranted after major architectural changes, new accounts or acquisitions. We recommend an external security assessment once a year, because internal teams tend to develop blind spots towards their own architectural decisions after a few months. Continuous External Attack Surface Monitoring — such as with Reepa Security — supplements internal audits with an outside perspective.
Can the AWS security controls be built in-house or is an external consultant needed?
Both are possible, depending on team capacity. If you have at least one person with an AWS Solutions Architect Professional or AWS Security Specialty certification and that person can dedicate 30 to 50 percent of their time to the topic, in-house implementation is feasible. Without these prerequisites, an external consultant for the first three to six months is almost always faster and more cost-effective — they bring templates, Conformance Pack configurations and experience that an internal team would first have to build up.
Ready to take your AWS environment to the next level?
Let's talk for 30 minutes, no commitment required. We walk through the twelve controls with you, identify the biggest gaps in your current AWS landscape and deliver an honest assessment — in-house or with external support — along with a realistic roadmap.
Schedule a 30-minute conversation
IT security and cloud architect with over ten years of experience. Develops Reepa Security with his team — an offensive audit platform for the mid-market. Writes regularly about cloud security, NIS2, GDPR compliance and AWS hardening.
Reviewed on: 22 May 2026 · More about Martin