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
| Combination Attempted | Expected Results |
| Invalid Username / Invalid Password | Access Denied |
| Valid Username / Invalid Password | Access Denied |
| Invalid Username / Valid Password | Access Denied |
| Valid Username / Valid Password | Access Granted |
2. Application Server
Application System Logon Verification as follows:
| Combination Attempted | Expected Results |
| Invalid Username / Invalid Password | Access Denied |
| Valid Username / Invalid Password | Access Denied |
| Invalid Username / Valid Password | Access Denied |
| Valid Username / Valid Password | Access Granted |
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!
