LII:Health Insurance Portability and Accountability Act audit guidelines and checklist

2013-05-22T03:08:41Z

Jleecbd: Remove group health plan component

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with the [[Health Insurance Portability and Accountability Act]] and a variety of other regulatory guidelines.

The following checklist is focused largely on computerized systems that house Protected Health Information (PHI) under the HIPAA regulations. However, since the computerized system exists as part of a complete operation, even when it is hosted by a Cloud provider, the checklist covers the majority of the regulation. This notion of the requirements of the entire regulation applying even to Cloud companies is particularly underscored with the HITECH modifications to the HIPAA regulations where Business Associates are now entirely responsible with adherence to the HIPAA privacy regulations and not merely on a contractual basis.

==Administrative safeguards==

====Security Management Process====

*Does a detailed risk assessment exist regarding potential vulnerabilities to the confidentiality, integrity, and availability of PHI?
*Does the assessment identify actions to mitigate certain risks? Have these actions been taken, or have plans been generated to take these actions?
*Does a policy exist specifying sanctions to be taken against employees who fail to comply with security policies and procedures?
*Is there a system in place for regular review of system activity, including things such as audit logs and incident reports?

====Assigned security responsibility====

*Is there a formally identified individual who is responsible for developing and implementing security policies?
*Has this individual, or the individual's direct reports, developed and implemented security policies?
*Collect evidence of security policies being implemented (group policy reports for the AD server, for instance)

====Workforce security and Information Access Management====

*Do procedures exist governing access to PHI by employees?
*Are employees who should not have access to PHI prevented from accessing it?
*If employees are permitted to access systems that contain PHI, but are not permitted to access PHI, does the system have suitable controls to prevent that access?
*View system accesses by both individuals who have access to PHI and those who don't, and evaluate potential areas of weakness in the security measures.
*Do processes exist for authorizing access to PHI? Do these processes seem reasonable.
*Are employees who have access to PHI supervised appropriately? Do their supervisors have adequate training and understanding regarding the treatment of PHI?
*Are adequate procedures in place governing the termination of employees with access to PHI?
*Do these procedures include appropriately times termination of accounts (i.e., in the case of involuntary termination, is the account terminated before the employee might have the opportunity to cause harm?).
*For voluntary terminations, are procedures in place that require the supervisor to evaluate the need for continued access to PHI prior to the departure of the employee in question?
*Is there a clear requirement for communication with system administrators and IT staff regarding affected accounts?
*If a health clearinghouse is part of a larger organization, confirm that adequate controls exist that prevent the larger organization from accessing PHI.
*Do the PHI access procedures apply to the IT/IS organization? That is, is access to PHI only allowed for IT/IS employees with a legitimate business reason to access that data? Are IT/IS employees adequately trained in the HIPAA regulations, internal policies and procedures regarding PHI?

====Security Awareness and Training====
*Is there a formal and documented training program for employees who deal with PHI?
*Are employees provided training on principles of security?
*Are there procedures in place for addressing malicious software, including it's detection and reporting? Are employees prevented from accessing remote sites that are at high risk for containing malicious software?
*Is there a system for ensuring that security protection software (in particular anti-virus programs, and firewalls) are updated periodically?
*For outward facing applications, is there a process by which security flaws in components (such as Java) are identified and fixed.
*For systems that provide access to PHI, do they track log-ins, and in particular failed logins?
*Does the system lock out users after a specified number of failed logins?
*Are system administrators notified if such an event occurs?
*Is there evidence that administrators respond to such events in an appropriate manner?
*Are there policies governing password complexity, change and reuse frequency? Are the policies consistent with current "standards" within the industry?
*Are employees trained to maintain strict secrecy regarding their passwords?
*Are there procedures mandating that IT may not request passwords from users?

====Security Incident Procedures====

*Are procedures in place for responding to security incidents?
*Is there evidence that these procedures are being followed (review any logs/files regarding actions taken in response to security incidents).

====Contingency Plan====

*Does the organization have a comprehensive disaster preparedness/business continuity plan?
*Does the plan included a backup and recovery procedure for all system data?
*Does the plan adequately address how operations can be continued under various scenarios?
*Does the plan include procedures for testing the various elements of the plan to ensure they are still valid?
*Does the plan address the criticality of the various systems in its design?

====Evaluation====

*Is a periodic re-evaluation of security standards undertaken?
*Does the re-evaluation take into account changes in the current state of IT security and the environment of threats facing secured systems, as well as the current state of the regulations?

====Business Associate Agreements====

*If components of the system are held outside the direct control of the company, such that PHI will be outside of the direct control of the company, do sufficient agreements exist to guarantee that the party responsible for handling the PHI will adhere to the requirements of the regulation?
*Are these agreements in such a form that they qualify as a contract or equivalent?

==Physical safeguards==

====Facility Access Controls====
*Is the facility containing the system (this includes electronic access points that connect to the system in a "non-secure" manner) sufficiently protected from unauthorized access?
*Is access to application and database servers further restricted to only those personnel who are authorized to directly interact with those elements of the system (i.e., system administrators).
*Is there a system that limits access to facilities and areas within facilities to authorized personnel? Does this system implement a mechanism for confirming the identify of individuals accessing the facility (e.g., through a electronic key access system)
*Does this system apply to visitors as well?
*Is access to systems used for testing and revision of software similarly restricted? Evaluate the access restrictions to tools that could be used to modify and deploy the software. Ensure that these access restrictions are addressed via SOP.

====Workstation Use====

*Do procedures exist which govern the class of workstation that can be used to access PHI?

====Workstation Security====

*Are workstations that are used to access PHI appropriately restricted?
*If workstations can directly interact with PHI without additional controls, are the workstations secured in appropriately restricted areas?

====Device and Media Controls====

*Are procedures in place governing the use and removal of hardware and storage media used to house PHI?
*Do the procedures seem reasonable?
*Do procedures exist regarding the disposal of media and devices used to store PHI?
*Are records maintained that account for the movement of such media, and who moved it?

==Technical safeguards==

====Access Control====

*Do systems with access to PHI have a robust authentication process for gaining access?
*Do these system require that all users have a unique id?
*Are password assignment, change, recovery, and related processes designed in such a way so as to ensure that the user gaining access to PHI is who they say they are?
*Is there a mechanism for gaining access to necessary PHI in the event of an emergency? Is this mechanism designed such that it's invocation during non-emergencies would not be achievable in a non-obvious way?
*Does this system automatically log off users after a defined period of inactivity?
*Does the system maintain PHI in an encrypted state?

====Audit Controls====

*Do systems used for PHI maintain audit trails which record, in a secure manner, all activities within the system. Are the audit trails reviewed periodically?

====Integrity====

*Are policies and procedures in place to ensure that PHI has not been altered or destroyed in an unauthorized manner?
*Are electronic mechanisms employed to corroborate that PHI has not been altered or destroyed in an unauthorized manner?*
*If PHI is transmitted outside of the responsible entity (i.e., via the internet), is the data transmitted in such a way so as to prevent unauthorized access (via ssl or similar protocols?)
*Are security certificates on servers involved in managing PHI current, and authenticated by a recognized third party certifying organization?

==Organizational requirements==

====Business associate contracts====

*Are business associates required contractually to adhere to the regulations with regard to PHI they maintain?
*Do business associate agreements exist with third party data/application hosting services?
*Do business associate agreements extend, contractually, to agents/subcontractors?
*Is it clear within the terms of the business associate agreements that the business associate must immediately report any breaches or incidents?
*Is it clear within the terms of the business associate agreements that the relationship can be terminated if the associate fails to comply with the requirements of the regulations?
*Do records exist of audits and other reviews of business associates? If breeches or violations of the regulation have occurred, have appropriate actions been taken, up to and including termination of the agreement?

==Documentation requirements==

====Documentation====

*Are the procedures required by the regulations maintained in written (or alternatively electronic, but signed) form?
*Are actions and activities which are required to be documented maintained in written form (or electronic alternatives)?
*Is there a retention policy regarding the policies and procedures? Does the policy require that such documents be maintained for at least 6 years after either the date of its creation or of its effective date (whichever is later)?
*Does a review system exist for these policies and procedures to ensure that they are current?

LII:Health Insurance Portability and Accountability Act audit guidelines and checklist

2013-05-22T03:03:13Z

Jleecbd: /* Security Awareness and Training */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with the [[Health Insurance Portability and Accountability Act]] and a variety of other regulatory guidelines.

The following checklist is focused largely on computerized systems that house Protected Health Information (PHI) under the HIPAA regulations. However, since the computerized system exists as part of a complete operation, even when it is hosted by a Cloud provider, the checklist covers the majority of the regulation. This notion of the requirements of the entire regulation applying even to Cloud companies is particularly underscored with the HITECH modifications to the HIPAA regulations where Business Associates are now entirely responsible with adherence to the HIPAA privacy regulations and not merely on a contractual basis.

==Administrative safeguards==

====Security Management Process====

*Does a detailed risk assessment exist regarding potential vulnerabilities to the confidentiality, integrity, and availability of PHI?
*Does the assessment identify actions to mitigate certain risks? Have these actions been taken, or have plans been generated to take these actions?
*Does a policy exist specifying sanctions to be taken against employees who fail to comply with security policies and procedures?
*Is there a system in place for regular review of system activity, including things such as audit logs and incident reports?

====Assigned security responsibility====

*Is there a formally identified individual who is responsible for developing and implementing security policies?
*Has this individual, or the individual's direct reports, developed and implemented security policies?
*Collect evidence of security policies being implemented (group policy reports for the AD server, for instance)

====Workforce security and Information Access Management====

*Do procedures exist governing access to PHI by employees?
*Are employees who should not have access to PHI prevented from accessing it?
*If employees are permitted to access systems that contain PHI, but are not permitted to access PHI, does the system have suitable controls to prevent that access?
*View system accesses by both individuals who have access to PHI and those who don't, and evaluate potential areas of weakness in the security measures.
*Do processes exist for authorizing access to PHI? Do these processes seem reasonable.
*Are employees who have access to PHI supervised appropriately? Do their supervisors have adequate training and understanding regarding the treatment of PHI?
*Are adequate procedures in place governing the termination of employees with access to PHI?
*Do these procedures include appropriately times termination of accounts (i.e., in the case of involuntary termination, is the account terminated before the employee might have the opportunity to cause harm?).
*For voluntary terminations, are procedures in place that require the supervisor to evaluate the need for continued access to PHI prior to the departure of the employee in question?
*Is there a clear requirement for communication with system administrators and IT staff regarding affected accounts?
*If a health clearinghouse is part of a larger organization, confirm that adequate controls exist that prevent the larger organization from accessing PHI.
*Do the PHI access procedures apply to the IT/IS organization? That is, is access to PHI only allowed for IT/IS employees with a legitimate business reason to access that data? Are IT/IS employees adequately trained in the HIPAA regulations, internal policies and procedures regarding PHI?

====Security Awareness and Training====
*Is there a formal and documented training program for employees who deal with PHI?
*Are employees provided training on principles of security?
*Are there procedures in place for addressing malicious software, including it's detection and reporting? Are employees prevented from accessing remote sites that are at high risk for containing malicious software?
*Is there a system for ensuring that security protection software (in particular anti-virus programs, and firewalls) are updated periodically?
*For outward facing applications, is there a process by which security flaws in components (such as Java) are identified and fixed.
*For systems that provide access to PHI, do they track log-ins, and in particular failed logins?
*Does the system lock out users after a specified number of failed logins?
*Are system administrators notified if such an event occurs?
*Is there evidence that administrators respond to such events in an appropriate manner?
*Are there policies governing password complexity, change and reuse frequency? Are the policies consistent with current "standards" within the industry?
*Are employees trained to maintain strict secrecy regarding their passwords?
*Are there procedures mandating that IT may not request passwords from users?

====Security Incident Procedures====

*Are procedures in place for responding to security incidents?
*Is there evidence that these procedures are being followed (review any logs/files regarding actions taken in response to security incidents).

====Contingency Plan====

*Does the organization have a comprehensive disaster preparedness/business continuity plan?
*Does the plan included a backup and recovery procedure for all system data?
*Does the plan adequately address how operations can be continued under various scenarios?
*Does the plan include procedures for testing the various elements of the plan to ensure they are still valid?
*Does the plan address the criticality of the various systems in its design?

====Evaluation====

*Is a periodic re-evaluation of security standards undertaken?
*Does the re-evaluation take into account changes in the current state of IT security and the environment of threats facing secured systems, as well as the current state of the regulations?

====Business Associate Agreements====

*If components of the system are held outside the direct control of the company, such that PHI will be outside of the direct control of the company, do sufficient agreements exist to guarantee that the party responsible for handling the PHI will adhere to the requirements of the regulation?
*Are these agreements in such a form that they qualify as a contract or equivalent?

==Physical safeguards==

====Facility Access Controls====
*Is the facility containing the system (this includes electronic access points that connect to the system in a "non-secure" manner) sufficiently protected from unauthorized access?
*Is access to application and database servers further restricted to only those personnel who are authorized to directly interact with those elements of the system (i.e., system administrators).
*Is there a system that limits access to facilities and areas within facilities to authorized personnel? Does this system implement a mechanism for confirming the identify of individuals accessing the facility (e.g., through a electronic key access system)
*Does this system apply to visitors as well?
*Is access to systems used for testing and revision of software similarly restricted? Evaluate the access restrictions to tools that could be used to modify and deploy the software. Ensure that these access restrictions are addressed via SOP.

====Workstation Use====

*Do procedures exist which govern the class of workstation that can be used to access PHI?

====Workstation Security====

*Are workstations that are used to access PHI appropriately restricted?
*If workstations can directly interact with PHI without additional controls, are the workstations secured in appropriately restricted areas?

====Device and Media Controls====

*Are procedures in place governing the use and removal of hardware and storage media used to house PHI?
*Do the procedures seem reasonable?
*Do procedures exist regarding the disposal of media and devices used to store PHI?
*Are records maintained that account for the movement of such media, and who moved it?

==Technical safeguards==

====Access Control====

*Do systems with access to PHI have a robust authentication process for gaining access?
*Do these system require that all users have a unique id?
*Are password assignment, change, recovery, and related processes designed in such a way so as to ensure that the user gaining access to PHI is who they say they are?
*Is there a mechanism for gaining access to necessary PHI in the event of an emergency? Is this mechanism designed such that it's invocation during non-emergencies would not be achievable in a non-obvious way?
*Does this system automatically log off users after a defined period of inactivity?
*Does the system maintain PHI in an encrypted state?

====Audit Controls====

*Do systems used for PHI maintain audit trails which record, in a secure manner, all activities within the system. Are the audit trails reviewed periodically?

====Integrity====

*Are policies and procedures in place to ensure that PHI has not been altered or destroyed in an unauthorized manner?
*Are electronic mechanisms employed to corroborate that PHI has not been altered or destroyed in an unauthorized manner?*
*If PHI is transmitted outside of the responsible entity (i.e., via the internet), is the data transmitted in such a way so as to prevent unauthorized access (via ssl or similar protocols?)
*Are security certificates on servers involved in managing PHI current, and authenticated by a recognized third party certifying organization?

==Organizational requirements==

====Business associate contracts====

*Are business associates required contractually to adhere to the regulations with regard to PHI they maintain?
*Do business associate agreements exist with third party data/application hosting services?
*Do business associate agreements extend, contractually, to agents/subcontractors?
*Is it clear within the terms of the business associate agreements that the business associate must immediately report any breaches or incidents?
*Is it clear within the terms of the business associate agreements that the relationship can be terminated if the associate fails to comply with the requirements of the regulations?
*Do records exist of audits and other reviews of business associates? If breeches or violations of the regulation have occurred, have appropriate actions been taken, up to and including termination of the agreement?

====Requirements for group health plans====

*Have group health plans amended their plans to reflect the need to comply with the regulation with regard to PHI?

==Documentation requirements==

====Documentation====

*Are the procedures required by the regulations maintained in written (or alternatively electronic, but signed) form?
*Are actions and activities which are required to be documented maintained in written form (or electronic alternatives)?
*Is there a retention policy regarding the policies and procedures? Does the policy require that such documents be maintained for at least 6 years after either the date of its creation or of its effective date (whichever is later)?
*Does a review system exist for these policies and procedures to ensure that they are current?

LII:Health Insurance Portability and Accountability Act audit guidelines and checklist

2013-05-22T03:01:18Z

Jleecbd:

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with the [[Health Insurance Portability and Accountability Act]] and a variety of other regulatory guidelines.

The following checklist is focused largely on computerized systems that house Protected Health Information (PHI) under the HIPAA regulations. However, since the computerized system exists as part of a complete operation, even when it is hosted by a Cloud provider, the checklist covers the majority of the regulation. This notion of the requirements of the entire regulation applying even to Cloud companies is particularly underscored with the HITECH modifications to the HIPAA regulations where Business Associates are now entirely responsible with adherence to the HIPAA privacy regulations and not merely on a contractual basis.

==Administrative safeguards==

====Security Management Process====

*Does a detailed risk assessment exist regarding potential vulnerabilities to the confidentiality, integrity, and availability of PHI?
*Does the assessment identify actions to mitigate certain risks? Have these actions been taken, or have plans been generated to take these actions?
*Does a policy exist specifying sanctions to be taken against employees who fail to comply with security policies and procedures?
*Is there a system in place for regular review of system activity, including things such as audit logs and incident reports?

====Assigned security responsibility====

*Is there a formally identified individual who is responsible for developing and implementing security policies?
*Has this individual, or the individual's direct reports, developed and implemented security policies?
*Collect evidence of security policies being implemented (group policy reports for the AD server, for instance)

====Workforce security and Information Access Management====

*Do procedures exist governing access to PHI by employees?
*Are employees who should not have access to PHI prevented from accessing it?
*If employees are permitted to access systems that contain PHI, but are not permitted to access PHI, does the system have suitable controls to prevent that access?
*View system accesses by both individuals who have access to PHI and those who don't, and evaluate potential areas of weakness in the security measures.
*Do processes exist for authorizing access to PHI? Do these processes seem reasonable.
*Are employees who have access to PHI supervised appropriately? Do their supervisors have adequate training and understanding regarding the treatment of PHI?
*Are adequate procedures in place governing the termination of employees with access to PHI?
*Do these procedures include appropriately times termination of accounts (i.e., in the case of involuntary termination, is the account terminated before the employee might have the opportunity to cause harm?).
*For voluntary terminations, are procedures in place that require the supervisor to evaluate the need for continued access to PHI prior to the departure of the employee in question?
*Is there a clear requirement for communication with system administrators and IT staff regarding affected accounts?
*If a health clearinghouse is part of a larger organization, confirm that adequate controls exist that prevent the larger organization from accessing PHI.
*Do the PHI access procedures apply to the IT/IS organization? That is, is access to PHI only allowed for IT/IS employees with a legitimate business reason to access that data? Are IT/IS employees adequately trained in the HIPAA regulations, internal policies and procedures regarding PHI?

====Security Awareness and Training====
*Is there a formal and documented training program for employees who deal with PHI?
*Are employees provided training on principles of security?
*Are there procedures in place for addressing malicious software, including it's detection and reporting? Are employees prevented from accessing remote sites that are at high risk for containing malicious software?
*Is there a system for ensuring that security protection software (in particular anti-virus programs, and firewalls) are updated periodically?
*For outward facing applications, is there a process by which security flaws in components (such as Java) are identified and fixed.
*For systems that provide access to PHI, do they track log-ins, and in particular failed logins?
*Does the system lock out users after a specified number of failed lockouts?
*Are system administrators notified if such an event occurs?
*Is there evidence that administrators respond to such events in an appropriate manner?
*Are there policies governing password complexity, change and reuse frequency? Are the policies consistent with current "standards" within the industry?
*Are employees trained to maintain strict secrecy regarding their passwords?
*Are there procedures mandating that IT may not request passwords from users?

====Security Incident Procedures====

*Are procedures in place for responding to security incidents?
*Is there evidence that these procedures are being followed (review any logs/files regarding actions taken in response to security incidents).

====Contingency Plan====

*Does the organization have a comprehensive disaster preparedness/business continuity plan?
*Does the plan included a backup and recovery procedure for all system data?
*Does the plan adequately address how operations can be continued under various scenarios?
*Does the plan include procedures for testing the various elements of the plan to ensure they are still valid?
*Does the plan address the criticality of the various systems in its design?

====Evaluation====

*Is a periodic re-evaluation of security standards undertaken?
*Does the re-evaluation take into account changes in the current state of IT security and the environment of threats facing secured systems, as well as the current state of the regulations?

====Business Associate Agreements====

*If components of the system are held outside the direct control of the company, such that PHI will be outside of the direct control of the company, do sufficient agreements exist to guarantee that the party responsible for handling the PHI will adhere to the requirements of the regulation?
*Are these agreements in such a form that they qualify as a contract or equivalent?

==Physical safeguards==

====Facility Access Controls====
*Is the facility containing the system (this includes electronic access points that connect to the system in a "non-secure" manner) sufficiently protected from unauthorized access?
*Is access to application and database servers further restricted to only those personnel who are authorized to directly interact with those elements of the system (i.e., system administrators).
*Is there a system that limits access to facilities and areas within facilities to authorized personnel? Does this system implement a mechanism for confirming the identify of individuals accessing the facility (e.g., through a electronic key access system)
*Does this system apply to visitors as well?
*Is access to systems used for testing and revision of software similarly restricted? Evaluate the access restrictions to tools that could be used to modify and deploy the software. Ensure that these access restrictions are addressed via SOP.

====Workstation Use====

*Do procedures exist which govern the class of workstation that can be used to access PHI?

====Workstation Security====

*Are workstations that are used to access PHI appropriately restricted?
*If workstations can directly interact with PHI without additional controls, are the workstations secured in appropriately restricted areas?

====Device and Media Controls====

*Are procedures in place governing the use and removal of hardware and storage media used to house PHI?
*Do the procedures seem reasonable?
*Do procedures exist regarding the disposal of media and devices used to store PHI?
*Are records maintained that account for the movement of such media, and who moved it?

==Technical safeguards==

====Access Control====

*Do systems with access to PHI have a robust authentication process for gaining access?
*Do these system require that all users have a unique id?
*Are password assignment, change, recovery, and related processes designed in such a way so as to ensure that the user gaining access to PHI is who they say they are?
*Is there a mechanism for gaining access to necessary PHI in the event of an emergency? Is this mechanism designed such that it's invocation during non-emergencies would not be achievable in a non-obvious way?
*Does this system automatically log off users after a defined period of inactivity?
*Does the system maintain PHI in an encrypted state?

====Audit Controls====

*Do systems used for PHI maintain audit trails which record, in a secure manner, all activities within the system. Are the audit trails reviewed periodically?

====Integrity====

*Are policies and procedures in place to ensure that PHI has not been altered or destroyed in an unauthorized manner?
*Are electronic mechanisms employed to corroborate that PHI has not been altered or destroyed in an unauthorized manner?*
*If PHI is transmitted outside of the responsible entity (i.e., via the internet), is the data transmitted in such a way so as to prevent unauthorized access (via ssl or similar protocols?)
*Are security certificates on servers involved in managing PHI current, and authenticated by a recognized third party certifying organization?

==Organizational requirements==

====Business associate contracts====

*Are business associates required contractually to adhere to the regulations with regard to PHI they maintain?
*Do business associate agreements exist with third party data/application hosting services?
*Do business associate agreements extend, contractually, to agents/subcontractors?
*Is it clear within the terms of the business associate agreements that the business associate must immediately report any breaches or incidents?
*Is it clear within the terms of the business associate agreements that the relationship can be terminated if the associate fails to comply with the requirements of the regulations?
*Do records exist of audits and other reviews of business associates? If breeches or violations of the regulation have occurred, have appropriate actions been taken, up to and including termination of the agreement?

====Requirements for group health plans====

*Have group health plans amended their plans to reflect the need to comply with the regulation with regard to PHI?

==Documentation requirements==

====Documentation====

*Are the procedures required by the regulations maintained in written (or alternatively electronic, but signed) form?
*Are actions and activities which are required to be documented maintained in written form (or electronic alternatives)?
*Is there a retention policy regarding the policies and procedures? Does the policy require that such documents be maintained for at least 6 years after either the date of its creation or of its effective date (whichever is later)?
*Does a review system exist for these policies and procedures to ensure that they are current?

LII:Health Insurance Portability and Accountability Act audit guidelines and checklist

2013-05-22T02:55:45Z

Jleecbd: First upload checklist

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with the [[Health Insurance Portability and Accountability Act]] and a variety of other regulatory guidelines.

==Administrative safeguards==

====Security Management Process====

*Does a detailed risk assessment exist regarding potential vulnerabilities to the confidentiality, integrity, and availability of PHI?
*Does the assessment identify actions to mitigate certain risks? Have these actions been taken, or have plans been generated to take these actions?
*Does a policy exist specifying sanctions to be taken against employees who fail to comply with security policies and procedures? 164.308(1)(ii)(C)
*Is there a system in place for regular review of system activity, including things such as audit logs and incident reports?

====Assigned security responsibility====

*Is there a formally identified individual who is responsible for developing and implementing security policies?
*Has this individual, or the individual's direct reports, developed and implemented security policies?
*Collect evidence of security policies being implemented (group policy reports for the AD server, for instance)

====Workforce security and Information Access Management====

*Do procedures exist governing access to PHI by employees?
*Are employees who should not have access to PHI prevented from accessing it?
*If employees are permitted to access systems that contain PHI, but are not permitted to access PHI, does the system have suitable controls to prevent that access?
*View system accesses by both individuals who have access to PHI and those who don't, and evaluate potential areas of weakness in the security measures.
*Do processes exist for authorizing access to PHI? Do these processes seem reasonable.
*Are employees who have access to PHI supervised appropriately? Do their supervisors have adequate training and understanding regarding the treatment of PHI?
*Are adequate procedures in place governing the termination of employees with access to PHI?
*Do these procedures include appropriately times termination of accounts (i.e., in the case of involuntary termination, is the account terminated before the employee might have the opportunity to cause harm?).
*For voluntary terminations, are procedures in place that require the supervisor to evaluate the need for continued access to PHI prior to the departure of the employee in question?
*Is there a clear requirement for communication with system administrators and IT staff regarding affected accounts?
*If a health clearinghouse is part of a larger organization, confirm that adequate controls exist that prevent the larger organization from accessing PHI.
*Do the PHI access procedures apply to the IT/IS organization? That is, is access to PHI only allowed for IT/IS employees with a legitimate business reason to access that data? Are IT/IS employees adequately trained in the HIPAA regulations, internal policies and procedures regarding PHI?

====Security Awareness and Training====
*Is there a formal and documented training program for employees who deal with PHI?
*Are employees provided training on principles of security?
*Are there procedures in place for addressing malicious software, including it's detection and reporting? Are employees prevented from accessing remote sites that are at high risk for containing malicious software?
*Is there a system for ensuring that security protection software (in particular anti-virus programs, and firewalls) are updated periodically?
*For outward facing applications, is there a process by which security flaws in components (such as Java) are identified and fixed.
*For systems that provide access to PHI, do they track log-ins, and in particular failed logins?
*Does the system lock out users after a specified number of failed lockouts?
*Are system administrators notified if such an event occurs?
*Is there evidence that administrators respond to such events in an appropriate manner?
*Are there policies governing password complexity, change and reuse frequency? Are the policies consistent with current "standards" within the industry?
*Are employees trained to maintain strict secrecy regarding their passwords?
*Are there procedures mandating that IT may not request passwords from users?

====Security Incident Procedures====

*Are procedures in place for responding to security incidents?
*Is there evidence that these procedures are being followed (review any logs/files regarding actions taken in response to security incidents).

====Contingency Plan====

*Does the organization have a comprehensive disaster preparedness/business continuity plan?
*Does the plan included a backup and recovery procedure for all system data?
*Does the plan adequately address how operations can be continued under various scenarios?
*Does the plan include procedures for testing the various elements of the plan to ensure they are still valid?
*Does the plan address the criticality of the various systems in its design?

====Evaluation====

*Is a periodic re-evaluation of security standards undertaken?
*Does the re-evaluation take into account changes in the current state of IT security and the environment of threats facing secured systems, as well as the current state of the regulations?

====Business Associate Agreements====

*If components of the system are held outside the direct control of the company, such that PHI will be outside of the direct control of the company, do sufficient agreements exist to guarantee that the party responsible for handling the PHI will adhere to the requirements of the regulation?
*Are these agreements in such a form that they qualify as a contract or equivalent?

==Physical safeguards==

====Facility Access Controls====
*Is the facility containing the system (this includes electronic access points that connect to the system in a "non-secure" manner) sufficiently protected from unauthorized access?
*Is access to application and database servers further restricted to only those personnel who are authorized to directly interact with those elements of the system (i.e., system administrators).
*Is there a system that limits access to facilities and areas within facilities to authorized personnel? Does this system implement a mechanism for confirming the identify of individuals accessing the facility (e.g., through a electronic key access system)
*Does this system apply to visitors as well?
*Is access to systems used for testing and revision of software similarly restricted? Evaluate the access restrictions to tools that could be used to modify and deploy the software. Ensure that these access restrictions are addressed via SOP.

====Workstation Use====

*Do procedures exist which govern the class of workstation that can be used to access PHI?

====Workstation Security====

*Are workstations that are used to access PHI appropriately restricted?
*If workstations can directly interact with PHI without additional controls, are the workstations secured in appropriately restricted areas?

====Device and Media Controls====

*Are procedures in place governing the use and removal of hardware and storage media used to house PHI?
*Do the procedures seem reasonable?
*Do procedures exist regarding the disposal of media and devices used to store PHI?
*Are records maintained that account for the movement of such media, and who moved it?

==Technical safeguards==

====Access Control====

*Do systems with access to PHI have a robust authentication process for gaining access?
*Do these system require that all users have a unique id?
*Are password assignment, change, recovery, and related processes designed in such a way so as to ensure that the user gaining access to PHI is who they say they are?
*Is there a mechanism for gaining access to necessary PHI in the event of an emergency? Is this mechanism designed such that it's invocation during non-emergencies would not be achievable in a non-obvious way?
*Does this system automatically log off users after a defined period of inactivity?
*Does the system maintain PHI in an encrypted state?

====Audit Controls====

*Do systems used for PHI maintain audit trails which record, in a secure manner, all activities within the system. Are the audit trails reviewed periodically?

====Integrity====

*Are policies and procedures in place to ensure that PHI has not been altered or destroyed in an unauthorized manner?
*Are electronic mechanisms employed to corroborate that PHI has not been altered or destroyed in an unauthorized manner?*
*If PHI is transmitted outside of the responsible entity (i.e., via the internet), is the data transmitted in such a way so as to prevent unauthorized access (via ssl or similar protocols?)
*Are security certificates on servers involved in managing PHI current, and authenticated by a recognized third party certifying organization?

==Organizational requirements==

====Business associate contracts====

*Are business associates required contractually to adhere to the regulations with regard to PHI they maintain?
*Do business associate agreements exist with third party data/application hosting services?
*Do business associate agreements extend, contractually, to agents/subcontractors?
*Is it clear within the terms of the business associate agreements that the business associate must immediately report any breaches or incidents?
*Is it clear within the terms of the business associate agreements that the relationship can be terminated if the associate fails to comply with the requirements of the regulations?
*Do records exist of audits and other reviews of business associates? If breeches or violations of the regulation have occurred, have appropriate actions been taken, up to and including termination of the agreement?

====Requirements for group health plans====

*Have group health plans amended their plans to reflect the need to comply with the regulation with regard to PHI?

==Documentation requirements==

====Documentation====

*Are the procedures required by the regulations maintained in written (or alternatively electronic, but signed) form?
*Are actions and activities which are required to be documented maintained in written form (or electronic alternatives)?
*Is there a retention policy regarding the policies and procedures? Does the policy require that such documents be maintained for at least 6 years after either the date of its creation or of its effective date (whichever is later)?
*Does a review system exist for these policies and procedures to ensure that they are current?

LII:Health Insurance Portability and Accountability Act audit guidelines and checklist

2013-05-22T02:39:49Z

Jleecbd:

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with the [[Health Insurance Portability and Accountability Act]] and a variety of other regulatory guidelines.

==Administrative safeguards==

===Security Management Process===

*Does a detailed risk assessment exist regarding potential vulnerabilities to the confidentiality, integrity, and availability of PHI? 164.308(1)(ii)(A)
*Does the assessment identify actions to mitigate certain risks? Have these actions been taken, or have plans been generated to take these actions? 164.308(1)(ii)(B)
*Does a policy exist specifying sanctions to be taken against employees who fail to comply with security policies and procedures? 164.308(1)(ii)(C)
*Is there a system in place for regular review of system activity, including things such as audit logs and incident reports?

Assigned security responsibility

Is there a formally identified individual who is responsible for developing and implementing security policies?
Has this individual, or the individual's direct reports, developed and implemented security policies?
Collect evidence of security policies being implemented (group policy reports for the AD server, for instance)

Workforce security and Information Access Management

Do procedures exist governing access to PHI by employees?
Are employees who should not have access to PHI prevented from accessing it?
If employees are permitted to access systems that contain PHI, but are not permitted to access PHI, does the system have suitable controls to prevent that access?
View system accesses by both individuals who have access to PHI and those who don't, and evaluate potential areas of weakness in the security measures.
Do processes exist for authorizing access to PHI? Do these processes seem reasonable.
Are employees who have access to PHI supervised appropriately? Do their supervisors have adequate training and understanding regarding the treatment of PHI?
Are adequate procedures in place governing the termination of employees with access to PHI?
Do these procedures include appropriately times termination of accounts (i.e., in the case of involuntary termination, is the account terminated before the employee might have the opportunity to cause harm?).
For voluntary terminations, are procedures in place that require the supervisor to evaluate the need for continued access to PHI prior to the departure of the employee in question?
Is there a clear requirement for communication with system administrators and IT staff regarding affected accounts?
If a health clearinghouse is part of a larger organization, confirm that adequate controls exist that prevent the larger organization from accessing PHI.
Do the PHI access procedures apply to the IT/IS organization? That is, is access to PHI only allowed for IT/IS employees with a legitimate business reason to access that data? Are IT/IS employees adequately trained in the HIPAA regulations, internal policies and procedures regarding PHI?

Security Awareness and Training
Is there a formal and documented training program for employees who deal with PHI?
Are employees provided training on principles of security?
Are there procedures in place for addressing malicious software, including it's detection and reporting? Are employees prevented from accessing remote sites that are at high risk for containing malicious software?
Is there a system for ensuring that security protection software (in particular anti-virus programs, and firewalls) are updated periodically?
For outward facing applications, is there a process by which security flaws in components (such as Java) are identified and fixed.
For systems that provide access to PHI, do they track log-ins, and in particular failed logins?
Does the system lock out users after a specified number of failed lockouts?
Are system administrators notified if such an event occurs?
Is there evidence that administrators respond to such events in an appropriate manner?
Are there policies governing password complexity, change and reuse frequency? Are the policies consistent with current "standards" within the industry?
Are employees trained to maintain strict secrecy regarding their passwords?
Are there procedures mandating that IT may not request passwords from users?

Security Incident Procedures

Are procedures in place for responding to security incidents?
Is there evidence that these procedures are being followed (review any logs/files regarding actions taken in response to security incidents).

Contingency Plan

Does the organization have a comprehensive disaster preparedness/business continuity plan?
Does the plan included a backup and recovery procedure for all system data?
Does the plan adequately address how operations can be continued under various scenarios?
Does the plan include procedures for testing the various elements of the plan to ensure they are still valid?
Does the plan address the criticality of the various systems in its design?

Evaluation

Is a periodic re-evaluation of security standards undertaken?
Does the re-evaluation take into account changes in the current state of IT security and the environment of threats facing secured systems, as well as the current state of the regulations?

Business Associate Agreements

If components of the system are held outside the direct control of the company, such that PHI will be outside of the direct control of the company, do sufficient agreements exist to guarantee that the party responsible for handling the PHI will adhere to the requirements of the regulation? (note exceptions)
Are these agreements in such a form that they qualify as a contract or equivalent?

Physical safeguards:

Facility Access Controls
Is the facility containing the system (this includes electronic access points that connect to the system in a "non-secure" manner) sufficiently protected from unauthorized access?
Is access to application and database servers further restricted to only those personnel who are authorized to directly interact with those elements of the system (i.e., system administrators).
Is there a system that limits access to facilities and areas within facilities to authorized personnel? Does this system implement a mechanism for confirming the identify of individuals accessing the facility (e.g., through a electronic key access system)
Does this system apply to visitors as well?
Is access to systems used for testing and revision of software similarly restricted? Evaluate the access restrictions to tools that could be used to modify and deploy the software. Ensure that these access restrictions are addressed via SOP.

Workstation Use

Do procedures exist which govern the class of workstation that can be used to access PHI?

Workstation Security

Are workstations that are used to access PHI appropriately restricted?
If workstations can directly interact with PHI without additional controls, are the workstations secured in appropriately restricted areas?

Device and Media Controls

Are procedures in place governing the use and removal of hardware and storage media used to house PHI?
Do the procedures seem reasonable?
Do procedures exist regarding the disposal of media and devices used to store PHI?
Are records maintained that account for the movement of such media, and who moved it?

Technical safeguards:

Access Control

Do systems with access to PHI have a robust authentication process for gaining access?
Do these system require that all users have a unique id?
Are password assignment, change, recovery, and related processes designed in such a way so as to ensure that the user gaining access to PHI is who they say they are?
Is there a mechanism for gaining access to necessary PHI in the event of an emergency? Is this mechanism designed such that it's invocation during non-emergencies would not be achievable in a non-obvious way?
Does this system automatically log off users after a defined period of inactivity?
Does the system maintain PHI in an encrypted state?

Audit Controls

Do systems used for PHI maintain audit trails which record, in a secure manner, all activities within the system. Are the audit trails reviewed periodically?

Integrity

Are policies and procedures in place to ensure that PHI has not been altered or destroyed in an unauthorized manner?
Are electronic mechanisms employed to corroborate that PHI has not been altered or destroyed in an unauthorized manner?
If PHI is transmitted outside of the responsible entity (i.e., via the internet), is the data transmitted in such a way so as to prevent unauthorized access (via ssl or similar protocols?)
Are security certificates on servers involved in managing PHI current, and authenticated by a recognized third party certifying organization?

Organizational requirements

Business associate contracts

- Are business associates required contractually to adhere to the regulations with regard to PHI they maintain?
Do business associate agreements exist with third party data/application hosting services?
Do business associate agreements extend, contractually, to agents/subcontractors?
Is it clear within the terms of the business associate agreements that the business associate must immediately report any breaches or incidents?
Is it clear within the terms of the business associate agreements that the relationship can be terminated if the associate fails to comply with the requirements of the regulations?
Do records exist of audits and other reviews of business associates? If breeches or violations of the regulation have occurred, have appropriate actions been taken, up to and including termination of the agreement?

Requirements for group health plans

- Have group health plans amended their plans to reflect the need to comply with the regulation with regard to PHI?

Documentation requirements

Documentation

Are the procedures required by the regulations maintained in written (or alternatively electronic, but signed) form?
Are actions and activities which are required to be documented maintained in written form (or electronic alternatives)?
Is there a retention policy regarding the policies and procedures? Does the policy require that such documents be maintained for at least 6 years after either the date of its creation or of its effective date (whichever is later)?
Does a review system exist for these policies and procedures to ensure that they are current?

21 CFR Part 11/Audit guidelines and checklist

2013-04-20T06:41:52Z

Jleecbd: /* Process Controls */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls<ref>The field of IT security has exploded in recent years with a number of high profile breaches. At the time of the writing of Part 11, the internet was much safer in this regard than it is today. The auditor should focus significant effort on security around all systems, but especially open systems.</ref>===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured? [[#21 CFR Part 11|21 CFR 11.30]]
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to? - [[#21 CFR Part 11|21 CFR 11.70]]
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls). - [[#21 CFR Part 11|21 CFR 11.200(a)(3)]]
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access? - [[#21 CFR Part 11|21 CFR 11.200(a)(1)(i)]]
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)? - [[#21 CFR Part 11|21 CFR 11.300(c)]]
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts? - [[#21 CFR Part 11|21 CFR 11.300(d)]]
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted? - [[#21 CFR Part 11|21 CFR 11.300(e)]]
*Is there a password reset method that does not require system administrators to know a user’s password? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 123]]
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency? - [[#21 CFR Part 11|21 CFR 11.10(b)]]
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy? - [[#21 CFR Part 11|21 CFR 11.10(c)]]

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system? - [[#21 CFR Part 11|21 CFR 11.10(g)]]
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)? - [[#21 CFR Part 11|21 CFR 11.10(f)]]

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-20T06:39:39Z

Jleecbd: /* Records Retention Support */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls<ref>The field of IT security has exploded in recent years with a number of high profile breaches. At the time of the writing of Part 11, the internet was much safer in this regard than it is today. The auditor should focus significant effort on security around all systems, but especially open systems.</ref>===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured? [[#21 CFR Part 11|21 CFR 11.30]]
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to? - [[#21 CFR Part 11|21 CFR 11.70]]
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls). - [[#21 CFR Part 11|21 CFR 11.200(a)(3)]]
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access? - [[#21 CFR Part 11|21 CFR 11.200(a)(1)(i)]]
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)? - [[#21 CFR Part 11|21 CFR 11.300(c)]]
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts? - [[#21 CFR Part 11|21 CFR 11.300(d)]]
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted? - [[#21 CFR Part 11|21 CFR 11.300(e)]]
*Is there a password reset method that does not require system administrators to know a user’s password? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 123]]
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency? - [[#21 CFR Part 11|21 CFR 11.10(b)]]
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy? - [[#21 CFR Part 11|21 CFR 11.10(c)]]

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-20T06:35:07Z

Jleecbd: /* Export of Records for Agency Review */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls<ref>The field of IT security has exploded in recent years with a number of high profile breaches. At the time of the writing of Part 11, the internet was much safer in this regard than it is today. The auditor should focus significant effort on security around all systems, but especially open systems.</ref>===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured? [[#21 CFR Part 11|21 CFR 11.30]]
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to? - [[#21 CFR Part 11|21 CFR 11.70]]
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls). - [[#21 CFR Part 11|21 CFR 11.200(a)(3)]]
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access? - [[#21 CFR Part 11|21 CFR 11.200(a)(1)(i)]]
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)? - [[#21 CFR Part 11|21 CFR 11.300(c)]]
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts? - [[#21 CFR Part 11|21 CFR 11.300(d)]]
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted? - [[#21 CFR Part 11|21 CFR 11.300(e)]]
*Is there a password reset method that does not require system administrators to know a user’s password? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 123]]
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency? - [[#21 CFR Part 11|21 CFR 11.10(b)]]
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-20T06:20:41Z

Jleecbd: /* Electronic Signatures */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls<ref>The field of IT security has exploded in recent years with a number of high profile breaches. At the time of the writing of Part 11, the internet was much safer in this regard than it is today. The auditor should focus significant effort on security around all systems, but especially open systems.</ref>===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured? [[#21 CFR Part 11|21 CFR 11.30]]
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to? - [[#21 CFR Part 11|21 CFR 11.70]]
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls). - [[#21 CFR Part 11|21 CFR 11.200(a)(3)]]
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access? - [[#21 CFR Part 11|21 CFR 11.200(a)(1)(i)]]
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)? - [[#21 CFR Part 11|21 CFR 11.300(c)]]
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts? - [[#21 CFR Part 11|21 CFR 11.300(d)]]
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted? - [[#21 CFR Part 11|21 CFR 11.300(e)]]
*Is there a password reset method that does not require system administrators to know a user’s password? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 123]]
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-20T05:20:20Z

Jleecbd: /* System Specific */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls<ref>The field of IT security has exploded in recent years with a number of high profile breaches. At the time of the writing of Part 11, the internet was much safer in this regard than it is today. The auditor should focus significant effort on security around all systems, but especially open systems.</ref>===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured? [[#21 CFR Part 11|21 CFR 11.30]]
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-20T05:18:59Z

Jleecbd: /* Open Systems Controls */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls<ref>The field of IT security has exploded in recent years with a number of high profile breaches. At the time of the writing of Part 11, the internet was much safer in this regard than it is today. The auditor should focus significant effort on security around all systems, but especially open systems.<ref>===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured? [[#21 CFR Part 11|21 CFR 11.30]]
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-20T05:09:14Z

Jleecbd: /* Open Systems Controls */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured? [[#21 CFR Part 11|21 CFR 11.30]]
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T05:11:38Z

Jleecbd: /* Access Controls */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T05:05:59Z

Jleecbd: /* Audit Trails 21 CFR 11.10(e) */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails ===
*Does the system maintain an audit trail that tracks changes to electronic records? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records time stamped? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are the audit trail records system generated, such that human intervention is not required? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Are audit trail records secured such that they cannot be modified by users of the system? [[#21 CFR Part 11|21 CFR 11.10(e)]]
*Is the audit trail data available for export (printing or electronic) to support agency review? [[#21 CFR Part 11|21 CFR 11.10(e)]]

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T05:04:25Z

Jleecbd: /* Audit Trails */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails [[#21 CFR Part 11|21 CFR 11.10(e)]]===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T05:02:54Z

Jleecbd: /* Fraud Detection */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent? [[#21 CFR Part 11|21 CFR 11.10(a)]]

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T05:00:03Z

Jleecbd: /* Records Retention Policy */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations? [[#21 CFR Part 11|21 CFR 11.10(c)]]

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T04:56:41Z

Jleecbd: /* Electronic Signature Certification */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so? [[#21 CFR Part 11|21 CFR 11.100(c)]]

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T04:55:07Z

Jleecbd: /* Change Control Systems */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding? [[#General Principles of Software Validation|GPSV 6.1]]
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so?

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T04:54:30Z

Jleecbd: /* Change Control Systems */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system? [[#General Principles of Software Validation|GPSV 5.2.7]]
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding?
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable? [[#General Principles of Software Validation|GPSV 5.2.1]]
*Is there a formal change control system for changes to requirements and design elements of the system during the development process? [[#General Principles of Software Validation|GPSV 3.3]]
*Do change control systems in use require appropriate approvals as governed by the SDLC model in use?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so?

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T04:39:40Z

Jleecbd: /* Change Control Systems */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system?
*Is there a configuration management system in place such that the contents of each version of released software is archived and readily identifiable?
*Is there a formal change control system for changes to requirements and design elements of the system during the development process?
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding?
*Do change control systems in use for Agile development models require product owner and development team approvals?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so?

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T04:34:37Z

Jleecbd: /* Training and Personnel */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?[[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are system administrators and developers trained in Part 11 and related regulations? [[#21 CFR Part 11|21 CFR 11.10(i)]]
*Are users trained on the use of electronic records systems? [[#21 CFR Part 11|21 CFR 11.10(i)]]

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system?
*Is there a formal change control system for changes to requirements and design elements of the system during the development process?
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding?
*Do change control systems in use for Agile development models require product owner and development team approvals?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so?

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T04:16:25Z

Jleecbd: /* Training Programs */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training and Personnel===
*Is an organizational chart available covering personnel involved in the design, development, administration or use of electronic records systems?
*Are job descriptions available for these individuals, indicating their specific responsibilities regarding electronic record systems?
*Is there a defined training program around authentication practices? Electronic signatures?
*Are system administrators and developers trained in Part 11 and related regulations?
*Are users trained on the use of electronic records systems?

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system?
*Is there a formal change control system for changes to requirements and design elements of the system during the development process?
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding?
*Do change control systems in use for Agile development models require product owner and development team approvals?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so?

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T04:13:26Z

Jleecbd: /* Cloud Computing PoliciesIn general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems. */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner? [[#21 CFR Part 11|21 CFR 11.30]]

===Training Programs===
*Is there a defined training program around authentication practices? Electronic signatures?
*Are system administrators and developers trained in Part 11 and related regulations?
*Are users trained on the use of electronic records systems?

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system?
*Is there a formal change control system for changes to requirements and design elements of the system during the development process?
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding?
*Do change control systems in use for Agile development models require product owner and development team approvals?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so?

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-19T04:10:31Z

Jleecbd: /* Cloud Computing Policies */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies<ref>In general there was little anticipation when Part 11 was drafted that such a thing as the cloud would come to exist. These checklist items, therefore, are reasonable extensions of requirements for in house systems.</ref>===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do these policies include Service Level Agreements(SLA's) regarding such things as up time, and support responsiveness?
*Are cloud vendors evaluated for security and compliance with appropriate regulations?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner?

===Training Programs===
*Is there a defined training program around authentication practices? Electronic signatures?
*Are system administrators and developers trained in Part 11 and related regulations?
*Are users trained on the use of electronic records systems?

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system?
*Is there a formal change control system for changes to requirements and design elements of the system during the development process?
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding?
*Do change control systems in use for Agile development models require product owner and development team approvals?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so?

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]

21 CFR Part 11/Audit guidelines and checklist

2013-04-17T04:55:54Z

Jleecbd: /* Identity Management Systems */

The following guidelines and checklist items provide a frame of reference for [[:Category:Vendors|vendors]] and auditors to better determine potential compliance issues with [[21 CFR Part 11|Title 21 Code of Federal Regulations Part 11]] and a variety of other regulatory guidelines.

All items in the checklist for general IT controls should also be checked for individual systems, especially where those systems use different control measures (e.g., they have an independent authentication system).

If this checklist is used by software vendors, then certain elements may or may not apply depending on the circumstances. For instance, validation is technically the responsibility of the entity acquiring the software. However, in the case of [[software as a service|SaaS]], a greater practical responsibility to validate the system may lie with the vendor. In all cases, the vendor should assume responsibility for ensuring that their software operates as intended within the targeted environments. Failure to do so may result in a lack of willingness of potential customers to obtain the system.

References will be provided for each checklist item to indicate where the requirement comes from. These references are either to the regulation itself, Agency responses in the Final Rule, or from the guidance document "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (GPSV).

==General IT==

Following is a list of questions that either apply to the larger IT environment, or to both the larger environment and to individual systems. The auditor must be sure to evaluate both where necessary. For instance, an organization may have a robust password policy which is managed by a centralized identity management tool. This is important evaluate in terms of general security around the systems in scope. At the same time, the specific system may or may not leverage the corporate IDM and thus it’s identity management should be evaluated on its own merits.

====Computer Systems Validation - 21 CFR 11.10(a)====
*Does a defined computer system validation policy exist? - [[#21 CFR Part 11|21 CFR 11.10(a)]]
*Are all computer systems involved in activities covered by predicate regulations validated? - [[#21 CFR Part 11|21 CFR 11.10(a)]], [[#Others|21 CFR 211.68(b)]], [[#Others|21 CFR 820.30(g)]]
*Does the computer system validation cover the current deployed version of the system? - [[#General Principles of Software Validation|GPSV 4.7]]
*Validation Assessment
**Does the software developer have a defined systems development life-cycle (SDLC)? - [[#General Principles of Software Validation|GPSV 4.4]]
**Does the SDLC reflect a generally recognized life cycle approach? <ref>While the Agency specifically does not recommend an SDLC, and rightfully so, established SDLC approaches become established typically due to the quality of product that comes from them. An SDLC that is either unique or a blend of disparate approaches may merit additional attention on the part of the auditor </ref>
**Is the SDLC followed? - [[#General Principles of Software Validation|GPSV 4.4]]
**Is the software well documented from a design/development/implementation perspective? - [[#General Principles of Software Validation|GPSV 3.3]]
**Is there evidence of design review activities (what this entails will depend on the nature of the SDLC - for instance, Agile methodologies will involve daily standup meetings,while a waterfall approach may reflect formal design review steps)? - [[#General Principles of Software Validation|GPSV 3.5]]
**Does the level of validation coverage reflect the risk from system failure? - [[#General Principles of Software Validation|GPSV 6.1]]
**Is there sufficient level of independence in the validation/verification activities? - [[#General Principles of Software Validation|GPSV 4.9]]
**Are sufficient resources and personnel provided for software development and validation? - [[#Others|21 CFR 211.25(c)]], [[#Others|21 CFR 820.25(a)]]
**Are records maintained of defects and failures identified in the development process? - [[#General Principles of Software Validation|GPSV 5.2.6]]
**For any software system, is there a set of approved requirements which drove the design (note: the name can vary based on the SDLC in use). - [[#General Principles of Software Validation|GPSV 6.1]]
**For iterative development approaches, are previous versions of deliverables (such as requirements lists) archived in some fashion? - [[#General Principles of Software Validation|GPSV 5.2.1]]
**Is there an audit trail for modifications to system documentation? - [[#21 CFR Part 11|21 CFR 11.10(k)(2)]]
**For commercial off-the-shelf (COTS), has the vendor been evaluated for its quality systems? - [[#General Principles of Software Validation|GPSV 6.3]]
**Is there some form of traceability that permits tracking of test results and verification activities to specific requirements? - [[#General Principles of Software Validation|GPSV 5.2.2]]
**Are adequate change control systems in place during the development and implementation processes? [[#General Principles of Software Validation|GPSV 3.3]]
**For each of the other elements of this checklist that apply directly to an electronic record system, has appropriate validation work been undertaken to establish that the system complies with the checklist item?

===Identity Management Systems===
*Do any identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable? - [[#21 CFR Part 11|21 CFR Part 11 Final Rule Section 130]]
*Do these id systems have policies regarding password change frequency? - [[#21 CFR Part 11|21 CFR 11.300(b)]]
*Do identity management systems prevent the creation of duplicate user ID’s? <ref>Although the regulation only specifies that identification codes in combination with passwords must be unique, since passwords are typically stored in encrypted format, there is no practical way to do this outside of ensuring that user ID's are unique</ref>

===Access Controls===
*Do formal procedures exist governing user account creation for electronic records systems.
*Do formal procedures exist governing access to network and server resources that are used to operate electronic records systems?

===Cloud Computing Policies===
*Are policies in place governing the selection and use of cloud vendors for electronic record systems?
*Do policies governing record retention specifically apply to cloud vendors?
*Are systems for transmitting electronic records configured to do so in a secure manner?

===Training Programs===
*Is there a defined training program around authentication practices? Electronic signatures?
*Are system administrators and developers trained in Part 11 and related regulations?
*Are users trained on the use of electronic records systems?

===Change Control Systems===
*Is there a formal change control system for modifications to the production electronic records system?
*Is there a formal change control system for changes to requirements and design elements of the system during the development process?
*Does the change control system require an assessment of impact, risk, and require authorization before proceeding?
*Do change control systems in use for Agile development models require product owner and development team approvals?

===Electronic Signature Certification===
*If the organization is using electronic signatures, have they filed a certification with the FDA indicating so?

===Records Retention Policy===
* Does the organization have a records retention policy covering records per the predicate regulations?

==System Specific==

===Fraud Detection===
* Is the system designed to either prevent record alteration or make such alteration apparent?

===Audit Trails===
*Does the system maintain an audit trail that tracks changes to electronic records?
*Are the audit trail records time stamped?
*Are the audit trail records system generated, such that human intervention is not required?
*Are audit trail records secured such that they cannot be modified by users of the system?
*Is the audit trail data available for export (printing or electronic) to support agency review?

===Access Controls===
*Does the identity management systems have minimum password complexity/strength requirements? Do these minimums seem reasonable?
*Do these id systems have policies regarding password change frequency?
*Do identity management systems prevent the creation of duplicate user ID’s?

===Open Systems Controls===
*Are records transmitted by the system sent in a secure manner, such that their authenticity, integrity and confidentiality are ensured?
*Is access to the system appropriately managed to prevent unauthorized external access?
*Has the system been evaluated for susceptibility to intrusion?
*Is there a system in place to evaluate current IT security threats that have been identified (by the National Cyber Awareness System via NIST, or other appropriate organization)?

===Electronic Signatures===
*Is the electronic signature system engineered in such a way as to ensure that the signatures cannot be attached to other records, or cannot be removed from the records they are attached to?
*Is the system engineered such that in order to apply someone else’s signature to a file that collaboration is required between two or more individuals? (this is largely covered by the identity management controls).
*If a signature event only requires one signature element, is it only in the case of being part of a continuous period of system access?
*Are their suitable loss management procedures in place to address compromised passwords, or lost/stolen authentication devices (such as RSA ID tokens)?
*Is the system designed to alert security and/or management in the event of an apparent attempt at unauthorized use of electronic signatures? Does the system automatically take steps to lock out users associated with these attempts?
*Is there a system for the periodic testing of tokens and cards to ensure that they are still operating as expected and have not been altered? If not, is there something in the nature of the tokens/cards that would render them unusable should alteration be attempted?
*Is there a password reset method that does not require system administrators to know a user’s password?
*Are user passwords suitably encrypted in any persistent data store, such that elucidating the original password would require extraordinary means?
*Are controls in place to ensure that password reset instructions are sent to the correct individual?

===Export of Records for Agency Review===
*Does the system support exporting records in a format that is readable by the agency?
*If the agency hasn’t been specifically consulted with regard to acceptable formats, does the system support export into common formats such as XML or JSON?

===Records Retention Support===
* Does the system have sufficient controls to ensure that the records stored within it will be available throughout the period specified in the records retention policy?

===Process Controls===
*Does the system have a mechanism to establish differing levels of authority to perform tasks in the system?
*Does the system have a mechanism for preventing steps being taken out of sequence (e.g., signing a record before data has been entered, or releasing a record before the review step was completed)?

==Reference material==

===21 CFR Part 11===

'''Subpart A — General Provisions'''
:§ 11.1 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.1 Scope]
:§ 11.2 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.2 Implementation]
:§ 11.3 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.3 Definitions]

'''Subpart B — Electronic Records'''
:§ 11.10 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.10 Controls for closed systems]
:§ 11.30 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.30 Controls for open systems]
:§ 11.50 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.50 Signature manifestations]
:§ 11.70 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.70 Signature/record linking]

'''Subpart C — Electronic Signatures'''
:§ 11.100 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.100 General requirements]
:§ 11.200 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.200 Electronic signature components and controls]
:§ 11.300 [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?fr=11.300 Controls for identification codes/passwords]

===General Principles of Software Validation===

The full name of this FDA guidance document is "General Principles of Software Validation; Final Guidance for Industry and FDA Staff," referenced on here as "GPSV."

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237928 Section 1. Purpose]'''

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237929 Section 2. Scope]'''
:2.1. Applicability
:2.2. Audience
:2.3. The Least Burdensome Approach
:2.4. Regulatory Requirements for Software Validation
:2.4. Quality System Regulation vs Pre-Market Submissions

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237935 Section 3. Context for Software Validation]'''
:3.1. Definitions and Terminology
::3.1.1 Requirements and Specifications
::3.1.2 Verification and Validation
::3.1.3 IQ/OQ/PQ
:3.2. Software Development as Part of System Design
:3.3. Software is Different from Hardware
:3.4. Benefits of Software Validation
:3.5 Design Review

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237944 Section 4. Principles of Software Validation]'''
:4.1. Requirements
:4.2. Defect Prevention
:4.3. Time and Effort
:4.4. Software Life Cycle
:4.5. Plans
:4.6. Procedures
:4.7. Software Validation After a Change
:4.8. Validation Coverage
:4.9. Independence of Review
:4.10. Flexibility and Responsibility

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237955 Section 5. Activities and Tasks]'''
:5.1. Software Life Cycle Activities
:5.2. Typical Tasks Supporting Validation
::5.2.1. Quality Planning
::5.2.2. Requirements
::5.2.3. Design
::5.2.4. Construction or Coding
::5.2.5. Testing by the Software Developer
::5.2.6. User Site Testing
::5.2.7. Maintenance and Software Changes

'''[http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm#_Toc517237965 Section 6. Validation of Automated Process Equipment and Quality System Software]'''
:6.1. How Much Validation Evidence Is Needed?
:6.2. Defined User Requirements
:6.3. Validation of Off-the-Shelf Software and Automated Equipment

===Others===

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=211 21 CFR Part 211]: Current Good Manufacturing Practice for Finished Pharmaceuticals

* [http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/cfrsearch.cfm?cfrpart=820 21 CFR Part 820]: Quality System Regulation

==References and footnotes==
<references />

[[Category:Regulatory information]]