ISO 27001 certification is no small undertaking. Organisations typically spend several months working through risk identification, control implementation, internal auditing and the external certification process before a certificate is issued.
For most, certification strengthens client confidence, supports commercial relationships and brings a level of structure to information security that wasn’t previously in place.
Where organisations tend to focus less is on what the certification actually covers and where the boundaries of that assurance sit.
What your certification audit reviews – and what it doesn’t
An ISO 27001 certification audit focuses on your ISMS (information security management system). It assesses whether risks have been identified and treated appropriately, whether controls have been selected and implemented against those risks, and whether your organisation has a functioning process for ongoing review.
What it doesn’t extend to is the technical state of the organisation’s Cloud infrastructure.
A certification audit isn’t a Cloud security review. It doesn’t validate whether AWS IAM (Amazon Web Services Identity and Access Management) policies reflect current business requirements, whether security groups have been configured in line with network access control procedures, or whether CloudTrail and monitoring services are generating alerts that anyone is actually acting on.
Keeping that level of alignment between the ISMS and the live AWS environment is the organisation’s own ongoing responsibility and one that sits between audit cycles, not just before them.
For organisations running workloads in AWS, this is where the real governance challenge lies. Cloud environments aren’t static: configurations drift, access permissions accumulate and the technical posture of an AWS account can shift considerably between certification cycles. Without a structured process to keep the ISMS aligned with the live environment, control gaps can develop that wouldn’t surface through the certification audit alone.
In other words, your certification might not reflect your actual security posture and the next penetration test, client due diligence request or security incident will expose that gap quickly.
How AWS environments drift over time
AWS is a widely adopted Cloud platform that gives organisations significant flexibility in how they build and manage their infrastructure. For organisations with ISO 27001 certification, that flexibility comes with a governance responsibility that needs to be managed as part of the programme.
What tends to happen over time is configuration drift. For example:
- Access permissions are set up for a specific purpose and never reviewed after that purpose has passed.
- Staff leave the business and their Cloud credentials stay active because deprovisioning AWS access was not part of the offboarding workflow.
- Monitoring tools are deployed without a defined process for acting on what they detect.
- Infrastructure configurations from an initial deployment are not revisited as business requirements change.
These are the practical consequences of working in a Cloud environment where change happens frequently and there’s rarely a formal trigger to review what’s already in place. Over time, the AWS environment can diverge considerably from what the organisation’s security policies describe and that divergence represents a genuine security risk.
Where ISO 27001 programmes add the most value
ISO 27001 is built around the PDCA (plan-do-check-act) cycle, which means the Standard is designed to be an ongoing operational discipline rather than a periodic compliance exercise.
- Risk assessments are expected to be reviewed as the threat landscape and business environment evolve.
- Controls are expected to be evaluated for operational effectiveness, not simply documented and signed off.
- Internal audits are expected to test whether the programme is functioning as intended across the organisation’s actual environment.
Organisations that embed this cycle into day-to-day operations tend to derive tangible security value from their ISO 27001 programme:
- AWS environments are reviewed periodically against the control objectives the organisation has committed to.
- Access rights are managed as a continuous process, with regular entitlement reviews ensuring permissions remain aligned to current business requirements.
- When changes occur in the environment, the risk management process is engaged to assess whether existing controls remain adequate and whether any residual risk requires further treatment.
Organisations that approach the continual improvement cycle as a tick-box exercise rather than an operational commitment tend to see the gap between their documented control framework and their live environment widen over time. The programme may remain technically compliant while becoming less and less reflective of the actual security position.
What good practice looks like in an AWS context
Several areas consistently require attention when aligning an ISO 27001 programme with an AWS environment.
Identity and access management is where misalignment most commonly occurs.
- Joiners, movers and leavers procedures should explicitly cover AWS access provisioning and deprovisioning.
Access entitlements should be subject to periodic access reviews, with permissions assessed against the principle of least privilege and revoked promptly where they are no longer required by the business. - Logging and monitoring controls need to be operationalised, not just deployed.
Having CloudTrail or similar logging enabled satisfies a documentation requirement but does not in itself constitute an effective detective control. There needs to be defined ownership for reviewing security event outputs, clear escalation procedures for events that require further investigation, and evidence that the monitoring process is being followed consistently. - Technical configuration reviews should be conducted alongside standard documentation reviews.
Assessing whether IAM policies, security group rules and logging configurations reflect the controls documented in the ISMS gives a far more accurate view than reviewing policies alone. - Change management procedures should be integrated with the risk assessment process.
When new AWS services are onboarded, third-party integrations are introduced or organisational changes affect how the environment is managed, a risk assessment should be conducted to determine whether existing controls remain sufficient or whether additional treatment is required.
Keeping your programme relevant over time
ISO 27001 provides a strong governance framework for managing information security risk in a Cloud environment. The risk treatment process, supported by the Annex A control set and a PDCA cycle, gives organisations a structured and repeatable approach to maintaining their security posture as the AWS environment evolves.
Organisations that sustain the value of their certification are the ones that keep the programme operationally connected to their live environment. Control effectiveness is reviewed regularly, access entitlements are maintained in line with current business requirements, and the risk assessment process is used to evaluate the impact of changes before they introduce new vulnerabilities into the environment.
A certificate reflects the state of the ISMS at the point of assessment. Maintaining its relevance requires treating ISO 27001 as a continual operational commitment rather than a certification milestone.
Your ISMS should accurately reflect the security controls governing your AWS environment at all times, not just at the point of audit.