GxP / Guide 4
Qualifying Azure and AWS
Assessing the cloud provider as a supplier, designing a GxP landing zone, qualifying it with infrastructure as code, and keeping it qualified as the platform changes under you.
Validated applications need qualified infrastructure underneath. On premises that meant documenting servers, storage and networks. In the cloud, the provider runs the hardware and changes its services every week, so qualification shifts to three things: assessing the provider as a supplier, qualifying your landing zone, and controlling it continuously rather than once.
Assess the provider as a supplier
You can't audit an Azure or AWS data center, and you don't need to. A documented supplier assessment based on their published evidence is the accepted approach:
- Audit reports and certificates: ISO 9001, ISO/IEC 27001, 27017 and 27018, SOC 1 and SOC 2 Type 2. Download them from the Microsoft Service Trust Portal and AWS Artifact, read the scope (which services and regions are covered), and note the exceptions and complementary user entity controls in the SOC 2 report: those are controls you must operate.
- GxP guidance from the provider: Microsoft's Azure GxP guidelines (written with an independent GxP consultancy) and its GxP compliance offering page; AWS's GxP Systems on AWS whitepaper and life sciences compliance pages. Both describe the shared responsibility model and map their controls to GAMP.
- Agreements: the online service terms and data protection addendum act as the quality agreement for a hyperscaler. Record how they cover change notification, incident notification, data location, audit rights and exit. The 2025 Annex 11 draft expects these points to be explicit.
- Re-assessment: review the new SOC 2 report each year, and whenever you adopt a new service for GxP use. Keep the list of services approved for GxP.
Design a GxP landing zone
Keep GxP workloads separate so their controls, logs and change process can be strict without slowing down everything else:
| Azure | AWS | |
|---|---|---|
| Boundary | Management group mg-gxp with its own subscriptions: sub-notes-gxp-val, sub-notes-gxp-prod | OU Workloads/GxP with its own accounts: notes-gxp and a validation account |
| Guardrails | Azure Policy initiatives assigned at mg-gxp: allowed regions, allowed services, required tags, diagnostic settings, no public endpoints | SCPs on the OU: allowed regions and services, deny disabling CloudTrail and Config, deny deleting recovery points |
| Audit trail | Activity log and resource logs to a dedicated Log Analytics workspace (log-notes-gxp), copied to immutable storage | Organization trail to a separate log archive account, with Object Lock and log file validation |
| Identity | Entra ID groups per system and role; PIM for admin roles | IAM Identity Center permission sets; no IAM users |
| Backup | Recovery Services vault with immutability locked | AWS Backup vault with Vault Lock, copies to a separate backup account |
| Scope marker | Tag GxP = Yes and GxPSystemId on subscriptions or resource groups | Tag GxP = Yes and GxPSystemId on accounts and resources |
Only list services in the GxP guardrails that you've assessed. A new service arrives in the GxP environment through change control, with a short assessment of how it's configured, logged and backed up.
Qualify with infrastructure as code
Treat the landing zone as a GAMP category 1 configuration and qualify it like one:
- Specify the landing zone in code (Bicep, Terraform or CloudFormation) plus a short design document. The repository at a tagged version is the configuration specification.
- Review pull requests: at least one reviewer who isn't the author. The pull request is your design review record.
- Install through a pipeline only. The pipeline run, with its approvals, logs and the commit it deployed, is your IQ evidence.
- Verify automatically: policy compliance, the conformance pack and the evidence scripts, run against the new environment and saved with their hash files.
- Test the operational functions that matter: backup and restore, log delivery, alerting, failover. That's your OQ.
- Report in a short qualification summary that lists the template version, pipeline run, test results and open deviations.
With this in place, rebuilding an environment is a re-run of the same qualified process, and a new GxP application can inherit the landing zone's qualification instead of repeating it.
Continuous compliance checks
A qualified state only lasts until someone changes it. Check continuously:
- Azure: Azure Policy in audit or deny mode at
mg-gxp; Defender for Cloud regulatory compliance dashboard; deployment stacks with deny settings to stop changes outside the pipeline. Microsoft Purview Compliance Manager includes a 21 CFR Part 11 regulation template for your control mapping. - AWS: AWS Config with the sample conformance pack Operational Best Practices for FDA Title 21 CFR Part 11, deployed to every GxP account through the organization. It checks things like CloudTrail log file validation, backup plans and recovery point protection, encryption, MFA and public access. Export its results with
Get-AwsGxPConformanceReport.ps1.
AWS Audit Manager, which also had a Part 11 framework, closed to new customers and is moving to maintenance mode; AWS recommends Config conformance packs instead. If you already use Audit Manager, plan the move.
# One-off: GxP evidence for the notes-gxp account
.\Get-AwsGxPConformanceReport.ps1 -ProfileName notes-gxp -Region us-east-1 -NonCompliantOnly
.\Get-AwsGxPAuditTrailStatus.ps1 -ProfileName notes-gxp -GapsOnly
When the provider changes the platform
Cloud providers change services constantly: new features, API versions, retirements, regional changes. You can't control those changes, so control your response to them:
- Watch: Azure Service Health and Azure Updates (retirement notices), AWS Health events and scheduled changes. Route them to the team that owns the GxP platform, not to a general mailbox.
- Assess: for each notice that touches a GxP-approved service, record a short impact assessment: no impact, monitor, or raise a change.
- Rely on regression checks: the automated tests and evidence scripts from qualification double as regression tests after provider changes.
- Retirements: treat these as planned changes with lead time. Several have hit GxP estates in the last few years (for example Azure NSG flow logs moving to VNet flow logs).
Data location and exit
Record where GxP data lives (regions, backup copies, log archives) and restrict regions with policy. Write an exit plan: how you would export records, audit trails and metadata in a readable form if you left the provider or the SaaS vendor. The 2025 Annex 11 draft expects an exit strategy that keeps you in control of your data, and it's a question inspectors already ask.