Securing Your AWS Estate: SCPs, GuardDuty, and NCSC Alignment for UK Enterprises

Here is a question worth asking honestly: if someone gained access to an IAM user with broad permissions in your AWS account tonight, how long before you would know? For most UK enterprises we speak to, the answer is uncomfortable. Logging is inconsistent, alerts are noisy or absent, and preventive guardrails were never put in place because the team was always focused on shipping features.

AWS provides a genuinely strong set of security primitives. The problem is not the tooling — it is the gap between what AWS makes available and what organisations actually configure. This post covers the three controls that make the biggest difference: Service Control Policies (SCPs), Amazon GuardDuty, and aligning your posture with NCSC guidance. None of this requires a dedicated security team to implement, but it does require deliberate effort.

Why Perimeter Security Is Not Enough in AWS

Traditional IT security assumed a hard perimeter — a firewall between the trusted internal network and the hostile internet. In AWS, that model breaks down almost immediately. Compute is ephemeral, networking is software-defined, and the blast radius of a misconfigured IAM policy or a leaked access key extends well beyond a single machine.

The NCSC's cloud security guidance makes this explicit. Their 14 Cloud Security Principles emphasise identity and access management, data-in-transit and at-rest protections, and visibility into supply chains — not just network segmentation. If your AWS security strategy still centres on security groups and VPC ACLs, you are leaving the most significant attack vectors unaddressed.

Service Control Policies: The Preventive Layer You Probably Don't Have

SCPs are AWS Organisations policies that set the maximum permissions available to any account or organisational unit (OU). They do not grant permissions — they establish an outer boundary that no IAM policy in the account can exceed, even for the root user.

In practice, most organisations treat SCPs as an afterthought, applying only the FullAWSAccess default policy that AWS ships with. This is the equivalent of leaving the door open. SCPs done properly look like this:

• Deny leaving your approved AWS regions. For UK data residency requirements — increasingly important under UK GDPR and sector-specific regulation — an SCP that explicitly denies API calls outside eu-west-2 (London) and eu-west-1 (Ireland) is far more reliable than trusting developers to check a box in the console.
• Prevent disabling CloudTrail. A Deny on cloudtrail:StopLogging and cloudtrail:DeleteTrail means that even a compromised administrator account cannot cover its tracks.
• Block public S3 ACLs at the organisation level. S3 data exposure remains one of the most common causes of cloud breaches. An SCP enforcing s3:PutBucketPublicAccessBlock at account creation, combined with AWS Config rules, eliminates an entire class of misconfiguration.
• Restrict IAM actions in production. Preventing iam:CreateUser and iam:CreateAccessKey in production OUs means new human access must go through your central identity provider, not be created ad hoc under pressure.

The key design principle: SCPs are your last line of defence against misconfiguration and insider threat. They should be defined in code (Terraform or CloudFormation), reviewed alongside your application infrastructure, and tested with the AWS IAM Policy Simulator before deployment.

GuardDuty: Threat Detection Without the Noise

Amazon GuardDuty is a managed threat detection service that analyses CloudTrail logs, VPC Flow Logs, and DNS logs using machine learning and threat intelligence feeds. Enabling it is a single API call. Yet fewer than half of the AWS environments we encounter have it switched on across all accounts.

GuardDuty's value is in detecting what preventive controls miss: an IAM credential being used from an unusual geography, an EC2 instance communicating with a known command-and-control server, or a user suddenly making API calls at 3am that they have never made before. These are the signals that traditional SIEM tools struggle to surface without extensive custom rule-writing.

A few implementation points that matter in practice:

• Enable GuardDuty in every region, not just your primary one. Attackers frequently target inactive regions precisely because monitoring is sparse there. AWS GuardDuty's multi-region delegated administrator feature, managed through AWS Organisations, makes this straightforward.
• Integrate with AWS Security Hub. Security Hub aggregates GuardDuty findings alongside AWS Config compliance results, Inspector vulnerability findings, and third-party tools into a single normalised view. It also provides automated scoring against the AWS Foundational Security Best Practices standard, which maps closely to NCSC guidance.
• Automate responses for high-confidence findings. A GuardDuty finding of UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration — indicating that EC2 instance credentials are being used outside of AWS — warrants an immediate automated response: isolate the instance, revoke the session token, and page the on-call engineer. EventBridge and Lambda make this achievable with minimal custom code.

IAM: The Discipline That Matters Most

If SCPs are the outer wall and GuardDuty is the alarm system, IAM is the lock on every door. Most of the breaches and data exposures we see in AWS environments trace back to IAM: over-permissive roles, long-lived access keys, and no separation between human and machine identities.

The NCSC's guidance on identity is unambiguous — least-privilege access, strong authentication, and regular review. In AWS, that translates to:

• No long-lived access keys for human users. All human access should go through IAM Identity Centre (formerly AWS SSO), federated to your corporate identity provider — Azure AD, Okta, or Google Workspace. This gives you centralised access control, MFA enforcement, and a full audit trail, without distributing static credentials.
• Permission boundaries on developer roles. Developers in a self-service environment need the ability to create IAM roles for their applications. Permission boundaries ensure they can only create roles that are as permissive as their own — preventing privilege escalation by design.
• Regular access reviews with IAM Access Analyser. Access Analyser identifies resources that are shared outside your AWS Organisation — S3 buckets, KMS keys, Lambda functions, SQS queues — and generates findings for review. Running this on a weekly schedule and routing findings to your security team closes a significant visibility gap.

UK Data Residency: Getting It Actually Right

UK GDPR and the Data Protection Act 2018 place obligations on where personal data is processed and stored. For regulated industries — financial services, healthcare, central government — the requirements are more specific still. The instinct is often to rely on the service provider's assurances: AWS is certified, therefore we are compliant. That is not sufficient.

Data residency in AWS requires deliberate control at multiple layers. The region SCP described above is necessary but not sufficient on its own. You also need to consider:

• Global services that may transfer data. IAM, Route 53, CloudFront, and AWS Support all operate globally. Review whether any of these introduce residency concerns for your specific workloads.
• Third-party integrations. SaaS tools connected to your AWS environment — monitoring agents, CI/CD platforms, secret managers — may transmit data outside your approved regions. Audit these as part of your data mapping exercise.
• Encryption and key custody. AWS KMS with Customer Managed Keys (CMKs) gives you control over encryption key lifecycle and the ability to revoke access at the key level. For the most sensitive workloads, AWS CloudHSM provides dedicated hardware under your exclusive control.

Aligning with NCSC's Cloud Security Principles

The NCSC's 14 Cloud Security Principles provide a practical framework that maps well to AWS controls. Principles 2 (Asset Protection and Resilience), 9 (Secure User Management), 10 (Identity and Authentication), and 11 (External Interface Protection) are the ones most commonly under-implemented in the AWS environments we review.

A useful approach is to treat the NCSC principles as a structured audit checklist. Map each principle to the AWS services and configurations that address it, identify gaps, and prioritise remediation by risk. AWS Security Hub's compliance standards — particularly the NIST CSF and CIS AWS Foundations Benchmark — provide a machine-readable version of this mapping and track your posture continuously.

Cyber Essentials Plus, the UK government-backed certification, is increasingly a prerequisite for public sector contracts and a marker of baseline hygiene for enterprise procurement. AWS has published guidance on how its shared responsibility model interacts with Cyber Essentials Plus, but achieving certification still requires demonstrating controls on the customer side — particularly around patch management, access control, and malware protection on any EC2 instances you operate.

Where Most Organisations Actually Are

The honest assessment: most UK enterprises operating on AWS have enabled some security controls, have good intentions, but have not connected the dots into a coherent, auditable posture. SCPs were discussed in a meeting two years ago and never deployed. GuardDuty is on in one account but not the others. IAM is a tangle of legacy roles created under deadline pressure. There is no automated response to any finding.

This is not a failure of intent. It is a consequence of security being treated as something to layer on after the fact rather than designed in from the beginning. The controls described here are not exotic — they are table stakes for any organisation that takes its obligations seriously.

How Kineticor Can Help

Kineticor works with UK enterprises to design and implement AWS security postures that are practical, auditable, and built to last. We bring together Landing Zone architecture, IAM design, SCP frameworks, and Security Hub integration into a coherent programme — not a checklist of bolt-ons. If you are concerned about your current AWS security posture, or preparing for a regulatory review or Cyber Essentials Plus certification, get in touch for a no-obligation conversation.