I haven’t see a system yet that didn’t check password access, but most testing of Security features stops there. Even though Security is one of the critical “Big Three” drop-dead validation issues, it doesn’t get much attention by most companies. Therefore, you often see findings like this one made in an FDA 483:

Testing of system security was inadequate. Example: multiple levels of user access testing was insufficient to demonstrate that authorized users of the system are prevented access to unauthorized areas.

You should thoroughly demonstrate that the security on the system is adequate to prevent unauthorized entry.

So, in addition to the “front door” of the system (i.e the usual method of access), attempt system break-ins through the “back door, side door, and windows” as well. For example, in a Windows environment, attempt to access secured files through Windows Explorer and DOS.

In addition, here’s the minimal Security Testing that needs to get done at the Operating System and Application levels:

1. Operating System

Operating System Logon Verification as follows

2. Application Server

Application System Logon Verification as follows:

3. Failed Logins

Verify that three failed logon attempts results in lockout for the user. Verify for Operating System access, as well as Application Systems access.

4. Admin Creation

Verify the creation of an Administrator User.

5. User Access

Logon as the Administrator. Verify the creation of Multiple Levels of User Access.

6. Acces Levels

Verify the creation of Multiple Users with different Levels of Access assigned.

7. Access Level Testing

For each level of access, sign on as a user at that level and verify they have access to every screen/function they should have, and no access to any screen/function they shouldn’t have.

8. Changing Access Level

Verify that a user cannot modify another user definition. Verify that a user cannot change their own or another user’s Access Level.

9. Admin Modification

Logon as the administrator. Verify that a user can be modified by the Administrator. Verify that the Administrator can change a user’s Access Level.

10. Old Access Level Testing

Logon as the changed user. Verify that the user now can access all screens/functions at the new Access Level and none of the Old Access Level.

11. Restricted Access – Application

Verify that a user can be deleted from the Application but not from the Operating System. Verify that the user has no access to the Application at all, but can still log on to the Operating System.

11. Restricted Access – Operating System

Verify that a user can be deleted from the Operating System. Verify that a deleted user no longer has any access to the Operating System or the Application at all.

These are the basic Security tests that need to be run. Some systems will have more or less security features and therefore, the above tests will need to be adjusted.

Few validation efforts show this level of comprehensive testing!