AWS Security and Compliance for Regulated Businesses

AWS Security and Compliance for Regulated Businesses

Security and compliance get spoken about as one thing. They are two. Security is keeping attackers out and your systems sound. Compliance is proving, to a regulator or an auditor, that you operate to a defined standard, repeatedly, with evidence. You can be secure and non-compliant: you do the right things but cannot prove it. You can be compliant and insecure: you have the paperwork and a gap nobody tested. In a regulated market you need both, and the compliance half is usually the harder one, because it never finishes.

This guide covers both halves. The first is the security engineering: identity, least privilege, network control, audit trails, the fundamentals that breaches exploit when they are done badly. The second, expanded because it is where most regulated businesses struggle, is compliance: the regulatory landscape you actually operate in, how the obligation is shared, and how to produce evidence continuously instead of scrambling once a year. We run AWS for businesses in financial services, insurance, healthcare and the public sector, so the bias throughout is towards what survives an audit, not just what looks secure on a diagram.

Part one: get the security fundamentals right

AWS security failures are rarely exotic. They are the boring basics done badly: over-permissioned access, no audit trail, a public bucket nobody meant to expose, a long-lived key in a config file. Close these and you have shut the most common doors.

The shared responsibility model

AWS secures the cloud. You secure what you put in it. AWS owns the infrastructure, the hardware, and the managed service internals. You own your data, your access controls, your network configuration, and your application security. The line moves by service (more is yours with EC2, less with a fully managed service), but the principle is fixed: a misconfiguration on your side is your incident, and AWS will not configure your access model for you. Knowing exactly where the line falls for each service you run is the starting point for everything else, including compliance, because regulators hold you to your side of that line.

Identity is where breaches start

Most cloud incidents come down to identity. Every standing IAM user with a password and long-lived access keys is a liability: shared, committed to repositories, outliving the person who created it, rarely rotated. The modern pattern is federation. Connect your identity provider (Okta, Entra ID, Google Workspace) to AWS through IAM Identity Center, so people log in with your central identity, access is granted through groups, and credentials are temporary by default. That gives you one place to grant and revoke, central multi-factor authentication, and no standing keys to leak. The setup mechanics are in configure Okta with AWS IAM Identity Center, and monitoring federated access matters as much as configuring it, since you need to see who is assuming which roles.

Use temporary credentials everywhere. The AssumeRole pattern issues short-lived credentials that expire automatically, which is how applications, pipelines, and humans should get access. There is almost no legitimate reason for a long-lived key in a modern environment, and removing them removes the single most common cause of credential compromise.

Least privilege, then prove it

Least privilege means every identity has exactly the permissions it needs and nothing more. Write IAM policies scoped to specific actions on specific resources, not wildcards. Start from the minimum and add when something legitimately needs it. Use role-based access control so permissions attach to roles that map to job functions rather than to individuals, which keeps access reviewable. Add permission boundaries as the guardrail: a boundary caps the maximum permissions an identity can hold even if a broader policy is attached, which lets you delegate role creation to teams without letting them escalate their own access. That last control is exactly what auditors look for in a multi-team environment.

Control the network

Identity controls who, the network controls where. Security groups and network ACLs are the first layer: default deny, open only what is needed, document why each rule exists. AWS Network Firewall adds stateful protection at the VPC level, with deployment models ranging from a central inspection VPC to per-account firewalls, and the rules can be automated rather than hand-maintained. AWS WAF sits in front of your CloudFront, load balancers, and API Gateway for application-layer protection. Together they give defence in depth, and the firewall rules best practices apply across both: least exposure, explicit rules, regular review.

Audit trail and encryption

When something goes wrong, or an auditor asks, you answer one question: who did what, when. CloudTrail records every API call (who, from where, against what, success or failure). Capture it across all regions, log to a dedicated locked-down bucket, and protect it from tampering. The detail is in CloudTrail compliance best practices and AWS audit log best practices. Encryption belongs alongside it: data encrypted at rest and in transit by default, keys managed through KMS, as covered in encrypt data at rest and in transit. For posture, AWS Security Hub aggregates findings and checks your environment against established benchmarks, and a real vulnerability management process turns drift and new weaknesses into routine remediation rather than a future incident.

That is the security baseline. None of it is exotic. All of it is the difference between secure and exposed, and all of it becomes evidence when you turn to compliance.

Part two: compliance for regulated markets

Here is where regulated businesses live or die. The controls above have to exist, and you have to prove they exist, to a defined external standard, on demand. That is a different discipline, and it is the one we are built around.

Compliance, security, and governance are three things

Keep them distinct. Security is the technical reality of keeping systems safe. Governance is your internal framework of policies, ownership, and accountability. Compliance is demonstrating to an external standard that you meet defined requirements. Good governance makes compliance cheaper, because the evidence becomes a by-product of how you already operate rather than something assembled in a panic before an assessment. Weak governance makes every audit a fire drill.

Compliance is a shared responsibility too

AWS holds an extensive set of its own attestations, and you can pull AWS audit reports from AWS Artifact, but those cover the infrastructure layer only. They do not make your workload compliant. AWS being PCI-compliant infrastructure does not mean your payment system is PCI-compliant. AWS holding ISO 27001 for its data centres does not mean your information security management system passes. The infrastructure provider carries part of the obligation. The rest is yours: how you configure, who you give access to, what you log, how long you retain it, and whether you can evidence all of it. Most compliance failures happen on the customer side of that line.

The regulatory landscape you are actually in

Which regimes apply depends on your sector and where you operate. These are the ones our customers deal with most.

Financial services and fintech. DORA, the EU's Digital Operational Resilience Act, is now in force for EU financial entities. It sets requirements for ICT risk management, incident reporting, operational resilience testing, and, critically, ICT third-party risk. That third pillar matters to anyone running on AWS through a managed provider, and we return to it below. In the UK, the FCA, PRA, and Bank of England operational resilience rules require firms to identify their important business services, set impact tolerances for disruption, and stay within them through severe but plausible scenarios. And if you touch card payments, PCI DSS applies regardless of jurisdiction, with specific demands on network segmentation, encryption, access control, and logging that map directly onto AWS configuration.

Cross-sector cybersecurity. NIS2 in the EU expands cybersecurity and incident-reporting obligations to a much wider set of essential and important entities, and the UK is moving in a parallel direction on cyber resilience. ISO 27001 is the international standard for an information security management system and is often the baseline a customer or partner contractually requires. SOC 2 serves a similar purpose for technology and SaaS businesses, evidencing controls around security, availability, and confidentiality.

Data protection. UK GDPR and the Data Protection Act 2018, and the EU GDPR, govern how personal data is handled, with real consequences for breaches and for failing to demonstrate accountability. Your AWS architecture has to reflect data residency, encryption, access control, and retention obligations directly.

Healthcare. UK health and care organisations work to the NHS Data Security and Protection Toolkit, and healthtech products are assessed against the Digital Technology Assessment Criteria (DTAC), which folds in clinical safety, data protection, security, and interoperability. Workloads touching US health data fall under HIPAA. In each case the AWS environment is part of the assessed scope.

The point is not to memorise the acronyms. It is that in a regulated market the architecture decision and the compliance decision are the same decision, made at the same time. You confirm your specific obligations with your compliance function, then build the environment so the controls and the evidence are native to it.

The third-party risk angle, and why your provider matters

This is the part regulated businesses underestimate. Under DORA, your critical ICT third-party providers are part of your regulatory scope. The FCA outsourcing and operational resilience rules say much the same in the UK. When you run on AWS through a managed provider, that provider is one of those third parties. Their controls, their incident response, their evidence, and their resilience become things you are accountable for managing.

That changes how you choose a provider. A managed cloud partner who does not understand the regime, cannot produce evidence on your timeline, and cannot demonstrate their own security posture becomes a gap in your compliance, not a help. A partner who operates to the standards you are held to, holds their own certifications, and produces audit-ready evidence as a matter of course reduces your burden instead of adding to it.

Operationalise compliance: continuous evidence, not an annual scramble

The teams that find compliance painful treat it as an event. The teams that find it manageable treat it as a property of how they operate, evidenced continuously.

The AWS tooling supports this directly. AWS Config records configuration state and evaluates it against rules continuously, and conformance packs bundle rules mapped to common frameworks so drift is caught the moment it happens. Security Hub runs your environment against compliance standards (CIS benchmarks, PCI DSS, AWS Foundational Security Best Practices, and others) and tracks your score over time. AWS Audit Manager collects evidence continuously, mapped to framework controls, so your compliance position is always current rather than reconstructed annually. We cover the approach in automate compliance with AWS Audit Manager. CloudTrail and your log retention strategy provide the audit trail underneath it all.

Datadog adds the continuous-posture layer across this. Cloud Security Management evaluates your cloud configuration against compliance frameworks continuously and flags misconfigurations against benchmarks like CIS, PCI DSS, and SOC 2 as they arise, while Cloud SIEM provides the security monitoring and detection, correlated with the rest of your observability so a compliance-relevant signal sits next to the infrastructure and application context that explains it. Compliance posture stops being a quarterly report and becomes a live dashboard.

The goal is simple to state and hard to reach without the right operating model: when an assessor asks for evidence, it is an export, not a project.

This pillar anchors deeper guides

Each of the regimes above deserves its own treatment, and this page is the hub they hang from. Expect deeper guides on DORA for financial services running on AWS, operational resilience under the FCA, PCI DSS on AWS, NIS2 and UK cyber resilience, ISO 27001 and SOC 2 evidence on AWS, and NHS DTAC for healthtech. Each will go deep on a single regime. This pillar is the map.

Where Critical Cloud comes in

Operating all of this continuously, watching it 24/7, and keeping the evidence audit-ready while you ship product is more than most teams can carry alongside building the business. It is what we do, and regulated markets are our specialism.

Critical Cloud runs AWS environments for financial services, insurance, healthcare, and public sector organisations. Security monitoring is built in through Datadog Cloud SIEM and Cloud Security Management, correlated with the rest of your observability, with continuous compliance posture against the frameworks you are assessed on. We are ISO 27001 certified and Cyber Essentials Plus accredited, and we operate to the standards our regulated customers are held to, which means as your ICT third party we reduce your compliance burden rather than adding a gap to it. As the world's first Powered by Datadog accredited partner, that visibility and evidence come as part of how we run your platform.

If compliance is pulling your team away from building, and you need a provider who understands the regime you operate in, see how Critical Support works.