BioPharm International - October 2020

BioPharm- October - Regulatory Sourcebook

Issue link: https://www.e-digitaleditions.com/i/1300450

Contents of this Issue

Navigation

Page 29 of 59

30 BioPharm International eBook October 2020 www.biopharminternational.com many synergies between 21 CFR Part 11 and the standard for mod- ern bio/pharmaceutical facilities, IEC 62443, especially at security levels two and above. For example, IEC 62443 System Requirement 1.1 (4) addresses the use of mul- tifactor authentication; similarly, requirements are stated in 21 CFR Part 11 for closed systems. Another example is the IEC requirement for dual approvals where an action can result in serious injury (4); dual signatures for critical actions are required in good manufacturing practices applications. Solutions' providers are addressing the challenge of legacy facility staff working remotely due to COVID- 19 by deploying globally dispersed teams that provide remote monitor- ing for facilities on a 24/7 basis. This flexible approach means that teams can detect and respond to any poten- tial cyber-threat in real time. Finally, and crucially, it is nec- essary that there is a change in work culture to support effective implementation of these cyberse- curity measures. Staff that work in the legacy environment need to be convinced that they should not work with outdated operating systems, while facility owners must be fully supportive of the need to address vulnerabilities and ensure that legacy systems are protected from cyber-threats. CONCLUSION Like other industries, the bio/phar- maceutical sector faces a number of cybersecurity challenges. This is particularly pronounced in the area of manufacturing, where a prevalence of legacy systems can cause exposure to cyber-risks. To address these challenges, solu- tions providers must conduct com- prehensive risk assessments, use best-practice approaches in rela- tion to data integrity, and draw on global resources and local know- how to monitor for cyber-threats. REFERENCES 1. K. Bissell, R. Lasalle, and P. Cin, "Ninth Annual Cost of Cybercrime Study," accenture.com, March 6, 2019. 2. IEC, IEC 62443 Series 3. CFR Title 21, Part 11, Electronic Records; Electronic Signatures. 4. IEC, Network and System Security, Part 3-3: System Security Requirements and Security Levels (2013). BP Regulatory Sourcebook Data Integrity Successful data migrations must be measured by the ex- tent to which they meet the business needs in a timely, cost-effective manner that attain the highest level of data integrity. By taking proactive steps to fully plan, scope, design, and develop a formal quality assurance (QA) ap- proach, a team will be poised to make their next migration a great success. The importance of planning Due to poor planning, many migration efforts come up short (or fail), resulting in project delays, cost overruns, lack of delivery, and bad data that compromise system in- tegrity and compliance. Insufficient planning often stems from the failure to view data migration efforts as distinct projects (as part of a larger project or program). But that is exactly what they are, and as such, are no less deserving of meticulous planning, rigorous project management, and adherence to a software development lifecycle. Migration projects should include all the major constructs of a significant application implementation, including dedicated resources like business analysts, technical developers, QA analysts, and a project manager. They should also include business stakeholder engagement, representing both the micro and macro view of the migration within the organization. For example, audit trails that capture data maintenance of raw materials, components, and ingredients must not only migrate in a good manufacturing practice (GMP)-compliant manner but should also be FDA-audit ready. Toward that end, organizations need to consider how the newly housed data and documents align with existing company audit plans. Scoping a migration Like any other software project, success begins with stakeholder engagement to accurately size the effort according to both business and technical requirements. Consider a scenario in which a team will be implementing a new document management system that supports core manufacturing processes. The legacy system being replaced is eight years old and holds over one million documents. How do you determine which and how many of these documents should migrate to the new system? To start, determine the "state" of the process with which these documents are associated. Documents, such as standard operating procedures supporting active processes will, of course, need to be migrated. But what about long-retired procedures that are no longer subject to regulatory inspection? If there are no clear needs to access a document in near real-time, wouldn't it make more sense to archive that document off-line? Similarly, how far back will a company need to maintain manufacturing logbooks and specifications for retired formulations? The scope of a data migration must include which data will be migrated, how to transform and enrich that data, and how to test the business and technical requirements of the project. Because a new system implementation can't happen without migrating data, it is critical to treat all migrations as software implementation projects in order to achieve desired results. —Art Meisler, principal consultant at Daelight Solutions Data Migration Essentials

Articles in this issue

Links on this page

Archives of this issue

view archives of BioPharm International - October 2020 - BioPharm- October - Regulatory Sourcebook