Automating GxP compliance in the cloud: Best practices and architecture guidelines

The Life Sciences industry (encompassing, but not exclusively bio-pharma, genomics, medical diagnostics, and medical devices) is governed by a set of regulatory guidelines called Good Laboratory Practice, Good Clinical Practice, and Good Manufacturing Practice (commonly referred to as “GxP”). GxP is intended to protect patient health by ensuring the safety, efficacy, and quality of medicinal products, medical devices, biologics, and other food products.

AWS customers and AWS Partner Network (APN) Partners have been building solutions mapping to GxP guidelines since 2010-2011. For example, Merck and Moderna have spoken and written about, respectively, their use of AWS to meet their GxP requirements. Similarly, Veeva, an APN Advanced Technology Partner focusing on helping life sciences organizations from research and development to commercialization, has discussed their move to AWS and how AWS certifications support their requirements.

One of the most important components of GxP is the integrity, reproducibility, and traceability of data that companies generate while developing, testing, and manufacturing GxP-regulated products. Adoption of cloud principles such as infrastructure as Code (IaC) and security as code help customers automate GxP compliance processes so that you can move fast, stay secure, and stay compliant.

Often, GxP compliance is a manual process that happens at distinct points in time. In other words, a company can show auditors that its system was compliant at a particular time on a certain day. However, the company may be challenged to demonstrate compliance outside of that point in time or how they manage on-going compliance.

In this blog post, we demonstrate how life sciences customers can automate GxP compliance processes using the AWS cloud. We’ll provide some of the best practices and architecture guidelines for developers, system administrators, and security specialists who want to automate their GxP compliance processes. However, the customer is ultimately responsible for system qualification and validation, including Installation Qualification (IQ), Operational Qualification (OQ) and Performance Qualification (PQ). Customers may use these best practices, design guidelines and automated testing to automate qualification and validation processes.

Best practices for GxP compliance

Below are some best practices to keep in mind while building a GxP workload on the AWS Cloud. You should consult with your compliance experts based on your company’s specific GxP requirements.

Design & Development

• Compliance by design to ensure that compliance requirements are considered as part of design and architecture from the initial stage. This is likely similar to existing practices with on-premises qualification.
• Use AWS Regions, Availability Zones, and edge locations to help you build global, scalable, flexible, and highly available systems.
• Source control and approve your entire infrastructure by integrating it with a continuous integration and continuous delivery (CI/CD) pipeline on AWS.
• Use a centralized audit log for better and faster visibility into your audit trail information and ensure it is immutable.
• Automate qualification and validation using automated testing of not just your software but your AWS environment as well to maintain continuous validation state of your application.

Security

• Take advantage of AWS cloud-native security services to help improve your security and compliance posture.
• Segregation of your protected or sensitive data from non-sensitive data using appropriate access control lists( ACL) . (For example, consider storing clinical data with Personal Identifiable information using a separate AWS account or separately controlled S3 bucket).
• Encrypt sensitive data (clinical or lab data with PII information as an example) in transit and at-rest to ensure that your data meets the highest information security standards using AWS Key Management Services (KMS) and AWS Certificate Manager (ACM).
• Maintain data integrity and traceability across your application.
• For robust access control, use mechanisms like least privilege access using AWS IAM, multi-factor authentication using AWS MFA, and single sign-on using AWS SSO or an IDP, including Cognito.

Architecture overview

The following diagram (Figure 1) depicts an overall architecture that you can use to build a system to automate the validation of your GxP controls. The centerpieces of this system are the AWS Service Catalog and AWS Landing Zone. The AWS Service Catalog provides a single location where life sciences enterprises can centrally manage their catalogs of IT services. Life sciences security administrators can control which AWS services and versions are available, limit the configuration of the available services, and delegate permissions access by developer or by role. AWS Landing Zone is a solution that helps customers more quickly setup a secured, multi-account AWS environment based on AWS best practices. It provides a baseline environment with multi-account architecture, identity and access management, governance, data security, network design, and centralized logging that are integral parts of GxP solutions.

Figure 1: Reference architecture for GxP compliance

Here is a step-by-step walkthrough of the architecture shown in Figure 1, with a basic overview of how each AWS service fits together to help you manage the lifecycle of your GxP environment:

1. AWS Landing Zone allows the security administrator to automate the setup of an environment for running secure and scalable workloads. It also provides a baseline to get started with multi-account architecture, identity and access management, governance, data security, network design, and logging. When you implement Landing Zone, you can enable add-ons like a Centralized Logging Solution, AWS Directory Service for Microsoft Active Directory, or an Active Directory Connector for AWS SSO.
2. Your security administrator can define an AWS Service Catalog product (for example, a GxP application) using AWS CloudFormation templates. Typical products include pre-approved configurations for servers, databases, websites, or applications that are deployed using AWS resources (for example, an Amazon EC2 instance or an Amazon Relational Database Service (Amazon RDS) database). After your security administrator defines the GxP application using a CloudFormation template as a framework (refer to sample code in GitHub), they can publish it for developers in the AWS Service Catalog. Developers can use this framework to further enhance the template based upon the application requirements.
3. Developers take the framework and modify applications to further enhance it under Git source control and use AWS CodeCommit to fully manage the private code repository. Customers also can use Jenkins Pipeline to integrate with AWS CodePipeline for managing CICD operation.
4. When a developer is ready to deploy the modified code from CodeCommit to their GxP infrastructure, they use the AWS Service Catalog to launch the product they need as a CloudFormation stack.
5. The stack automatically provisions the necessary AWS resources based on what has been committed to the code repository as specified by the developer.
6. CodeCommit contains the application and system configuration source code pushed by the developers. Because the AWS Service Catalog is at the center of this architecture, developers can release their source code without needing to access any underlying resources or go through security administrators. Service Catalog can also be integrated with your existing ITSM tools like ServiceNow to raise AWS service requests, for more details, refer to the What’s New announcement for AWS Service Catalog Connector.
7. When the CloudFormation Stack is executed, you can also automate the testing and Installation Qualification (IQ) process to ensure that all services are being provisioned per your configuration specifications, system requirements, and application requirements. You can do this using serverless AWS Lambda functions and/or a Python program (or your preferred programming language) to create a test summary and qualification report automatically in an Amazon Simple Storage Service (S3) bucket for further consumption.
8. Access to the stack and its underlying resources is recorded and tracked through AWS CloudTrail, and the data is stored in S3. All individual CloudTrail logs, VPC Flow Logs, and AWS Config changes are aggregated into a centralized S3 bucket in a separate AWS Account for security purposes.
9. The security administrator configures, monitors, and sets up automated alerts/notification on changes and the health of the stack. The security admin can access dashboards and metrics via Amazon CloudWatch and/or through third-party applications. Refer to the diagram below for some sample non-compliance
10. When the stack is changed, change events are recorded and tracked through AWS Config. Any events that are out of compliance are displayed in the AWS Config compliance dashboard and notification can be sent to users using Amazon Simple Notification Service (SNS).
    

    Figure 2: Sample Config dashboard for Non-compliance

11. To indicate that something may be out of compliance, CloudWatch can initiate alarms based on rules that you design.
12. CloudTrail monitors API calls made against the AWS environment to track each and every control plane request for audit trail purposes.
13. The administrator is notified/alerted by CloudWatch Events when something changes that could cause the system to be non-compliant.
14. CloudTrail log files from the centralized logging S3 buckets will be queried and converted into a human readable format like CSV using Amazon Athena, for any audit purpose. Refer to the AWS CloudTrail Logs documentation for information about querying and viewing CloudTrail Logs.
15. You can visualize CloudTrail Logs using Amazon QuickSight, as outlined in this post on the AWS Big Data Blog.

                               Figure 3: Amazon QuickSight dashboard for Analyzing audit trail data

Conclusion

This blog post provides best practices and a sample framework for implementing an automated GxP solution in the AWS Cloud. We recommend consulting with your internal compliance and legal team before implementing these best practices to ensure that they align with your existing quality and compliance processes and policies.  Based on your compliance need you can expand on this architecture by  leveraging AWS Control Tower to manage your multi-account strategy and AWS Security Hub for a comprehensive view of your high-priority security alerts and compliance status as they are generally available now.

Further Reading

After reading this post, we recommend that you review the AWS Shared Responsibility Model and the whitepaper “Considerations for Using AWS Products in GxP Systems.”  To learn more about GxP compliance on AWS, visit the GxP Compliance Page. You can access additional GxP resources via AWS Artifact after logging into your AWS Management Console.

As part of the shared responsibility mode, it is a customer’s responsibility to define the various GxP security and compliance requirements. Customers can use AWS certifications like ISO 9001, ISO 27001, ISO 27017, PCI DSS, SOC 1, and SOC 2 to understand how AWS services are being assessed by 3^rd parties as well as the BioPhorum IT Control Implementation and Responsibilities (all of which can be downloaded through AWS Artifact) to help build out their associated quality and control mappings.  The specifics of those control mappings are beyond the scope of this post and it is recommended that customers engage their AWS team for further support.

Learn more about how Merck achieved their GxP compliance on AWS Cloud: AWS re:Invent 2016: GxP Compliance in the Cloud and their continuous compliance journey : AWS re:Invent 2016: Continuous Compliance in the AWS Cloud. Similarly Moderna Therapeutics delivers mRNA drug faster, at lower cost and in compliant way using AWS cloud, refer to Moderna case study here.

Click here to learn more about AWS for Life Sciences