Computer System Configuration Management and Change Control

Computer System Configuration Management and Change Control Using Risk-Based Decision Making to Plan and Implement IT Change Justin J. Fisher Senior Manager, BT Quality and Compliance Pfizer

Agenda 1. Background 2. Audience Demographics 3. Scope 4. Introduction 5. Overview 6. Computer System Configuration Management 7. Computer System Change Control 8. The Valuable Interaction between Change Control and Configuration Management 9. Interactive Exercise 10.Summary

Background Education B.A. Education, Flagler College, St. Augustine, FL Experience Financial/Mortgage Industry IT Service Manager/ IT Change Manager Pharmaceutical Industry Internal and Independent Quality and Compliance Roles Computer Systems Validation and Infrastructure Qualification Quality systems Change Control, Incident Mgmt, CAPA/Investigations and Commitments Document and Records Management, etc. Lifecycle (Validation, Qualification, Project/Operational) Share Services

Getting To Know You Audience Poll Are you in IT? Delegated Quality or Compliance unit? Current Role in Change and Configuration Mgmt in your organization? Are you in Quality? Computerized Systems Quality?

Scope In Scope: Guidance for process expectations based on risk, scale, and complexity Out of Scope: Definitive application of processes at the technology level Risk of different architecture is varied, and we will not affix a risk categorization or specific process expectation to technologies (ie. Enterprise computer system used at multiple sites versus a desktop solution) Risk of business processes is varied Disclaimer: Theoretical definitions of Validation and Qualification Multiple resources available on understanding evolving industry expectations Terms will be used as they apply to historical use and experience

Introduction Configuration Management Change Control Computer System Configuration Management Appropriate configuration Mgmt processes should be established such that a computerized system and all its constituent components can be identified and defined at any point. 1 Computer System Change Control Change management procedures should be established. The point at which change management is introduced should be defined. Appropriate change processes should be applied to both project and operational phases. 1 1 ISPE. (2008). GAMP 5 A Risk-Based Approach to Compliant GxP Computerized Systems.

Overview Increased rigor and formality Project Configuration Management Change Control Clear hand-off from one phase to another Operations Configuration Management Change Control

Computer System Configuration Management a computerized system and all its constituent components can be identified and defined at any point. 1

Computer System Configuration Management Configuration Identification Configuration Control Configuration Status Accounting Configuration Evaluation

Identify Configuration Identification (What to keep under control) Configuration Item: Component of the system which does not change as a result of the normal operation of the system. 1 Deliverables that support the computer system User Requirements Functional Requirements Technical Architecture Configuration Specifications, etc. Computer System components Application modules and code Infrastructure Hardware Mid-tier solutions

Define Use a risk-based approach to determine the scale and complexity of a computer system configuration management process Finding the right granularity Scale, complexity, and risk Elements are controlled through Change Control Tell the story of the system through time Aids in Investigations

Key Elements of an Effective Configuration Management Solution Accessible Allows for more appropriate Impact Analysis and decision making Updateable Sufficient controls in place to prevent unauthorized modifications Accountability Change controls should adequately plan for configuration mgmt updates and follow through

Configuration Management Risk Avoidance Scale appropriately Unwieldy Best intentions may still not provide a dependable CMDB Utilize Periodic Review processes for continued maintenance Change from external systems may impact asset inventory Shared resources at risk of breaking CMDB if not appropriately addressed by all stakeholder Accountability to maintain system Strong quality system to hold teams accountable for compliance to the CM process

Computer System Change Control Change management procedures should be established. The point at which change management is introduced should be defined. Appropriate change processes should be applied to both project and operational phases. 1 URS 1.0 FS 1.1 FS 1.2 FS 1.3 CS 1.1.1 DS 1.1.2

Computer System Change Control Describe the proposed change Document and Justify the change Evaluate Risks and Impact of the Change Accept or Reject the Request Develop and Verify the change Approve and Implement the Change Close the Change

Risk Based Change Control Increase rigor and formality as we move up the chart Applying the same rigor and formality to a server change as we would new functional code to support new business processes is not risk-based decision making Impact continuum Impact cannot be viewed solely as outage, but the further down the pyramid, the greater likelihood of a failure causing outage rather than functional failure Consistent processes must be scalable for risk The same SOPs and Change Control processes can be used for all categories, however the rigor and formality that is prescribed by the process should be scaled accordingly. Increase formality and rigor of change control Category 5: Custom applications Category 4: Configured products Category 3: Non- Configured products Category 1: Infrastructure Software

Flexibility Different types of technological components of a computer system require nuanced management For many application changes, the change moves through a pre-production workflow for appropriate development and verification prior to moving into the production environment. For many changes to infrastructure, there is no concept of moving a change through prerequisite environments, but if using one Change Control process, it must allow for both types of movements of change. Shared infrastructure/services Infrastructure that is not allocated for one computer system and has an inherent design that does not relate back to a business process Data Centers and Computer Rooms Shared Databases Physical and virtual Server Farms Storage arrays A Change control process that is overly focused on application change control will be impossible to implement for shared infrastructure concepts

Priority Automate as much of the regulatory and internal requirements into the process as possible to keep the business running Expectations to understand regulatory impact and requirements is scaled based on the category of technology supported A server technician doesn t need to know the GMP regulatory requirements for the business processes supported by a Customized application hosted on their server, but they need to know how GMP regulations apply to how they are expected to exhibit control over a component of a regulated computer system Communicate process design to the business to level-set expectations

Impact Analysis Category 5: Custom applications Category 4: Configured products Category 3: Non-Configured products Category 1: Infrastructure Software Less likelihood of functional impact Change control process should provides sufficient guidance for evaluating the impact of a proposed change Reasonable estimate of the positive and/or negative impact to: Computer system configuration items Business processes Functions Availability Other scheduled activities (scheduled backups, disaster recovery activities, other planned changes) Reasonable and Scalable

Proceduralizing Change Control Much of what happens in IT is repeatable in nature, therefore duplicate changes may be implemented repeatedly Not a part of the normal use of the computer system or component Not used for novel or one-off changes Build the elements of the repeatable change into procedures Reduces documentation during change control execution Built in planning in accordance with known impact Greater likelihood of repeatable changes Category 5: Custom applications Category 4: Configured products Category 3: Non- Configured products Category 1: Infrastructure Software

Avoiding Common Issues with Change Control Urgency causes poor quality and may override thoughtful and appropriate risk-based planning Centralizing change management roles reduces accountability and expertise when managing a change Once change is made, record keeping can lapse Negative impact to Inspection ready state Not appropriately tied into Computer System Lifecycle When to follow Change Control procedures, and when to follow lifecycle procedures, or both

The Valuable Interaction between Change Control and Configuration Management Configuration Management Change Control

Benefits of Strong Process Design Accurate, dependable, and defendable decision making Improved integration into other Quality Systems processes Audit and Inspection efficiencies Reporting capabilities Metrics and greater visibility for process improvements Improved communication with business partners

Approval and Notification Clearly defined Configuration Items Notification to stakeholders Approval from relevant and required groups

Activity Impact Analysis and Mitigation

ISSUE Common Issues encountered in Computer System Configuration Management and Change Control Processes and Solution IMPACT Discuss possible negative impacts RESOLUTION Discuss possible resolutions

Scenario 1 ISSUE The configuration documented within the CMDB is out of date IMPACT Decisions may be made based on inaccurate information May lead to rework and project delays RESOLUTION Increase accountability and verification Periodic auditing of system/solution

Scenario 2 ISSUE Configuration is not detailed enough IMPACT Inability to perform thorough impact analysis of a proposed change or a reported event Critical changes to configuration may not be appropriately controlled RESOLUTION Clearly define the configuration expectations within your Configuration Management plan or SOPs

Scenario 3 ISSUE Configuration is too detailed IMPACT Unable to determine true impact of a proposed change or a reported event Difficult to maintain RESOLUTION Consider the risk of a configuration item to the overall system and the intended use of the system when determining the granularity that is appropriate for the CI Do not include configurations that change as a part of the normal use of the system

Scenario 4 ISSUE Configuration Management solution is too cumbersome and difficult to update IMPACT Easy to overlook/avoid CM expectations because it slows down the ability for IT to get the job done. RESOLUTION Develop CM solutions to ensure that the system is user friendly, intuitive, and makes sense to an IT professional. Consider the use of Industry Standard tools and processes.

Scenario 5 ISSUE The Change Control system is a glorified Word document IMPACT Very little automation in alignment with process requirements Greater variability in how the records are documented SME is required to be able to achieve sufficient documentation RESOLUTION Implement a common solution that meets process requirements (TrackWise, HP OpenView ServiceCenter) Configure a solution in alignment with the process

Scenario 6 ISSUE The Change Control process is not appropriately linked to configuration management processes Inability to meet requirements IMPACT Lack of understanding of how to use the processes Two separate processes are triggered independently and inconsistently Create technical and procedural linkages between the two systems RESOLUTION Automate changes to CIs within the CC system Increase periodic configuration evaluation

Scenario 7 ISSUE Change Controls are scheduled without regard to other scheduled activities IMPACT Greater potential for failure Significant potential for impact to other scheduled events RESOLUTION Embed Change Control coordination into process Ensure Impact Analysis includes review of scheduled activities

Scenario 8 ISSUE The Change Control process design is very focused on Application Change Control Open to significant interpretation by the other teams IMPACT May drive multiple processes; creating wrapper documents and sub-procedures to meet the requirements of the SOP by different technologies RESOLUTION Integrate perspective of all IT teams and technologies into process development

Summary Computerized System Configuration Management and Change Control are interrelated processes fundamental to the defendable control of a system through its lifecycle Strong process design, inclusive of the needs of different technologies, requiring appropriate analyses and mitigation strategies, leads to reduction of potential negative impact