We are developing user requirements for a system, and aren’t sure how we should handle the requirements around security. We know the system will have role-based security, but the user wants the ability for an Administrator to create roles as needed. I foresee two potential options:
Define a single user requirement that says an Administrator shall have the ability to create security roles. Abilities for each role would not be defined in the documentation because it can change as roles are added or modified. This would also save us from having to constantly update the documentation.
Define separate user requirements for the security roles that will be available when the system is released. If roles must be added or modified, the system must go through a change control process. Corresponding documentation would have to be updated.
Is option #1 even feasible with 21 CFR Part 11? Any recommendations or suggestions will be greatly appreciated.
When you say roles will be continually modified, what exactly do you mean? Surely you need to know upfront what each role is capable of doing. Would it not be possible to create a number of roles to cover all of the eventualities that can occur in the system to avoid constant generation of change controls?
What I mean is that roles have the possibility of changing over the years. For example, let’s say I have a Technician role that has the ability to view reports for Part Numbers and Manufacturing Deviations. Down the road, we decide that a Technician should be able to view a Machine Usage report. This report is already available in the system, but could not previously be viewed by a Technician. The Administrator would then have the ability to go in and give the Technician role access to this new report.
I suppose you could create a number of roles to cover all eventualities, but I don’t see any value to that especially if some of the roles aren’t used. I think in our particular scenario, we wouldn’t be doing a lot of change controls around security, but we are trying to maintain flexibility of what we do.
I think what I am trying to figure out is if it is possible to validate the functionality of a role-based security as opposed to validating the roles we will use. If we validate the functionality, then I think changes for a security role do not require a change control. Make sense?
From previous experiences when you test role based functionality, your tests ensure that each role has a specific functionality. So you write a test, for say a product builder and you test that they can only use specific functionality in the system.
I would think giving someone rights at a later stage without going through change control could be risky if that is what you are thinking of doing.
If this only happens now and again I wouldn’t worry about it too much as raising a change control to test a new role functionality would be pretty straight forward.
I would validate the roles themselves as this are a critical aspect of your system.
Are you config checking or will you do functional tests?
I think you touched on exactly what this is. Changing the security is a configuration option, not a code change. If changing security required a code change, I wouldn’t be asking this.
They haven’t determined what tests we will be doing yet, but I imagine the tests will be more focused on the functionality as opposed to what the configuration is. We need to show that the functionality will satisfy our requirements.
Personally, I wasn’t too worried about raising the change control, but we do have limited resources so anything we can do now that will reduce the number of change controls will help in the long run.
From my perspective if you put the security / user access levels in the User Requirements, then you have to test it for Validation purposes. It sounds like you want to limit the testing. I would recommend writing a good Configuration Management Plan to go with the system.
Unfortunately, it’s a complex question with an equally complex answer.
I think that what you’re asking is if you can validate the system (e.g., for Part 11) without defining specific roles. I would say the answer is yes, but you have to jump through some extraordinary hoops to get there.
Take, for example, a system with 3 security facets: a, b, and c. Presume, for the sake of this discussion, that they are independent of each other and binary (e.g., either on or off). Thus, you could define any user in the system as a sequence of settings for a, b, and c. If I do the math, there are 8 combinations. Your validation would need to show each of these to ensure that any user defined in the system would have the controls as expected. I think that’s probably what you are getting at when you say you could validate for all eventualities. As you can see, complexity mushrooms as you add multiple facets or if the facets aren’t binary. This would likely make such validation quite infeasible.
I would probably suggest that you stick with the role-based approach and, if a role needs to change or be added, re-validate the system (should be a limited re-validation focused only on the new / changed role). The idea of changing a role is a bit worrisome as the potential for unintended consequences increases (e.g., someone given a delete privilege could alter the past).
I think your approach defined in #2 is better suited for a regulated environment. Keep in mind that validation isn’t just for the software - it’s for the system. So any change to the system (e.g., role change / addition, addition of a new server, etc.) takes the system out of a validated state. You can do a change / risk analysis after each change to scope the re-validation effort.
That’s a very good point yodon. I was thinking that instead of testing each combination of functionality that we would take a risk-based approach. We would test each individual security option to ensure that each one is correct, and then take some different combinations of security roles to make sure that they don’t interfere with each other. The more I think about it, that can be a gray area because how do you select the right combinations? You can’t. You won’t know if you selected the right combinations unless you test all of them. It’s a catch-22.
I think it will save us a lot of heartache to validate the roles that we intend to use right now, and then open up change controls and make the necessary updates if it ever changes down the road.
Thank you all for this very valuable insight! You have been very helpful!
