IT Systems Validation for SOx and Regulatory Compliance

Importance of Information Systems Audit and Validation

Information technology has become a core enabler of business processes within the organizations today. As a result, companies are required to audit and validate their relevant IT systems to ensure that their business processes and underlying records comply with regulations such as the Sarbanes-Oxley Act of 2002 or Healthcare Insurance Portability and Accountability Act (HIPAA) or 21 CFR Part 11(FDA). This paper defines an “easy-to-implement” framework for auditing and validating IT systems for regulatory compliance. It also identifies a best practice which calls for IT organizations and software vendors to proactively audit their software development and implementation processes on an ongoing basis to identify and correct any systemic issues to lower the cost of compliance.

The Sarbanes-Oxley Act signed into law on July 30, 2002, takes corporate governance, disclosure and financial accounting to new heights. The crux of the legislation – aimed squarely at public companies – centers on ensuring the accuracy, consistency, transparency, and timeliness of financial results and disclosures. Establishing and maintaining an adequate internal control structure and procedures for financial reporting is at the core of compliance with section 404 of Sarbanes-Oxley Act. However, there is a strong linkage between the enhanced internal controls that the act demands and the information systems that manage data, implement workflows, and automate business processes. In fact, the accuracy and timeliness of financial reporting is heavily dependent on a well-controlled IT environment. PCAOB Auditing Standard No. 2 discusses the importance of IT in the context of internal control. In particular, it states: “The nature and characteristics of a company’s use of information technology in its information system affect the company’s internal control over financial reporting.”

Many companies are using the COSO framework for internal controls – where the importance of IT controls is embedded in the framework. These companies are then applying the C OBIT model of IT Governance to ensure that the right level of IT controls are implemented (see figure 1). Compliance with Sarbanes-Oxley Act requires that financial systems used in the preparation of required financial statements be controlled and validated to prove the accuracy and timeliness of certain financial data.

Figure 1: Sarbanes-Oxley: Internal Control Components Source:
IT Control Objectives for Sarbanes Oxley, ISACA
Please click on image for enhanced version)

HIPAA (Healthcare Insurance Portability and Accountability Act, passed in 1996), presents the health care industry with extensive regulations that significantly impact the technical and operational aspects of health care information systems and embedded health care systems. It includes standards for electronic exchange of administrative and financial healthcare transactions between health care providers and insurance providers and includes privacy rules to protect the confidentiality and security of health data being transmitted. Companies have rushed to make appropriate changes to their software to comply with the regulation. However, the challenge now is to ensure that the systems infrastructure continues to be validated on an ongoing basis to stay compliant with the HIPAA requirements.

21CFR Part 11 was implemented in 1997 to let the FDA accept electronic records and signatures in place of paper records and handwritten signatures for compliance. The regulation outlines controls for ensuring that electronic records and signatures are trustworthy, reliable, and compatible with FDA procedures and as verifiable and traceable as their paper counterparts. Hence 21 CFR Part 11 also specifies a number of requirements for software systems to enable trustworthy and reliable electronic records and signatures – see Figure 2. These software requirements must be met for the resulting electronic records to comply with FDA mandated Current Good Manufacturing Practices (cGMP). If an organization employs electronic records and signatures, but fails to comply with these system requirements, the FDA will cite the firm for violating the underlying regulation. The potential impact might include FDA requested recall, FDA mandated recall, warning letter, seizure, injunction, prosecution, civil penalties, and detention. IT System Validation is a key 21CFR Part 11 requirement - its primary benefit is to assure quality and performance of the systems deployed to manage any cGMP process. Empirical evidence states that if a specific process is managed by a validated IT system, it will consistently yield a product that meets its predetermined specifications and quality requirements.

Figure 2: Scope of 21CFR Part 11 Requirements Source: CGE&Y
(Please click on image for enhanced version)

What is IT System Validation?
IT system validation is the process of verifying all the system functions in writing and ensuring that the performance of those functions meets system specifications and data integrity. To successfully manage compliance, each regulated system must be proven to operate in accordance with its intended use and design, and in certain organizations such as those regulated by FDA, all documentation supporting that evidence must be in a form acceptable to the regulatory body upon audit.

The scope of the systems that needs to be validated is based on the regulatory body. For example, in an FDA environment, any software used to automate device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, complaint handling, or to automate any other aspect of the quality system is in scope of validation requirements. In addition, computer systems used to create, modify, and maintain electronic records or systems that maintain certain employee training records are also subject to the FDA validation requirements. Such computer systems must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. Similarly, compliance with Section 404 of the Sarbanes-Oxley Act requires that financial systems used in the preparation of required financial disclosures and statements be controlled and validated to prove the accuracy and timeliness of certain financial data

Framework for System Validation
While various consulting companies have created their own methodologies for systems validation, our experience shows the following framework to be comprehensive and applicable to both off-the-shelf and home grown software solutions. This framework ensures that the software being deployed meets the regulatory requirements and will continue be compliant over time. Key elements of that framework include:

• Compliance with core regulatory requirements: This element requires that the software is audited to be compliant with the key requirements of the regulation.

  For example in FDA regulated industries, the software should comply with the following 21CFR Part 11 requirements:

• Any change to any record is captured in the audit trail and these entries are time stamped with additional information including operator name and why the record was changed.
  
  
• System provides adequate security to prevent unauthorized modification by ensuring role-based access and preventing users from directly updating the database.
  
  
• Software employs electronic signatures for any transaction into the system
  
  

Similarly, HIPAA requires that the information systems that maintain electronic Protected Health Information allow access only to those persons or software programs that have been granted access rights as specified.

• Audit and Validation for intended use: This element requires that the requirement specifications are developed for the intended use of the system. First, the system documentation is audited against the intended use specification to identify any issues. Then the IT system itself is audited using the intended use specification to identify any issues. Major issues need to be corrected using the closed-loop change control method (see lifecycle methodology below) and system needs to be retested before it can be certified to be validated as ready for intended use.
  
  
• Lifecycle Methodology: This element ensures that the software vendor (or IT development organization) that develops the software and the IT organization that implements the software follows a clearly defined and documented software lifecycle methodology to ensure good quality and prevent any software defects that cause non-compliance. The components of the lifecycle include:
  
  
• All system Requirements must be clearly defined before any design or coding effort starts. All system functions must be identified at this stage.
  
  
• System design specification must be clearly documented and design reviews must be done to evaluate the capability of the design to meet system requirements and to identify any problems.
  
  
• Test plans, test procedures and test cases should be developed as early in the development lifecycle as possible.
  
  
• Coding Standards should be well documented and code reviews must be done to ensure that these standards are followed.
  
  
• Multi-level testing methodology including unit test, functional test, integration test and system test must be followed. In addition stress Testing and disaster recovery testing must be performed to ensure that system performance requirements are met.
  
  
• Closed-loop change control: This element ensures that proper change control documentation, approval and testing procedures are followed for any changes including, correcting software defects or adding new capabilities for a new version of the software or making changes to software configuration. Change control procedures must be written and well understood by the developers through adequate training, to ensure compliance. Unauthorized changes to a validated system, even during the implementation process, can have a detrimental affect on the system integrity.
  
  

Figure 3: Mapping of COSO and COBIT for the system lifecycle Source:
IT Control Objectives for Sarbanes Oxley, ISACA
(Please click on image for enhanced version)

• Facility: This element requires that the vendor facilities, as well as, the IT organization be audited to ensure that they employ adequate security controls to prevent unauthorized access to software, computer rooms and backup media storage rooms.
• Organization: This element ensures that the software developers, designers, QA engineers and project managers are trained to perform the technical aspects of their jobs and the company has training policies to ensure they continue to have the right skills on an ongoing basis to do their job. This requirement is specified in the FDA regulations and in the COSO framework.

Organizations that implement this framework find it easier to keep their system validated on an ongoing basis.

Using a QMS system to streamline IT audit and validation process
In a world where technology and business practices are dynamic rather than static, reactive validation methodologies provide questionable value. Best practices call for IT organizations and software vendors to proactively audit their software development and implementation processes on an ongoing basis using the framework defined above and to identify and correct any systemic issues arising from the audit. In order to streamline and automate the entire IT audit and corrective action process, industry leaders are deploying Quality Management Systems (QMS) within their IT/development organizations.

The QMS system serves as a system-of-record for the IT systems validation project. All documents including functional requirements, system specifications and test plans are stored in its repository. The QMS audit capabilities are used to create and track an audit checklist and its results. Once issues have been identified through the internal audit process, the first step is to initiate an investigation and to properly identify the root cause of the problem. After the root cause has been identified, Corrective Action (CAPA) items are created. When corrective actions are approved, appropriate changes are implemented in the environment through a change-control process and then the CAPA is closed out. These changes may include amendments to a documented procedure/SOP or creating a new documented procedure/SOP when one is lacking, or placing controls to ensure that the documented process is followed, or upgrading the skill set of an employee through a training and certification process. Its dashboard provides IT and regulatory compliance executives an ongoing view into the status of the validation process. By using QMS, companies ensure that the ongoing and proactive audit and corrective action process is systematized and provides the basis for lowering the cost of compliance.

In summary, system validation is not a onetime project – it is an ongoing process. Through a combination of a good implementation of system development lifecycle, proactive auditing of the software development and implementation process and automation of the audit and corrective action process, companies can easily comply with the system validation requirements of regulations such as 21CFR part 11, Sarbanes-Oxley or HIPAA etc. at a lower cost of compliance.

About MetricStream
MetricStream is a market leader in Enterprise-wide Compliance and Quality Management software for global corporations. MetricStream solutions are used by leading corporations in diverse industries such as Automotive, Food, Pharmaceuticals, Manufacturing and Electronics for regulatory and industry-mandated compliance and corporate governance initiatives. MetricStream is headquartered in Redwood Shores, California and can be reached at www.metricstream.com.

Please send feedback on this paper or ideas for additional research topics to the author at agupta@metricstream.com