Part 11 Password Safeguards: What’s Really Required?

Q: My question concerns the requirement for Part 11 password safeguards (Part 11.300(d)) that prevent unauthorized use of passwords or identification codes.

We’ve always considered the “detect and report” portion of this requirement to include logging unsuccessful attempts and then reviewing those logs. Is this the right approach?

If so, how are other companies meeting the Part 11 password safeguards requirement, especially considering the huge volume of records involved? If they review access logs, how frequently are the logs reviewed and how long are the records retained? Who should review the logs?

A: You are correct that “detect and report” includes logging of unsuccessful ID/password attempts and reviewing those logs — but the intent of this section of Part 11 goes farther.

Transaction safeguards include all the procedures, processes and policies you develop and implement to provide security for passwords and identification. They also include your procedures for issuing passwords, verifying identities, constructing passwords, determining the frequency of password changes, training employees, auditing for effectiveness, and monitoring.

In addition, you should have policies that cover the use of multiple identifiers and physical access to systems. Your objective should be to ensure detection and monitoring throughout the sequence of all operations, preserve audit trails, and maintain system integrity over time.

[pullquote align=”right” cite=”” link=”” color=”” class=”” size=””]The logging and review of unsuccessful attempts is a minimum expectation, and just part of the overall system you should have for Part 11 transaction safeguards.[/pullquote]

So the logging and review of unsuccessful attempts is a minimum expectation and just part of the overall system you should have for Part 11 transaction safeguards.

How are other companies addressing this requirement?

Generally, in addition to having the policies and procedures mentioned above, failures are counted and lead at some point to locking the user (or user ID) out of the system. While locking out the user is not a particularly productive activity, reporting the number of attempts, having automated monitoring, and reporting the number of failures to security administrators does indeed have value.

Rather than waiting for a log review, you should alert security administrators based on system-detected suspicious attempts. This process is stronger — it “pushes” the information to security rather than waiting for after-the-fact discovery.

System security personnel should perform the review of any logs. The logs and records of their review (usually in a logbook) are considered regulated records and follow the normal record retention period requirements.

Needless to say, if suspicious activity is detected, an investigation must be conducted to assess its impact on data integrity as soon as possible.

Answered by Martin Browning, President and Co-Founder of EduQuest, who co-wrote the 21 CFR Part 11 rules for electronic records and electronic signatures while serving as the Special Assistant to FDA’s Associate Commissioner for Regulatory Affairs.Martin also is the developer and chairman of EduQuest’s three-day training class on FDA Auditing of Computerized Systems and Part 11/Annex 11 Compliance


Leave a Reply

Your email address will not be published. Required fields are marked *