CSA – Part 3: The journey to CSA. A historical review of applicable regulations and guidelines for Computer Software Assurance

The purpose of this article (CSA – Part 3) is to trace early origins of concepts expressed by the recent “computer software assurance„ or CSA approach (see CSA – Part 1), a relatively new term in the computerized system validation field, by reviewing applicable regulations and guidelines related to computer software assurance. This review was made possible by examining early relevant regulations and their evolution through the last few years/decades.

Highlighted in bold font is the focus of this 3rd article.

CSA – Part 1: Provide a brief summary of the latest guidelines related to CSA concepts 

CSA – Part 2: Provide a Summary/preview of the historical review analyzed and presented in more detail in the next article (see CSA – Part 3) in the series

CSA – Part 3: Provide a historical review of CSA-related regulations and guidelines and trace early origins of the new CSA approach related to computerized system validation and computer software assurance (this article)

CSA – Part 4: Examine the areas in which CSV is evolving into CSA based on the recent guidelines

Index

  1. The story of 21 CFR Part 211.68 – CGMP for finished pharmaceuticals – Automatic, mechanical, and electronic equipment
  2. The story of 21 CFR Part 11 – Electronic Records Electronic Signatures
  3. The story of 21 CFR Part 820 – Quality System Regulation
  4. FDA guidelines on Software Validation
  5. FDA’s Case for Quality (CfQ) initiative
  6. The story of GAMP5
  7. PIC/S guidelines and EU regulations
  8. Data Integrity
  9. Take-away points from this review
  10. Conclusion
  11. Acronyms
  12. References

In this review we provide a high-level (and at times a detailed-level) examination of the evolution of regulations to the CSA approach, along with its underlying origins and concepts. The documents referenced here were gathered by publicly available information from the internet and the links to all documents referenced in this article are embedded within the text. The figure below offers a timeline representation of the regulations and guidelines reviewed in this article, culminating in the three CSA-related articles published in 2022 (CSA -Part 1), which are highlighted in bold font.

  1. The story of 21 CFR Part 211.68 – CGMP for finished pharmaceuticals – Automatic, mechanical, and electronic equipment

21 CFR Part 211.68 describes the regulations for Current Good Manufacturing Practice (CGMP) For Finished Pharmaceuticals – Automatic, mechanical, and electronic equipment. The oldest electronic record available from the public internet mentioning the regulatory requirement that a computer system used in manufacturing processes under CGMPs needs to be calibrated/inspected/checked can be found in 43 FR 45077, an FDA Federal Record from 1978 (see Figure 1). At least in the case of computers, we could extrapolate that this could be one of the earliest references to computer system validation (CSV) and subsequently to computer software assurance (CSA).

Figure 1. 21 CFR Part 211.68, 1978 (43 FR 45077)

In 1991 a statement was added to 21 CFR Part 211.68(b), to express that the degree of verification of computer data (input or output) shall be based on the complexity and reliability of the computer system itself 56 FR 5671. We could potentially see here the primordial origins of the ‘risk-based approach‘ concept (see Figure 2).

Figure 2. 21 CFR Part 211.68, 1991 (56 FR 5671)

In 1995, in response to reviewers‘ comments, the FDA retained its previous position regarding accuracy verifications for computer systems stated in paragraph (b) of 211.68 and clarified it further in the federal record: 60 FR 4091 The FDA authors clarified their intention that the system/software manufacturer shall exercise ‘discretion‘ and ‘reasonable judgement‘ regarding input/output accuracy verifications. This intention could be interpreted as an early sign of the ‘critical thinking‘ concept expressed in the CSA approach, and supported by the FDA nonetheless (see Figure 3).

Figure 3. 211.68, 1995 (60 FR 4091)

The last revision of 21 CFR Part 211.68 was made in 2008 and published in 73 FR 51932. This change entailed the addition of paragraph (c) to state that certain operations may be performed by automated equipment and verified by a person, rather than one person performing an operation and another person verifying that the operation was correctly performed. This was done to minimize the possibility that the provision might be misinterpreted as requiring a person to repeat by hand all calculations performed by automated equipment. This revision was based on review comments by life sciences organizations, which can be viewed as an example of the collaborative nature between a regulatory entity and industry (see Figure 4).

Figure 4. 211.68(c), 2008 (73 FR 51932)

  1. The story of 21 CFR Part 11: Electronic Records Electronic Signatures (ERES)

In 1992, the FDA announced in 57 FR 32185 that it was considering to propose regulations that would accept electronic signatures in place of handwritten signatures. This announcement was based on increased utilization of computer systems in the life sciences industry, coupled with the need of organizations in the life sciences industry to be supported by regulatory guidance on the use of electronic systems. After several rounds of reviews and commentary from interested parties in the early and mid 1990s, the FDA’s 21 CFR Part 11 regulation for Electronic Records and Electronic Signatures (ERES) came into effect on 20 March 1997. This regulation laid the regulatory foundation in the industry for transitioning from paper-based to electronic means and has been in effect since. Elements of critical thinking, validation of computerized systems (CSV) and the need for the application of data integrity principles were evident (see Figure 5).

Figure 5. 21 CFR Part 11, 1997

In August 2003 a group of FDA divisions published the Guidance for Industry: Part 11, Electronic Records; Electronic Signatures – Scope and Application to describe the FDA’s re-examination of the scope and application of (ERES) regulations described in 21 CFR Part 11. The motivation for this re-examination was the industry’s concerns that the ERES regulations seemed too broad in scope, would increase the cost of compliance and discourage innovation, as well as some confusion regarding the ERES regulatory requirements for systems already in use prior to 1997, when the  21 CFR Part 11 regulation had come into effect. We see here another example of the interaction between regulators and industry. This collaboration based on the application of critical thinking by both groups, resulted in a harmonization and optimization regarding the applicability of the 21 CFR Part 11 (ERES) regulation.

In June 2017 a smaller group of FDA divisions published a draft guidance for the Use of Electronic Records and Electronic Signatures in Clinical Investigations Under 21 CFR Part 11 – Questions and Answers, which further aimed at clarifying the use, applicability and enforcement of 21 CFR Part 11 (ERES) regulations on computerized systems used in the life sciences industry.

  1. The story of 21 CFR Part 820.30:

21 CFR Part 820 describes the requirements for Quality System Regulation in CGMP. In 1978, according to 43 FR 31527, the FDA prescribed the need to address medical devices used in CGMP and added relevant requirements for medical devices (Subchapter H), into the 21 CFR Part 820 regulation.

In October 1996, the FDA expanded on the regulations for medical devices in cGMP. These regulations became effective on 01 June 1997. Firstly, 21 CFR Part 820.30 paragraph (a) stipulated the design requirements that manufacturers should establish for devices automated with computer software (class i). See Figure 6.

Figure 6. 21 CFR Part 820.30(a) – Design Controls

Secondly, in 21 CFR Part 820.30 paragraph (g), the FDA authors stipulated requirements for testing of production units, which allowed the manufacturers to choose the testing conditions. There was no mention of what exactly needed to be tested, or how much testing should be performed, or whether any testing performed by the software/system developer/provider could be leveraged by the life sciences manufacturer of pharmaceutical products. Even more intriguing is that the 820(g) regulation mentioned specifically that design validation should include software validation and risk analysis. We could interpret the latter as the origin of the ‘risk-based‘ approach to compliant GMP systems (and medical devices), where validation effort and rigor, including testing quantity and approach, is commensurate with system/software criticality (severity, frequency of occurrence, impact). There was no mention in this regulation, which stipulated that immense amounts of documentation needed to be produced during testing, or that every functionality of the system/software should be tested (See Figure 7).

Figure 7. 21 CFR Part 820.30(g) – Design validation

Thirdly, 21 CFR Part 820.70 paragraph (i), specifically mentions that “when computers or automated data processing systems are used as part of production or the quality system, the [device] manufacturer shall validate computer software for its intended use according to an established protocol“. The regulation did not specify explicitly how much testing needed to be performed, which software development methodology or framework was to be used, or how much testing could be leveraged from other sources, other than that the software should be validated for its intended use according to an established protocol (See Figure 8). Therefore, here we see another example of inherent critical thinking that must have been be applied, based on the regulatory guidance at the time, to provide the necessary and sufficient design parameters and testing to assure that the system performed as intended and that certain conditions and requirements had been met. The ‘protocol‘ could have been ‘established‘ based on user, design, functional, regulatory requirements and specifications, and tested according to the discretion of the manufacturer, as for example the discretion needed to verify input and output data coming in and out of a computer system, respectively, as mentioned in 211.68 above.

Figure 8. 21 CFR Part 820.70(i) – Automated Processes

21 CFR Part 820.70(i) Quality System Regulation, Automated Processes, was later revised in February 2022 to align with ISO13485 (Medical Devices). Requirements for validation of medical devices applied to:

  • software used as components in medical devices
  • software that is itself a medical device
  • software used in production of the device (e.g. PLCs) or in implementation of the device manufacturer’s quality system.
  1. FDA guidelines on Software Validation

In June 1997 the FDA’s CDRH published its first draft guidance titled: General Principles of Software Validation version v1.1, after request from both, medical device manufacturers and FDA staff (e.g. FDA auditors). This guidance applied “to all medical device software and to software used to design, develop or manufacture medical devices“ and it was the first attempt to explain the regulations we examined above (211, 820) with examples and with some clarifications. From as back as 1997 we can see the foundations and early origins of the CSA concepts, such as critical thinking, risk-based analysis and potentially leveraging vendor testing for the purposes of computer software assurance (See Figures 9 and 10).

Figure 9. General Principles of Software Validation, 1997

Figure 10. General Principles of Software Validation, 1997 (continued)

In January 2002 the FDA’s CDRH published a guidance titled: General Principles of Software Validation; Final Guidance for Industry and FDA Staff, which superseded the earlier guidance from 1997. This guidance emphasized the benefits that could potentially be achieved by computerized system validation (CSV), including less risk to patients and reduction of costs, among others. This seemed great at the time and the validation principles described in this guidance certainly helped numerous validation projects to validate systems and software worldwide (see Figure 11).

Figure 11. General Principles of Software Validation, 2002

Additionally, this guidance introduced the term and concept of “The least burdensome approach“ for software validation to comply with the regulatory requirements mentioned above, which seems to be the likely origin for the future “risk-based approach“ concept by GAMP5. It also emphasized the importance of complexity and risk assessments during validation coverage.

Figure 12. General Principles of Software Validation, 2002, continued

The absence of the word “necessary“ in the validation documentation to be produced during CSV in Section 4.8 of the 2002 FDA guidance is noteworthy. Could this have implied that „“unnecessary“ documentation could also be produced? Probably not, but this lays the grounds for potential confusion. With critical thinking for establishing the appropriate records/outputs/deliverables, as proposed by the new CSA approach, the “necessary and sufficient“ documentation for software validation should be produced. As the 2022 FDA guidance states: “Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified“. This is an example of the maturation process of CSV and its evolution to the CSA thinking (See Figures 12).

Twenty years later, on 13 September 2022, the latest draft guidance was published by the FDA (and subgroups such as UDDHHS, CDRH, CBER), and was titled: Computer Software Assurance for Production and Quality System Software, as mentioned in CSA – Part 1. Its focus areas for software assurance were the following: Identifying the intended use of the software, determining a risk-based approach for software validation, determining the appropriate assurance and testing activities, and establishing the appropriate records/evidence that would justify software assurance. Furthermore, this guidance provided several examples where CSA principles could be applied considering the 4 focus areas mentioned above.

Although this 2022 CSA guidance “did not provide recommendations for the design verification or validation requirements specified in 21 CFR Part 820.30 when applied to software used in a medical device (SiMD) or software as a medical Device (SaMD)“, it did reference the 2002 guidance for software validation for support in these areas.

  1. FDA’s Case for Quality (CfQ) initiative

Although the FDA’s draft guidance on CSA published in 13 September 2022 did not provide recommendations for the design verification or validation requirements for software in a medical device (SiMD) or software as a medical device (SaMD), as specified in 21 CFR Part 820.30 (see above), it is noteworthy to mention in this review an earlier initiative from the FDA’s CDRH group, regarding the Case for Quality. It is noteworthy because key concepts described in the Case for Quality initiative seem to be common with the new CSA approach for software validation.

A report published on 31 October 2011 by the FDA, titled: Understanding Barriers to Medical Device Quality, examined trends in the medical device industry. The report found that medical devices are becoming ever more complex due to new technologies, serious adverse effects related to medical devices (potentially including their underlying software) are increasing and that quality risks were largely attributed to manufacturing and design failures. The report also found that organizations that managed those risks from a ‘whole-organization‘ standpoint were more productive and had fewer product-related complaints and investigations, often associated with lower quality-related costs (e.g. smaller quality units within the organization), compared to organizations that did not manage product quality risks as effectively (See Figures 13 and 14).

The mission and vision of the Case for Quality (CfQ) program was to develop a culture shift for device manufacturers as well as regulators to focus more on sustained practices that improve medical device quality and patient safety, rather than merely complying to regulations.

Examples of this paradigm shift of the CfQ initiative were:

– increasing attention to supplier management and qualification.

– applying software development and testing to simulate the effects of actual usage.

– improving quality metrics collection, for example to track software quality rather than purely compliance-related metrics.

– emphasizing the importance of an organization-wide quality culture (led by management).

– linking incentives to quality performance.

– cultivating collaboration and communication between the quality team and various departments within the organization to avoid silos, so quality can become ‘everyone’s responsibility‘.

Figure 13. Case for Quality. Understanding Barriers to Medical Device Quality, 2011

Figure 14. Case for Quality. Understanding Barriers to Medical Device Quality, 2011, continued

6. A brief history of the GAMP5 guideline

In the early 1990s the regulatory requirements for CGMP (see above, 21 CFR Parts 211, 21, 820) had evolved to the point where life sciences industry organizations were seeking guidance on how to best comply with these regulations. The GAMP group was founded in the early 1990s to provide guidance for good automated manufacturing practices for computer systems and software used in pharmaceutical manufacturing operations to process, store and handle critical data. GAMP officially became part of ISPE in 2000 and is not only widely accepted and recognized as a good practice by professionals in the life sciences industry worldwide, but it also seems to be supported by regulatory authorities.

GAMP published their first guide, GAMP 1 in 1995, followed by  GAMP 2 in 1996, GAMP 3 in 1998, GAMP 4 in 2001 and GAMP 5 in 2008. The latest guidance is the second edition of the 2008 GAMP5, and was published in July 2022 (CSA -Part 1).

Throughout the evolution of the GAMP guideline, for almost three decades now, new concepts are being introduced and applied to align with advancing technologies, regulations and methodologies; concepts such as:

  • leveraging supplier activities to maximize return on investment and reducing cost of quality without compromising compliance with regulations.
  • applying science-based risk management and quality-by-design concepts.
  • producing evidence-based documentation commensurate with carefully thought-of validation effort/rigor.
  • applying critical thinking during testing and validation activities in general.
  • focusing on intended use rather that holistic approaches by not testing “everything“.
  • applying appropriate software development models (Waterfall, agile, hybrid models).
  • applying data integrity principles throughout the CSV and data lifecycles.
  • focusing on product and process understanding.
  • focusing on aspects critical to the patient and prioritizing patient safety and product quality over maximum compliance expectations.

As mentioned in CSA – Part 1, the latest GAMP5 guidance supports the concept of Computer Software Assurance (CSA) and offers good examples of how to apply critical thinking for efficient validation and assurance of computerized systems. One of the drivers for this publication was to provide guidance to improve the inefficient practices in the field of computer system validation due to “organizational inertia, lack of experience and training, compliance-driven tick-box approaches, and a misguided fear of perceived regulatory inflexibility”.

  1. PIC/S guidelines and EU regulations on Computer System Validation

The Pharmaceutical Inspection Convention/Co-operation Scheme (PIC/S) is a collaboration between 54 participating Regulatory Authorities in the field of Good Manufacturing Practice (GMP) of medicinal products for human or veterinary use and its mission is to harmonize inspection guidelines across its member states, which include the US, UK, Switzerland, and others. PIC/S is an informal, non-binding entity, and therefore it is not considered a regulatory body. In 2004, PIC/S established itself as a Swiss association based in Geneva, Switzerland.

In 1991, PIC/S published Annex 5 of the PIC GMP to define requirements for computer systems. In 1992 the PIC/S Annex 5 was incorporated into the EU GMP as Annex 11, becoming part of CGMPs in the European Union and was to be followed by European member states as regulation for the validation requirements of computerized systems.

Due to the technological advancements in the use of computerized systems in the life sciences industry and in alignment with the evolution of US FDA regulations related to computer and software validation requirements in the 1990s and 2000s (reviewed in earlier sections of this article), the 1992 EU Annex 11 was revised after almost 20 years and went into effect on 30 June 2011. Eudralex: The Rules Governing Medicinal Products in the European Union, Volume 4, Annex 11: Computerised Systems.

The revised Annex 11 (2011 version) adopted a risk-based approach, and was mostly aligned with industry computerized system validation good practices of the time, such as GAMP5: A risk-based approach to compliant GxP Computerized Systems. As with previous examples above, we are able to see certain regulations related to computerized system validation, which require critical thinking for their interpretation for the efficient validation of computerized systems (including software). See Figure 15 below.

Figure 15. EudraLex Volume 4, Annex 11: Computerized Systems, 2011

The EU Annex 11 on Computerized Systems has not been updated since 2011, neither has the PIC/S guidance related to computerized systems, as evidenced by the most recent PIC/S guidance PE 009-16, published on 01 February 2022, which lists the Annex 11 regulations as were stated in 2011.

Meanwhile, in 2007 PIC/S published its guidance for good practices for computerized systems in regulated “GXP” environments: PIC/S PI 011-3: 25 September 2007, whose purpose was to assist inspectors during the inspection of computerized systems at GxP-regulated organizations and was in very close alignment with the GAMP 4 guidance mentioned earlier.

On 19 September 2022 the concept paper on the revision of Annex 11: Computerized Systems guidelines was published (see CSA – Part 1). This concept paper is destined to  replace the EU Annex 11, as well as the latest PIC/S guideline for Computerized Systems. As this is currently a “concept” paper, and later it is planned to become a “draft” guideline, it is proposed to be adopted by the PIC/S committee in late 2026. Most probably, the EU regulations on Computerized systems will also be updated at around the same time.

  1. Data Integrity guidelines

Along with the regulations and guidelines we examined above, several regulatory bodies and industry guidelines (e.g. FDA in 2016, WHO in 2016, ISPE/GAMP in 2017, MHRA in 2018, PIC/S in 2021) have published draft guidelines on another ‘hot‘ topic, closely related to the CSA concept. This hot topic was data integrity in CGMP for pharmaceuticals (drugs), which inherently addressed good data integrity practices for software validation and assurance.

Several data integrity principles are common with CSA concepts, such as critical thinking, validation of software, ways of working via third party software service providers, understanding the data process to identify data with the greatest impact on patient safety and quality of products. These data integrity guidelines are not regulations per se, but act as good recommendations for both industry and inspectors alike. From these guidelines we see room for interpretation, and the importance of performing CSV projects based on understanding data workflows, data criticality and data controls (See Figures 16 and 17).

Figure 16. FDA guidance on data integrity, 2016

Figure 17. MHRA guidance on data integrity, 2018

  1. Take-away points from this review

– Regulatory entities and industry organizations seem to be collaborating well (e.g. FDA regulations and ISPE/GAMP guidelines). Guidelines on software validation and data integrity are well received and supported by the life sciences industry.

– There is evidence that regulatory bodies are harmonizing and consolidating their guidelines on software validation (e.g. Software for medical devices being incorporated into the Quality System Regulation (21 CFR Part 11, 820), PIC/S alignment with EU regulations).

– Current computer software assurance themes and concepts seem to have their origins in early regulations, sometimes from decades ago (e.g. The need for software validation, extent of validation rigor, leveraging IT service provider activities, applying data integrity principles, the need to use critical thinking for the interpretation of regulations).

– We have identified areas that were later clarified and improved in subsequent guidance versions (e.g. early FDA regulations being revised to clarify the need for verification of records, FDA’s revised guidance for principles of software validation from 1997 to 2002 and then again from 2002 to 2022).

– There are common themes between software validation guidelines, and validation of medical devices using software, i.e. SiMD & SaMD initiatives (e.g. FDA 21 CFR Parts 211 and 820 – requirements for design validation, automated processes, data integrity, risk analysis).

– There are common themes between software validation guidelines and data integrity guidelines (e.g. validation of system and data lifecycles, risk management, critical thinking).

– CSA aims to optimize CSV activities by prioritizing product quality and patient safety over extensive documentation for the sake of compliance to regulations, while at the same time helping to meet the appropriate regulatory requirements.

 

  1. Conclusion

In this review (CSA – Part 3), we took a historical approach to examine regulations and guidelines related to computerized system validation and computer software assurance. We examined the origins and evolution of some of these regulations and guidelines from various authoring bodies.

We were also able to identify and trace several common themes related to the recent computer software assurance (CSA) concept, not only within the applicable regulations for software validation, but also by looking at the case for quality initiative and data integrity principles from various authorities.

One of the main goals of this review article was to trace possible origins of the CSA concept to the earliest CGMP regulations (available in the public domain). Another goal was to help the reader appreciate the significance of the “interpretation“ of the regulations. Both, the regulations and the guidelines regarding computerized system validation have been evolving, and an increased degree of harmonization and alignment between regulations and guidelines can be seen.

The CSV/CSA practitioner, the auditor, the regulatory inspector, the industry leader, the software developer/manufacturer, the QA Manager, the IT expert, the automation engineer and others working in the CGMP environment, all possess the ability to think critically and should apply this critical thinking in all aspects of computerized system validation (CSV) as it matures and evolves into the computer software assurance (CSA) concept.

  1. Acronyms
CBER Center for Biologics Evaluation and Research
CDER Center for Drug Evaluation and Research
CDRH Center for Devices and Radiological Health
CGMP Current Good Manufacturer Practices
CSA Computer Software Assurance
CSV Computerized System Validation
CVM Center for Veterinary Medicine
ERES Electronic Records Electronic Signatures
EU European Union
FDA Food and Drug Administration
FR Federal Register
GAMP Good Automated Manufacturing Procedures
ISPE International Society for Pharmaceutical Engineering
IWG Inspectors Working Group
MHRA Medicines & Healthcare products Regulatory Agency
PIC/S Pharmaceutical Inspection Convention/Co-operation Scheme
PLC Programmable Logic Controller
SiMD Software in Medical Device
SaMD Software as a Medical Device
USDHHS U.S. Department of Health and Human Services
WHO World Health Organization
  1. References
  1. CSA – Part 1. Recent guidelines related to Computer Software Assurance.
  2. CSA – Part 2. Summary of historical review of applicable regulations and guidelines for Computer Software Assurance.
  3. GAMP5: A Risk-Based Approach to Compliant GxP Computerized systems. ISPE/GAMP. 2008.
  4. GAMP5, Second edition: A Risk-Based Approach to Compliant GxP Computerized systems, ISPE/GAMP, July 2022.
  5. Computer Software Assurance for Production and Quality System Software, Draft Guidance for industry and Food and Drug Administration Staff. US FDA, USDHHS, CDRH, CBER, 13 September 2022.
  6. Concept Paper on the revision of Annex 11 of the guidelines on Good Manufacturing Practice for medicinal products – Computerized Systems. PS/INF 94/2022, EMA and PIC/S, 19 September 2022.
  7. A guidance for industry: Part 11, Electronic Records; Electronic Signatures – Scope and Application. FDA, August 2003.
  8. Use of Electronic Records and Electronic Signatures in Clinical Investigations Under 21 CFR Part 11 – Questions and Answers. FDA, June 2017.
  9. General Principles of Software Validation, draft guidance version 1.1. USDHHS, FDA, CDRH, 01 June 1997.
  10. General Principles of Software Validation; Final Guidance for Industry and FDA Staff. USDHHS, FDA, CDRH, CBER, 11 January 2002.
  11. Understanding Barriers to Medical Device Quality. FDA, 31 October 2011.
  12. Eudralex: The Rules Governing Medicinal Products in the European Union, Volume 4, Good Manufacturing Practice Medicinal Products for Human and Veterinary Use Annex 11: Computerised Systems. European Commission, 30 June 2011.
  13. Good practices for computerized systems in regulated “GXP” environments. PIC/S PI 011-3, 25 September 2007.
  14. Guide to Good Manufacturing Practice for Medicinal Products, PIC/S, PE 009-16 (Annexes), 01 February 2022.
  15. Data Integrity and Compliance With CGMP Guidance for Industry, Draft Guidance. USDHHS, FDA, CDER, CBER, CVM, April 2016.
  16. ‘GXP‘ Data Integrity Guidance and Definitions. MHRA, March 2018.

 

Disclaimers

The information contained in this article is provided in good faith and reflects the personal views of the author. No liability can be accepted in any way. The information provided does not constitute legal advice.

Copyright

© CCG Solutions GmbH 2023 – 27 January 2023

Reproduction prohibited for commercial purposes. Reproduction for internal use is authorized, provided that the source is acknowledged.

Subscribing to our mailing list and receive newsletter with latest news and offers.