Security and Governance on AWS
Security and governance on AWS
AWS offers strong isolation and strong preventative controls, but only when the account structure and policy hierarchy are set up deliberately. We establish the organisation, the guardrails and the identity model first, then enable detection and data-protection services in a way that produces a prioritised queue with named owners rather than a wall of findings. Where an estate has grown account by account, the early work is usually consolidation and containment rather than new tooling.
Why AWS
When this is the right platform.
- AWS Organizations and AWS Control Tower separate workloads by account, so the blast radius of a compromised credential is bounded by an account boundary rather than by a tagging convention someone has to maintain.
- Service control policies apply above the account, so a permission the organisation has denied cannot be granted inside an account, including by that account's own administrator.
- IAM Identity Center federates to the identity provider you already run, including Microsoft Entra ID, and issues short-lived credentials per account and role instead of long-lived access keys sitting in developer machines.
- Amazon GuardDuty, Amazon Inspector and Amazon Macie are managed detections you enable rather than detections you build, which suits organisations without a dedicated detection engineering function.
- Amazon Security Lake normalises logs and findings into an open schema in storage you own, so the security data stays yours and the choice of analytics tool remains reversible later.
Where it is less suited
We would rather say this now than after a migration.
- Security services are enabled and priced per account and per region. Turning everything on everywhere across a large estate becomes expensive quickly, particularly GuardDuty on high-volume S3 data events and Macie scanning large object stores, so scope has to be a conscious decision reviewed against the value of the coverage.
- IAM policy evaluation combines identity policies, resource policies, permission boundaries, service control policies and session policies. Reaching genuine least privilege is real engineering effort with real review cycles, and in practice misconfiguration, not platform capability, is the usual cause of exposure.
- AWS Security Hub aggregates findings but does not decide what matters to your business. Without a triage model, agreed suppression rules and a named owner per account, teams end up with high volume and low prioritisation, which is worse than a smaller, well-owned set of controls.
- AWS Audit Manager and AWS Artifact provide evidence collection and AWS's own attestations for the infrastructure AWS operates. They do not make your workloads compliant, and the control narratives for everything you build on top remain your responsibility.
Business outcomes
What AWS delivers here.
- A blast radius you can draw on one page
- Production, non-production, security tooling and shared services sit in separate accounts with explicit trust between them. Platform and risk leads get a containment boundary they can explain to an assessor without a caveat.
- Credentials with a short life
- Engineers and pipelines assume roles for the task at hand instead of holding permanent access keys. The measure agreed at the start is usually the count of active long-lived IAM access keys remaining across the organisation.
- Findings in one prioritised queue
- Posture, vulnerability, threat and data-exposure findings converge into a single ranked view with an owner per account. The security lead stops chasing account owners for context and starts tracking closure rates instead.
- Sensitive objects located and protected
- The buckets holding regulated or client-confidential data are identified, encrypted with keys you control and blocked from public access at the organisation level. Data owners agree the coverage measure before scanning begins, so the cost of discovery is bounded.
- Evidence collected as you go
- Control evidence accumulates continuously instead of being reconstructed the month before a review. When a client asks for assurance, the response draws on current artefacts and a written exception register rather than on recollection.
- Guardrails that stop the change, not just log it
- Actions nobody should ever take, such as disabling logging or deploying outside agreed regions, are denied above the account. Engineering teams get an immediate, specific error rather than a compliance finding weeks later.
Common client problems
What we usually hear first.
We have around forty AWS accounts and no consistent view across any of them.
We bring the accounts under a single organisation with an account inventory, an owner per account and a landing zone that applies a baseline everywhere, enrolling what exists rather than rebuilding it. Findings and logs are then delegated to a dedicated security account so one view is possible at all.
There are long-lived access keys everywhere and I could not tell you which ones are still used.
We list every IAM user and access key with its last-used timestamp and the services it touched, which separates dormant credentials from live automation. Active use is migrated to roles or IAM Identity Center on a dated plan, then the keys are disabled before deletion so a rollback is possible.
GuardDuty is switched on but the findings just accumulate in a shared inbox.
We agree in advance which finding types are actioned, which are suppressed with a recorded reason and who owns each account, then route the remainder into a triage queue with severity thresholds. Automated response is added only for the finding types where the correct action is unambiguous.
Our security spend went up last quarter and nobody can explain which service caused it.
We attribute security service cost by account, region and feature, which usually surfaces a small number of causes such as S3 data event logging, broad Macie scanning or duplicated log destinations. Scope is then reset against the value of the coverage, with the decision written down and revisited monthly.
Our biggest client is asking for a SOC 2 report and we genuinely do not know where to start.
We map your current AWS configuration to the control themes an assessor will test, identify the gaps and build the evidence collection that keeps the answers current. We prepare and align the environment; the audit and any resulting report come from an independent assessor you engage separately.
How we deliver
Our AWS delivery approach.
- 01
Assessment and advisory
The AWS review works from the organisation downwards, because account structure and policy hierarchy determine what every control below them can achieve. Findings are backed by exportable configuration, not interviews alone.
- Map the AWS Organizations structure, listing every account, its owner, its purpose and the service control policies applied to its organisational unit.
- Enumerate IAM users, long-lived access keys and roles carrying wildcard permissions across all accounts, with last-used data so dormant credentials are separated from active automation.
- Confirm AWS CloudTrail organisation trail coverage, including management events, selected data events, log file validation, and whether the log destination can be altered from a workload account.
- Baseline AWS Config rule coverage and AWS Security Hub standard results per account and region, recording which controls are disabled and the reason given.
- Run Amazon Macie discovery against the buckets most likely to hold regulated or client-confidential data rather than the whole estate, so exposure is established without an open-ended scanning bill.
- Assess the estate against the Essential Eight maturity model and the control themes an ISO 27001 or SOC 2 assessor will test, documenting the AWS configuration evidence behind each rating.
- 02
Architecture and implementation
We build the organisation, identity and encryption layers before enabling detection, because detection on a weak foundation mostly generates work. Everything is expressed as code and applied to a test organisational unit first.
- Establish or remediate the landing zone with AWS Control Tower, separating security, log archive, network and workload accounts, and enrolling existing accounts where a rebuild is not warranted.
- Write service control policies that deny the actions no account should ever perform, including disabling CloudTrail, deleting log destinations, and creating resources outside the agreed region set.
- Configure IAM Identity Center with permission sets per job function, federated to your existing identity provider, then retire long-lived IAM users in a sequence that does not break running automation.
- Apply permission boundaries and least-privilege roles for workloads and pipelines, replacing wildcard actions with the specific API calls the workload makes, verified against IAM Access Analyzer findings.
- Encrypt data at rest with customer managed AWS KMS keys where key control matters, with key policies, rotation, and separation between the account that owns the key and the account that uses it.
- Move application credentials into AWS Secrets Manager with rotation, strip them from environment variables and repositories, and place public applications behind AWS WAF with AWS Shield protecting the internet-facing edge.
- 03
Governance, detection and assurance
Detection services are enabled organisation-wide from a delegated security account, then tuned against your architecture. Evidence collection is set up at the same time so assurance is a by-product of running the platform.
- Enable Amazon GuardDuty across all accounts and regions with delegated administration in the security account, and agree up front which finding types are actioned, which are suppressed and who owns each account.
- Enable Amazon Inspector for continuous vulnerability assessment of compute instances, container images and serverless functions, routing findings to the team that owns the build rather than to a central security inbox.
- Aggregate findings in AWS Security Hub, using its cloud security posture management standards as the baseline and consolidating GuardDuty, Inspector, Macie and AWS Config results into one prioritised queue.
- Centralise logs and findings into Amazon Security Lake in a normalised schema, with retention tiers set so investigation data is available for the period you agreed rather than the period a default chose.
- Use Amazon Detective for investigations that need behaviour across time and accounts, and record the investigation path so the next analyst does not repeat the work.
- Collect control evidence continuously with AWS Audit Manager and draw on AWS Artifact for AWS's own attestation reports covering the infrastructure AWS operates. We help you prepare for and align to a framework; the audit opinion is issued by an independent assessor, not by us.
- 04
Adoption and enablement
Engineering teams have to be able to keep shipping while the controls tighten. Every restrictive change is tested against real activity before it is enforced anywhere that matters.
- Migrate teams from IAM users to IAM Identity Center one workload at a time, leaving the old path in place until the new one is proven, then removing it on a dated plan.
- Give each account owner read access to their own AWS Security Hub findings plus a short guide to which control failures block a release and which do not.
- Apply new service control policies to a test organisational unit first and check the deny paths against real workload activity in AWS CloudTrail before widening the scope.
- Train engineers to obtain short-lived credentials through the command line and the console portal rather than storing keys, walking the real workflow on their own repositories.
- Agree a monthly review of Amazon Macie findings with data owners, so classification and retention decisions are made by the people who understand the content.
- 05
Managed security operations
AWS ships new controls and new finding types constantly, and account estates grow between reviews. We keep the baseline applied, the findings triaged and the evidence current, during agreed support hours and through an escalation path you have approved.
- Report monthly on AWS Security Hub control pass rate by account, Amazon GuardDuty finding trend by severity, and findings still open past their agreed age.
- Triage GuardDuty and Security Hub findings against an agreed severity model, escalating through a named playbook with a documented fallback contact.
- Review IAM entitlement drift each quarter, removing unused roles, keys and permissions identified from last-used data and IAM Access Analyzer results.
- Keep AWS Config rules, service control policies and remediation automation in a repository, tested in a sandbox organisational unit before promotion to the wider organisation.
- Track AWS Config, GuardDuty, Macie and Security Lake spend monthly and adjust scope where cost is growing faster than the value of the coverage it buys.
- Maintain the AWS Audit Manager assessment and its evidence so assurance responses stay current between review cycles instead of being rebuilt each time one is requested.
Technology reference
The AWS services we build with.
A reference architecture view of the platform services used in this domain, and what each one does in the design.
Identity and account governance
AWS Identity and Access ManagementRoles, policies and permission boundaries for workloads and pipelines. We use it to replace wildcard permissions with the specific API calls a workload makes, and use IAM Access Analyzer to prove the reduction.
IAM Identity CenterFederated human access with permission sets per job function, issuing short-lived credentials per account and role so long-lived access keys can be retired.
AWS OrganizationsThe account hierarchy and the service control policies that deny disallowed actions above the account, including actions an account administrator would otherwise be able to perform.
AWS Control TowerLanding zone setup and ongoing conformance, giving a consistent baseline for new accounts and a controlled way to enrol accounts that already exist.
Threat detection and investigation
Amazon GuardDutyManaged threat detection over CloudTrail, DNS, VPC flow and selected data events, delegated to the security account with finding types actioned or suppressed by prior agreement.
Amazon InspectorContinuous vulnerability assessment of compute instances, container images and serverless functions, with findings routed to the team that owns the build.
AWS Security HubThe single prioritised queue. We use its cloud security posture management standards as the control baseline and consolidate GuardDuty, Inspector, Macie and Config findings into one ranked backlog.
Amazon DetectiveInvestigation of behaviour across time and accounts when a finding needs context, with the investigation path recorded so the analysis is reusable.
Data protection and secrets
Amazon MacieScoped discovery and classification of sensitive data in object storage, targeted at the buckets most likely to hold regulated material so cost stays predictable.
AWS KMSCustomer managed keys, key policies, rotation and cross-account separation, so encryption decisions and key custody are explicit rather than implied by a default.
AWS Secrets ManagerCustody and rotation of database credentials, API keys and application secrets, allowing credentials to be removed from repositories, pipeline variables and environment configuration.
Configuration, logging and evidence
AWS ConfigResource configuration history and conformance rules, used both for drift detection and as the record that shows when a resource changed and to what.
AWS CloudTrailThe organisation-wide audit trail. We verify coverage, enable log file validation and place the destination in a log archive account that workload accounts cannot alter.
Amazon Security LakeNormalised, centralised security data in storage you own, with retention tiers matched to investigation needs and the analytics choice left open.
AWS Audit ManagerContinuous evidence collection against control frameworks, so assurance requests draw on current artefacts rather than a reconstruction exercise.
AWS ArtifactAccess to AWS's own compliance reports and agreements covering the infrastructure AWS operates, used as supporting evidence for the shared responsibility boundary.
Edge and application protection
AWS WAFManaged and custom rules in front of public applications and APIs, tuned against real traffic and released in count mode before blocking.
AWS ShieldProtection and visibility for the internet-facing edge against volumetric and application-layer denial-of-service activity.
Product names and icons are trademarks of Microsoft and Amazon Web Services, reproduced unmodified from their official architecture icon libraries to identify the technologies used in these architectures. Their presence does not indicate partnership, certification or endorsement by either vendor.
Related industries
Where this work has the most leverage.
Professional Services
Governed enterprise search, document intelligence and secure copilots that respect matter confidentiality and conflict boundaries.
Healthcare and Community Services
Administrative automation, policy search, workforce analytics and privacy uplift for healthcare and community providers, with clinical decisions left entirely to clinicians.
Logistics and Warehousing
Shipment and document automation, proof-of-delivery processing and exception dashboards that let a small team run a large network.
Free discovery workshop
Start with a security and governance discovery workshop.
Bring one challenge. We will assess whether AWS is the right platform for it before recommending anything.