Home|← Back to Evidence

GxP & CSV in AWS

Best practices for implementing Computer System Validation and Good Practice requirements in AWS cloud environments

1. Understanding GxP in the Cloud

1.1 What is GxP?

GxP is an umbrella term covering Good Practice quality guidelines and regulations that apply to Life Sciences:

  • GMP - Good Manufacturing Practice (pharmaceutical manufacturing)
  • GLP - Good Laboratory Practice (preclinical studies)
  • GCP - Good Clinical Practice (clinical trials)
  • GDP - Good Distribution Practice (supply chain)
  • GDocP - Good Documentation Practice (record keeping)

All GxP guidelines share common principles: data integrity, traceability, audit trails, and quality management.

1.2 What is Computer System Validation (CSV)?

Computer System Validation (CSV) is the documented process of ensuring a computerized system does what it''s supposed to do in a consistent and reproducible manner. CSV is required for any system that creates, modifies, maintains, archives, retrieves, or transmits GxP data.

CSV Core Principle

"A validated system provides documented evidence that the system is capable of consistently producing results meeting predetermined specifications."

1.3 Why Cloud Validation is Different

Traditional CSV assumed on-premise infrastructure you fully controlled. Cloud introduces new considerations:

☁️
Shared Infrastructure

AWS owns the hardware; you manage the application

🔄
Continuous Updates

AWS services update frequently without your control

🌐
Global Distribution

Data may physically reside across multiple regions

🔧
Serverless Architecture

No traditional "servers" to validate

2. GAMP 5 Framework for Cloud

2.1 GAMP Categories

GAMP 5 (Good Automated Manufacturing Practice) provides a risk-based approach to CSV. Systems are categorized by complexity:

Category
Description
Validation Approach
Cloud Example
Category 1
Infrastructure
Operating systems, databases, middleware
Supplier assessment + IQ
AWS infrastructure (EC2, RDS)
Category 3
Non-configured
COTS software used "as-is"
Supplier assessment + IQ/OQ
Cognito, S3, DynamoDB (default config)
Category 4
Configured
COTS software with configuration
Supplier assessment + IQ/OQ/PQ
VDC System (AWS services + custom Lambda)
Category 5
Custom
Fully custom-developed software
Full SDLC + IQ/OQ/PQ + code review
Custom ML models, proprietary algorithms

2.2 VDC System Classification

The VDC system is GAMP Category 4 (Configured Product):

  • Uses AWS managed services (S3, DynamoDB, Cognito, Lambda) - these are COTS
  • Configured with IAM policies, Cognito groups, API Gateway routes
  • Custom Lambda functions implement business logic
  • Frontend is a static site (Next.js) with minimal custom code

Validation Strategy: AWS supplier assessment + full IQ/OQ/PQ on the configured application.

3. Cloud Validation Approach

3.1 Shared Responsibility Model

AWS Responsibility
Physical security (data centers, hardware)
Network infrastructure (VPC, CloudFront)
Service availability & reliability
Infrastructure patching & updates
Compliance certifications (SOC 2, ISO 27001, HIPAA)
Evidence: AWS Artifact (audit reports), AWS compliance programs
Customer Responsibility (You)
Application validation (IQ/OQ/PQ)
User access controls (IAM, Cognito)
Data encryption (keys, policies)
Audit trail implementation
Backup & disaster recovery
Change control & configuration management
Evidence: Your validation documentation, SOPs, training records

3.2 AWS Supplier Qualification

Before validating your application, qualify AWS as a vendor:

1
Review AWS Compliance Documentation
  • AWS Artifact: Download SOC 2 Type II reports
  • Review ISO 27001, ISO 27017, ISO 27018 certifications
  • Check HIPAA BAA availability
  • Review AWS Life Sciences compliance program
2
Assess Service Maturity
  • Verify services are Generally Available (not preview/beta)
  • Review service SLA commitments
  • Check service history (uptime, incidents)
3
Document Supplier Qualification
  • Create vendor qualification document
  • Define periodic review schedule (annual)
  • Monitor AWS Health Dashboard for service issues

3.3 Validation Testing Strategy

The VDC system follows a risk-based testing approach:

Qualification
Focus
VDC Tests
IQ
Installation
Verify AWS resources deployed correctly via CloudFormation
11 tests - Cognito config, S3 encryption, DynamoDB tables, IAM policies
OQ
Operational
Test individual Lambda functions and API endpoints
21 tests - Each Lambda function, auth flow, audit creation, error handling
PQ
Performance
End-to-end workflows with role-based scenarios
29 tests - Submit→Approve workflow, RBAC, ALCOA+ compliance, performance

Result: 61 test cases, 100% pass rate

4. Data Integrity (ALCOA+)

4.1 ALCOA+ Principles

Data integrity is the foundation of GxP compliance. The ALCOA+ acronym defines data integrity requirements:

A
Attributable

Who performed the action? Identity must be traceable.

VDC: Cognito user ID + email in every audit record
L
Legible

Can the data be read and understood?

VDC: UTF-8 JSON, human-readable format
C
Contemporaneous

Was it recorded at the time of the action?

VDC: ISO 8601 timestamp generated at action time
O
Original

Is this the first recording, or a copy?

VDC: S3 versioning preserves original uploads
A
Accurate

Is the data correct and free from errors?

VDC: SHA-256 hash verification
+
Complete, Consistent, Enduring, Available

Additional modern data integrity requirements

VDC: Complete audit trail, immutable records, 7+ year retention

4.2 Cloud-Specific Data Integrity Controls

Risk
Cloud Challenge
VDC Mitigation
Data Tampering
S3 objects can be overwritten
S3 versioning + SHA-256 hash verification
Audit Trail Modification
DynamoDB items can be updated/deleted
IAM policy denies UpdateItem and DeleteItem on audit table
Unauthorized Access
Cloud console access to raw data
IAM least privilege + Cognito MFA + CloudTrail monitoring
Data Loss
Accidental deletion or service failure
S3 versioning + cross-region replication (if needed)
Time Synchronization
Distributed systems, clock drift
AWS NTP service + ISO 8601 UTC timestamps

5. Change Control in the Cloud

5.1 Types of Changes

In a cloud environment, distinguish between:

AWS-Managed Changes
  • Service Updates: AWS patches, feature additions (you don''t control timing)
  • Infrastructure: Hardware refresh, data center maintenance
Action: Monitor AWS Health Dashboard, review release notes
Customer-Managed Changes
  • Application Code: Lambda function updates, frontend changes
  • Configuration: IAM policies, Cognito settings, API Gateway routes
  • Infrastructure as Code: CloudFormation template updates
Action: Follow your change control SOP, re-validate as needed

5.2 Risk-Based Change Control

Not all changes require full re-validation. Use a risk-based approach:

Risk Level
Example Changes
Validation Impact
Low
UI text changes, CloudWatch log retention
Change control only, no re-testing
Medium
New feature (doesn''t affect existing), IAM policy refinement
Targeted OQ tests for new functionality
High
Audit trail modification, authentication changes, data model updates
Full impact assessment + relevant IQ/OQ/PQ re-execution

5.3 Infrastructure as Code Benefits

Using CloudFormation for deployment provides validation advantages:

  • Repeatability: Same template deploys identically to dev/prod
  • Version Control: CloudFormation templates in Git = change history
  • Automated Testing: Deploy to dev, run tests, promote to prod
  • Rollback: CloudFormation stack rollback if deployment fails

6. Common Questions

Q: Do I need to validate AWS services themselves?
A: No. AWS services (S3, DynamoDB, Lambda) are COTS software (GAMP Category 3/4). You qualify AWS as a supplier and validate your application built on those services.
Q: What if AWS updates their services?
A: AWS manages backward compatibility. Monitor AWS Health Dashboard for breaking changes. Most updates are transparent and don''t require re-validation. Major updates should trigger impact assessment.
Q: Can I use AWS for GxP Production systems?
A: Yes. Many large pharma companies (Moderna, Pfizer, AstraZeneca) run GxP workloads on AWS. Key is proper validation, supplier qualification, and following GxP principles.
Q: Do I need separate AWS accounts for dev/prod?
A: Strongly recommended. Separate accounts provide clear environment isolation, prevent accidental changes, and simplify audit trails. VDC uses separate resources (not just S3 buckets) for dev and prod.
Q: How do I prove data integrity in S3?
A: (1) Enable S3 versioning to preserve all uploads, (2) Calculate SHA-256 hash on upload, (3) Verify hash on download. This proves files haven''t been tampered with.
Q: What about audit trails for AWS console access?
A: AWS CloudTrail logs all API calls (including console actions). Enable CloudTrail in all regions, send logs to immutable S3 bucket. This provides infrastructure-level audit trail.

7. Resources

← Previous: 21 CFR Part 11Back to Evidence →