The FDA will not audit you unless you’re directly regulated (e.g. a medical device manufacturer), and in any case won’t bless your software for other companies to use.
I’ll tell you why I do software supplier audits and in general what I look for.
First, if my company is writing their own software, the expectation is that we’ll document what the user needs, what the software must do, how the software will be designed, how the software was built, how the software was tested, how the testing mapped to the requirements, how we handled any bugs or other testing discrepancies, how we’ll track bugs that remain in the software after release, and so forth. There are other things that surround and/or sit on top of the software development process that also have impact, such as whether our software development lifecycle is documented and repeatable, how we handle configuration management of the software and documentation, how we handle the training of developers and testers, whether we have separation of responsibilities for development and testing, whether we have an independent QA group that conducts internal audits, how we manage our work instructions and/or standard operating procedures, etcetera
ad infinitum.
Because we designed the software and we wrote the code and know how it’s structured, we’re expected to have design controls and software quality assurance in place. Our software specification documents should clearly define what the software must do and how it does it. Our design should undergo an review by technical folks who are independent of the effort being reviewed. Our code should be reviewed by programmers who didn’t write it. Our testing should have a lifecycle that includes (as appropriate to the technology being used) unit testing, integration testing, and acceptance testing. Our testing should include functional (input/output black box testing) and structural (code tracing white box testing). Because we know the inner structure of the software, the data we use when we run functional tests should be specified with an eye towards what might cause the software to break.
Now let’s say that instead of writing the software, we want to buy it from you. We’re still responsible for assuring that all of the above gets done, but we’re no longer the ones doing it. So we instead audit you and document what we found, and store that audit documentation along with whatever else we can do to assure that the software is fit for our purpose (the typical expectation is supplier audit + specification of our process needs + specification of how we combine your software installation with servers, networks, and other other supporting infrastructure + our own functional and performance testing). When we audit you we look for evidence of all the stuff we would expect to have in place and do ourselves had we written the code. We’ll look at your software development artifacts (to gain an assurance that the software is sound) and your quality management system (to gain an assurance that future releases will be sound, too).
If you validate your software per current industry standards it helps me in that it makes my review of your development artifacts faster. If also you declare your software to be Part 11 compliant it helps me, too, since I should be able to find all of the Part 11 technical controls as requirements in your specification documents and therefore easily traceable to the functional tests that challenged them.
Regards,
