Migration & Modernization

GxP considerations for large scale migrations Part – 2

Introduction:

This is Part 2 of our three-part series on Good x Practice (GxP) requirements in large-scale migrations. While Part -1 covered GxP assessment, this segment focuses on the mobilization phase of the AWS three-phase migration framework – Assess, Mobilize, and Migrate & Modernize goals and workstreams.

In this blog we introduce a new layered model approach to build governance, establish landing zones, and meet GxP requirements. This layered approach provides a clear separation of concerns, aligns to typical organizational structures and provides a structure that can be reflected in your QMS.

Organizations can adopt this suggested structured, layered approach that integrates GxP compliance with technical implementation to accelerate migrations.

Mobilize phase goals and workstreams

The goal of the mobilize phase is to enable the migration of business applications to the AWS cloud while laying the foundation for tooling, processes, and culture. These workstreams accelerate GxP-compliant migration at scale. The following workstreams are recommended to be run during this phase:

  • Landing Zone (LZ):Organizations must balance builders’ needs to stay agile while providing governance at scale. Establishing foundational standards allows you to enable, provision, and operate environments for business agility and governance at scale. This includes building an AWS environment with a multi-account architecture and an initial security baseline that incorporates security, risk, and GxP compliance requirements. The framework encompasses identity and access management, data security, network design, logging, and shared services.
  • Migration Governance:Establish governance mechanisms to oversee the GxP-compliant migration program, which may include creating a Cloud Business Office (CBO) as part of a Cloud Center of Excellence (CCoE). One useful technique is for the CBO to develop a quality systems assurance plan that describes how control is maintained across the cloud environment. The CBO can include a role dedicated to coordinating regulatory changes with business units, IT quality, and compliance. Demonstrating control over the IT operating environment is crucial for inspections, traditionally requiring evidence from Quality Management Systems and SOPs. With cloud technology, this process is simplified using tools including Amazon Security Lake, AWS CloudTrail Lake, AWS Config, and AWS Audit Manager.
  • Operations Model: Define the future-state cloud operating model, including processes for monitoring, incident management, and ongoing optimization of GxP-compliant systems. The operating model should encompass the relationships among people, processes, and tools to support the delivery of organizational objectives. Stay ahead of regulatory changes by embedding regulatory expertise in the CCoE/CBO to relay regulatory changes to the cloud platform engineering team. Prepare the cloud engineering and operations team, which is part of the CCoE, with training and knowledge transfer from AWS.

Shared responsibility model

GxP compliance in cloud environments follows a shared responsibility model between AWS and the customer. This model helps distribute the compliance burden, with AWS managing certain aspects while customers maintain control over others.
AWS responsibilities (security and compliance “of” the cloud) include operating, managing, and controlling components from the host operating system and virtualization layer down to the physical security of data centers. AWS maintains infrastructure verification and security controls, and provides documentation for AWS compliance-relevant processes and controls through AWS Artifact.

Customers own the responsibility for Good x Practice (GxP) compliance. This includes cloud platform design and management, shared IT capabilities development, business application infrastructure and automation, and maintenance of application-level GxP considerations. These responsibilities ensure proper configuration and use of Amazon Web Services (AWS) in alignment with GxP requirements. Customers must also develop and maintain necessary GxP documentation for their specific implementation.

A GxP version of this responsibility model was presented in the GxP Systems on AWS whitepaper:

Shared responsibility model with mapping industry guidance for GxP workloads.

Figure 1: Shared responsibility model with mapping industry guidance

The Layered Approach

GxP regulations require organizations to demonstrate control over the environment in which GxP workloads will operate. A top-level assurance plan is a good starting point to explain how each layer of the cloud environment is maintained under a state of control. The layered model provides a structure to guide the creation of new Quality Management System (QMS) documents or identify existing QMS documents that require revision. Organizations should complete any QMS updates during this phase to avoid delaying migration execution.

A primary concern for regulated enterprise customers is demonstrating control over a system when responsibilities are shared with a supplier. Taking the layered approach a step further, a layered assurance plan aims to address this and other similar concerns. The strategy will employ methods to address the customer’s regulatory needs.
To scope the assurance plan, the workload architecture should be viewed in its entirety. Enterprise-scale customers typically define the architecture similarly to the following:

  • Layers 0 and 1represent the AWS Global Infrastructure and foundational services for which AWS is responsible.
  • Layers 2 and 3represent the Mobilize phase workstreams covering building a regulated landing zone consisting of shared capabilities.
  • Layers 4 and 5represent applications and their building blocks, along with the business infrastructure automation built by the App team.

In this blog, we will explore layers 0 through 3 and then cover layers 4 and 5 in the next part of the blog series.

Figure 2: Layered approach, mapping to the shared responsibility model and mobilize phase workstreams marked in red.

Figure 2: Layered approach, mapping to the shared responsibility model and mobilize phase workstreams marked in red.

Layers 0 and 1 – AWS

Demonstrating control starts at the lowest level of the model with a supplier assessment. This assessment should consider the AWS services that includes the documentation available from the AWS website and AWS Artifact. For GxP compliance purposes, organizations typically rely on AWS’s SOC 2 and C5 audit reports, ISO 9001 and ISO 27001 certifications. These key documents, along with the AWS Quality Management System Overview, are referenced in the Supplier Assessment section of the AWS GxP whitepaper.

Layer 2 – Cloud platform design and management

This layer enables secure and compliant access to cloud services via accounts, with a landing zone serving as a multi-account environment for deploying workloads and applications.
Create an LZ using AWS Organizations or the Landing Zone Accelerator, which allows you to use a template to automate deployment. This simplifies change management and ensures consistency, as any modifications to the LZ involve updating the version-controlled template.

Organizational units (OUs) simplify account management by allowing policies to be applied collectively to all accounts within an OU. This is beneficial for compliance with specific regulations within GxP. AWS Organizations offers policies for central management of accounts.

Management policies allow for centralized configuration and management of AWS services. Backup policies help ensure backups are applied across accounts, particularly for data integrity and ALCOA+ requirements. Additionally, tag policies standardize resource tags, aiding in the identification of GxP workloads and supporting configuration management and application inventory.

Authorization policies help manage AWS account security in organizations. A common GxP request is to restrict approved services for GxP workloads. Approved services must be reviewed and maintained under control by the provider, with compliance evidence from programs like SOC 2 and ISO. These policies can be enforced using service control policies (SCPs) to limit service use. Specific regulatory constraints, such as HIPAA for PHI data, may require additional controls, which can be managed through policies for different organizational units.

Guardrails, which are governance rules for security and compliance, can be preventive (preventing non-compliant resource deployment) or detective (monitoring and alerting on rule violations). For instance, AWS CloudTrail must be enabled in all accounts, and public read access to Amazon Simple Storage Service (Amazon S3) buckets should be disallowed.

Having a secure account baseline is an effective way to demonstrate control in your cloud environment. For example, you should remove the default Amazon Virtual Private Cloud (Amazon VPC), deploy an approved Amazon VPC, and set up necessary security roles and stacks. Additionally, ensure that CloudTrail is enabled for logging purposes.

Typically, the standard practice is to maintain the core account structure using the Landing Zone Accelerator (LZA), while utilizing AWS Control Tower Account Factory for account vending related to workload accounts.

The delivery and operations of the regulated landing zone will include a formal qualification and handover with necessary documentation such as designs and runbooks, which must be maintained through change management. Using markup stored in the LZA code repository has proven effective for this purpose, as the documentation is updated alongside the template. Upon deployment, the documentation is uploaded to a shared repository, ensuring consistency with the LZ configuration. Verification tests will validate the LZ’s functionality, and the deployment pipeline can incorporate automated tests to confirm that the LZ is deployed and configured correctly.

Layer 3 – Building shared capabilities

This layer focuses on enabling IT shared capabilities for GxP migrations by assuming as much regulatory burden as possible. The CCoE’s mandate includes understanding the needs of development teams using the LZ and incorporating features to ease their workload. This involves understanding regulatory requirements and adding automation to the platform to meet those needs.

Cloud foundations must include common capabilities like centralized logging and core networking, as well as specific tools for GxP workloads to meet 21 CFR Part 11 requirements for data integrity. For instance, to support ALCOA+ principles, implement automated backup policies for GxP accounts that include both backup and restore capabilities. Additional examples include a central data archive and compliance reporting dashboards. Each capability will come with thorough documentation on design, delivery, and operational runbooks.

The migration of GxP workloads will utilize common tooling, ideally in a shared services account, with a strong emphasis on data integrity due to GxP regulations. Tools for data migration should ensure integrity is maintained and verification processes are planned post-migration. This verification can follow a standardized approach across the migration effort but must relate to each application’s data store.

Traditionally, regulated companies used installation qualification (IQ) protocols for manual installation steps. This can now be replaced by infrastructure as code (IaC) templates and scripts, which not only describe the required infrastructure but also automate deployment. This shift will require approvals and possible changes to your QMS.

Portfolio Analysis and Migration Planning

A thorough portfolio analysis is essential in GxP-regulated environments, emphasizing compliance and technical factors. It starts with assessing applications based on regulatory classification, data sensitivity, and compliance needs, while also considering technical dependencies to maintain ongoing compliance during and after migration.

The portfolio analysis should classify applications by GxP status (GxP vs. non-GxP), criticality, and compliance needs. This involves assessing systems with electronic records, electronic signatures (21 CFR Part 11), or validated processes, focusing on data integrity (ALCOA+), system availability, and regulatory reporting requirements.

The application portfolio assessment involves analyzing critical applications that affect product quality, patient safety, and data integrity. It maps interdependencies between systems to understand relationships among databases and interfaces, which is essential in GxP environments where data flows require validation. The analysis also considers technical complexity, including legacy technologies, custom code, and compliance requirements, which impact migration strategies.

During portfolio analysis, GxP workloads are identified to determine the necessary supporting services. These services may require both approval and formal qualification to determine appropriate configurations and guardrails. While AWS qualifies the standard documented features of a service, your specific configurations must also be qualified. In the wave planning phase, workloads are grouped into common archetypes for efficient migration. Identifying service configurations or “building blocks” that can be templatized and reused, such as standard server types or preconfigured Amazon S3 buckets that meet ALCOA+ requirements. This approach reduces validation effort and ensures consistency across migrations.

Common AWS services used during a mass migration include:

This systematic approach ensures that the migration maintains GxP compliance while optimizing the use of resources and minimizing business disruption.

Conclusion

In this blog, we discussed how Good x Practice (GxP) applies to various activities during the Mobilize phase. To ensure an accelerated and successful GxP-compliant migration to AWS, organizations can follow a structured, layered approach that integrates regulatory compliance with technical implementation. It is important to prioritize Mobilize phase actions based on GxP requirements to ensure that compliance is an integral part of the cloud infrastructure from the very beginning. In part-3 of this blog series we will cover Layer-4 and Layer-5 the Applications and Infrastructure layers that will dive deeper into application level GxP considerations and infrastructure automation.