|
|
|
|
|
by Kalium
2999 days ago
|
|
Well said! Thank you for your comments. With all that said, my point was that it's not obvious what is and isn't reasonable. Hiring a security specialist won't necessarily help you understand what bureaucrats will or won't deem reasonable, especially when there's no history to provide context. |
|
It's your best guess what is and isn't reasonable. As long as you've documented what you did and why you did it, then you've satisfied that requirement. If an auditor finds what you've done to be insufficient, you'll probably get a warning but you'll still be considered compliant for having done something.
I know it's not a satisfying answer and I'm sorry that I don't have a better one, but complying with regulation is not as definite a "yes/no" as programming.
My knowledge is with the FDA so I'll give an example I'm familiar with. I worked with CT scanners and we needed to do verification/validation. The FDA requirement was to the effect of "must define reasonable requirements for the device" and "must set up testing procedures that reasonably demonstrate that a device can meet its requirements" and so the team I worked with set requirements like "radiation dose: <20rad when run on [x] setting" and then tested it at [x] setting 5-20 times, then documented "passes radiation dose test with 99% certainty, which exceeds our cutoff for passing which is 95%".
CT is an old industry so there was a bit more to it than that, but we were still following requirements that we had written, and testing them in with procedures we had made. The point is the requirements even in the health industry can be vague, so you really just have to do your best to come up with something reasonable.
And because it's vague, that's also why it's so important to document everything.