FDA's Remote Compliance Inspections/Audits:

What originally appeared to be a temporary arrangement to adjust to the Covid 19 shutdown of 2020-2023 - remote / virtual inspections, now appears to be a regular feature used by the FDA remotely / virtually as needed to accomplish some lower risk (patient/user) CGMP compliance and other type inspections previously done in-person, on-site.

J. E. Lincoln and Associates LLC has performed several such internal audits (an annual requirement for regulated companies) for clients (new and established clients) over the past several years (since 2022) 100% remotely / virtually, with excellent results. One of these JELALLC virtual audits was to resolve a 483 from the FDA (for the company having done no internal/self audits) on a recently concluded site inspection, for which the FDA found our remediation method acceptable. 

Some considerations:

• An Audit Plan, developed by the auditor, addressing how some areas will be addressed remotely; a brief follow-up phone or e-mail discussion of the Plan and the development of a simplified flow plan / floor plan of the audit site /company by the auditor (approximately 1 week in advance);  
• Pre-submissions of some key documentation by the company to the auditor (prior or during);
• Client provides some one proficient with a camera (or phone camera) for site tour videos / pictures, document close-ups, and similar;
• Prearranged Zoom, Teams, or similar meeting (by the auditor, the Audit Meeting), starting with the meeting with the company team, a discussion of the Plan / Schedule / Audit Questionnaire / Matrix based on the applicable CGMPs / Regulations / Standards / FDA Inspection Manual 7283.850 (Devices, 2026) or FDA Inspection Manuals 7356.002 or-F (Pharma, General / Q10,2022, or -F, APIs, Q7, 2015) Check List (the day (1-2) of the audit, for usually 2 hours, +/-); 
• A "tour" of the facility (included in the above time frame)
• Q&A (the "meat of the audit") by the auditor using the Inspection Check List, verified by photos, videos, submissions as needed to resolve questionable areas / documentation / records (part of the above, any additional time to resolve any serious issues);
• Break.  Auditor drafts preliminary report based on the Questionnaire  (usually 1 - 2 hours);
• Resume Virtual Meeting with QA/Company principals to review the Draft report (usually 1 hour or less);
• Resolve any disagreements and develop remediation plan / responses as needed (included in above or a separate series of communications;
• Draft Final Report and submit for review and discussion (usually an e-mail or text discussion, about one+ weeks later);
• Submit Final Report, in agreed electronic format as well as a written Report by mail (usually 1-2 days after final draft review). 

The above is for a small or medium-sized company, with the actual audit taking portions of one to two days.

Note:  Per the new FDA Device Inspection Manual, Feb 02, 2026 (and 21 CFR 820 / QMSR Final Rule Preamble), company internal audits, vendor audits, and similar, are no longer "off limits" to an FDA inspector / inspection). 

Note:  While an FDA virtual inspection may follow a similar plant/format, including giving a company an idea of it's concerns after each day's inspection and providing the company a chance to correct (however the 483 observation remains, tho' the comment is added that it was corrected prior to completion of the inspection) and their timing may vary somewhat; the above done by JELALLC adds a client review/comment of the draft, with some possible revisions, and the same with the Final Report.  Such reviews can clear up misunderstandings so they don't remain in the final report, but they do not remove any valid findings, tho' some company explanation may be added.

-  jel@jelincoln.com    04/30 - 05/02/2026,; some clarification added after initial 4/30 publication. 

Questions Received From One of My Recent Webinars on Software V&V:

My responses:

 Q1. Do we need to define and perform periodic validation, or is it mainly an analysis to determine whether changes have occurred that require re-validation?  

ANS:  I believe I mentioned that I don't believe in calendar-scheduled revalidation, nor are they required by regulators.  There should be a periodic re-evaluation for any changes that require a re-validation, e.g., physical move, major repairs, etc., documented if the decision is to not revalidate.  You can also set up systems to maintain equipment in a validated state (challenged, recorded in a log, lot records, or...)  All allowed by the FDA

 

Q2. If we are using COTS software with low risk, can we skip the validation process?

ANS:  No.  FDA has stated that software is a risk-based activity, that's patient/user risk per ISO 14971, documented.  Some validation is necessary for all COTS (all software), at least to verify that it meets your / regulatory needs / requirements, that it does what it should do and doesn't do anything it shouldn't - no unintended consequences.  And Part 11 is mandatory if the COTS is used for CGMP compliance records/sigs. Ditto Cybersecurity, if software can be or is connected to the Internet (including by flash drive, CD-0ROM...). Any V&V done by the vendor, if you have access to it, can be used to reduce what you need to supplement it in your test documentation.

 

Q3. When using SaaS for testing activities (e.g., test tools), where we do not have control over vendor-driven version changes, how can we maintain a validated state? This is especially relevant when vendors provide advanced features but are not specifically focused on the medical device industry.

ANS:  Such vendor change control reporting is a problem in all industries, and especially with cloud-based software.  You're going to have to 1) try to select companies willing to commit to such change notifications, 2) put such requirements in contracts, POs, etc., 3) set up systems to catch changes when such are implemented without notification (common with software changes), 4) shift to CGMP/ISO compliant-vendors, or those who want to be to be more competitive.  Failure to do so will jeopardize $1000's in past validations, put you in conflict with the CGMPs, et al.  This is an on-going problem, and not just with our industry. 

 

Q4. How detailed should a test report be? We conduct multiple V&V rounds for both feature and regression testing, resulting in very detailed test steps. If we generate a final report, it can run into hundreds of pages with step-by-step pass/fail analysis. Is it acceptable to provide a summarized report instead of including detailed step-by-step results to keep the document concise?

ANS:  It should be patient/user risk- based for amount of detail / length.  Don't make the mistake of a "one-size fits all" software V&V test report SOP, which I see all too often with companies. I don't see how a summarized report saves anything if it's a summary of more extensive tests. Obviously 100's of pps should not be necessary for a PLC conveyor system validation or similar, but would be for a cancer drug pump. They can be large multi-page reports for complex, high risk (to people) systems/equipment, or a few pages in a Lab Book for low risk, and/or less complex systems.  They should all have enough information to allow replication:  Project/test No., Title, Purpose/Scope, Approvals, pre-determined acceptance criteria, Materials used in test( P/Ns, Descrip.,  Lot No., qty...) , Equipment used (Equip/Asset No., S/N, Descrip., ...), test set up descrip'n, diagrams...), Requirements/needs to be V&V's, test cases addressing each requirement, results (filled in test cases / data), conclusions (results compared to pre-determined acceptance criteria), Post-Approvals, Appendix -- expand / contract based on risk.   

 

Hope that answers the questions.

-- jel@jelincoln.com  04/28/2026

-- Minor clarifications, Q1 & Q2, 04 /29/26 - JEL

 Some "Test Case" Examples:

Each test case should be based on the test subject's requirements / needs (customers, Standards, legal, manufacturing capabilities, et al) that are being tested (verified / validated)

                                                                            OQ:

PQ:

Include on Each PQ Sheet (2nd Test Case for 

software, i.e., UPS, generator tests):

-- Added Test Case Titles, 04/29/26 - jel@jelincoln.com

- jel@jelincoln   04/27/2026

 Recommended In-House Test Format:

Your in-house test documentation should be structured similar as follows, each test in a formal document / Test Report or Lab Book, preferable per an SOP on testing:

• Title;
• Test Number, date(s);
• Description, Scope, Purpose...;
• Pre-approvals signatures/dates, including Tester, Verifyer/QC;
• Material (Description, Part Numbers, Quantity, Lot Numbers...);
• Test Equipment (Description, Asset No., Item No., Serial Numbers... (as appropriate));
• Test Set-Up (Drawings, Schematics, Photos, Diagrams, etc.);
• Predetermined acceptance criteria / expectations;
• Test object's Requirements;
• Test Cases / Protocol (at least one for each requirement, single or in combination);
• Results (filled in test cases, data);
• Conclusions (how test cases fulfilled pre-determined acceptance criteria ("pass/fail"));
• Post approvals, including tester, Verifier/QC. 
• Appendix, as needed.

 Include enough information to allow the test to be replicated and obtain similar results. 

- jel@jelincoln.com  04/27/2026

 - Added "similar" in 1st sentence; and "object's" to Requirements. - JEL, 04/30/26