Configuration Drift in Validated Cloud Environments: A GxP Problem, Not Just a Security One
Cloud teams treat drift as a security issue. In a GxP environment, an undocumented change to a validated system is a compliance event — and it needs to be treated like one.
Moving GxP workloads to AWS brings real benefits: elasticity, resilience and infrastructure defined as code. It also introduces a new kind of risk. In a cloud account, a single console click or an automated script can change the configuration of a validated system in seconds — and nobody may notice until the next periodic review.
Why drift matters to quality, not just security
GAMP 5 and EU GMP Annex 11 both expect computerised systems to be maintained in a validated state, with changes controlled, documented and assessed for impact. If encryption on a storage bucket holding batch records is disabled, if logging is turned off for a LIMS database, or if a security group is opened to the internet, that is not only a security concern. It may mean the system is no longer operating as validated.
The question an inspector asks is simple: how do you know your cloud environment today matches the configuration you validated?
Why generic tools don't fully answer it
Cloud security posture management tools are excellent at what they do: checking resources against security benchmarks such as CIS. But GxP compliance needs something different — checks against your approved, versioned baselines, mapped to Part 11, Annex 11 and your internal SOPs, with evidence formatted for a quality audience. Most regulated organisations need both views.
What good looks like
- Approved baselines under change control. Each resource type has a documented, versioned baseline with an approval history, just like any other controlled document.
- Event-driven detection. Every change recorded by AWS CloudTrail triggers a comparison against the baseline, so drift is found in seconds, not at quarter end.
- Deterministic checks. The compliance decision should be repeatable and explainable. AI can help draft new baselines, but it should not sit in the runtime decision loop.
- Evidence that never leaves your boundary. Results and reports should stay in your own account, so the monitoring tool does not become a new data-residency question.
A practical first step
Pick one GxP application in AWS and list the ten configuration settings that, if changed, would put its validated state at risk. Then ask how quickly you would know if any of them changed today. That gap is what continuous cloud compliance closes.
Driftly was built for exactly this: GxP-native drift detection that runs inside your own AWS account.