Most software device teams I work with assume audits follow a predictable rhythm. Show the CAPA. Walk through the DHF. Demonstrate the quality system is in order. Under the old QSR, that assumption was mostly correct, but after Feb 2, 2026, it is not.
The Quality Management System Regulation (QMSR) went into effect that day, aligning FDA's requirements with ISO 13485 and shifting the agency's inspection framework in ways that most software teams have not fully absorbed yet. The change is not subtle. Auditors who used to start their review at the CAPA level now start somewhere else entirely: your risk file. And they branch out from there based on what they find.
I have spent more than 15 years helping software device manufacturers build compliance frameworks, preparing quality systems for FDA inspections, and working through 483 remediation. I also co-founded Iaso Automated Medical Systems, which develops AI and machine learning-enabled medical devices. So I see both sides of this. What follows is what auditors are actually looking for when they walk into a software device company today.
The risk file is now the entry point for FDA inspections
BONUS RESOURCE: Click here to download your free 3-in-1 SaMD Gap Assessment Tool!
Under the previous QSR model, inspectors tended to start with corrective and preventive actions. Quality leads knew to have their CAPA files clean before an inspection. We would lay out the conversation in advance, map the risk elements in the CAPAs, and prepare to address them one by one.
Post-QMSR, inspectors start at risk. Your risk management file is the first thing the agency asks for, and what they find there determines where they go next. If they identify what looks like a blind spot in how you have approached risk, they branch into that area. There is no longer a standard choreography you can rehearse.
The implication is that a risk-based approach cannot be a document you maintain separately and produce on request. It has to be woven into how your quality management system operates. Under QMSR, FDA expects the risk-based approach to be visible throughout your QMS, not just in your design controls. One practical reminder: ISO 14971 is a standard specifically for product design. If you are referencing it as your risk standard in areas outside of design and development, that is a finding waiting to happen. The appropriate reference for enterprise-level risk management outside design controls is ISO 31000 or 31001.
The top two audit findings since QMSR took effect have been risk-related. None of that is surprising, given that the change was telegraphed clearly in how the regulation is structured. But understanding it intellectually and having documentation that actually reflects it are two different things.
Software safety class: what auditors look for in your IEC 62304 documentation
For SaMD, software in medical devices (SiMD), and AI/ML-enabled products, one of the first things an auditor examines in the software documentation is whether your software safety classification holds together.
Under IEC 62304, everything starts as Class C until you justify otherwise. A lot of teams want to downgrade some of their software components, which is acceptable, but you have to provide written justification. What I see repeatedly is teams that declare a software safety class and then restate the definition from the standard rather than actually justifying their classification.
Two specific gaps create findings here. First, the standard does not define what a "unit" is. If you are downgrading components based on their segregation, you need to define how your company defines a unit in your architecture document, then reference that definition in your software safety class justification. Second, the justification has to reference your software architecture, discuss segregation, and explain how the unit's classification is supported by the architectural evidence. Without that structural support, you are simply asserting a class without proving it, and that is where the finding lands.
There is also a coherence check auditors run that many teams miss. Under QMSR, software documentation is categorized as either basic or enhanced. If you are claiming a basic documentation level but your software safety class is C, that inconsistency is a flag. The documentation level and the safety class are not the same thing technically, but they both reflect how seriously you are treating potential harm, and when they do not align, auditors notice.
Risk hazards specific to AI/ML-enabled devices
Software device teams building AI and ML capabilities face an additional layer of scrutiny that hardware-adjacent teams often underestimate.
When I audit a risk analysis for an AI or ML-enabled product, I am looking for evidence that the team has engaged with the specific risk categories these technologies introduce. The AAMI TIR49711 standard covers this territory, and I want to see that the team has at least been exposed to it. Two particular hazard categories come up regularly in my audits and are often missing from risk files.
The first is overtrust. For clinical AI products, users, whether healthcare providers or patients, can over-rely on the system's outputs. If the risk file does not include hazards related to overtrust, that is a gap. The second is bias. AI systems trained on specific datasets can produce outputs that are systematically inaccurate for certain patient populations, and bias hazards tied to training data should appear in the risk analysis, particularly if the team has used datasets with known representational limitations.
Beyond these categories, software risk analyses often miss the full product life cycle. Obsolescence is a good example. Teams think of it as a hardware concern, but for SaMD, the question of what happens to stored data when the product is discontinued is a real risk. If you process or hold protected health information, you need to document how that data will be handled at end of life. In European markets, the right-to-erasure requirement under GDPR adds another dimension to this problem.
I also look carefully at whether risk control measures are truly linked to verification of effectiveness. Most teams have traceability from hazardous situations to requirements. What falls apart is the next step: can you follow the thread from that requirement through to a test result that actually demonstrates the risk control measure is working, not just that the requirement exists? Tracing to a test report is fine. Tracing to a test report that verifies a requirement that does not directly address the risk is not.
Design controls and software DHF: common audit findings
After risk, design and development is where software audits yield the most findings, and the gaps tend to cluster around the same structural problems.
On user needs: these should capture the intended use, the user environment, and clinical workflow requirements, down to the context in which the device operates. User needs and user requirements are not the same thing, and I see them confused regularly. User needs reflect the user's perspective, what the person using the product actually needs to achieve, while user requirements are the company's translation of those needs into measurable, verifiable specifications. Getting these mixed up creates traceability problems that surface during verification and validation, and auditors will find them.
On design inputs: they need to be verifiable and measurable. I have seen teams write the inverse of a requirement rather than the requirement itself. "The system shall not fail" is not a design input. I have also seen user needs placed where design inputs should be, and user requirements placed where user needs should be. These distinctions matter because they shape the entire verification and validation approach downstream.
Software bill of materials (SBOM) is increasingly a hard requirement for any device that can connect to external systems. Even if you have designed the device not to connect, if it is capable of connecting to an open-loop system or the internet, FDA assumes users will connect it and expects you to have considered those risks. The SBOM should list everything: off-the-shelf components, custom off-the-shelf, and software of unknown provenance (SOUP). Having the SBOM is not sufficient on its own. You also need to run it against vulnerability databases and document that you have identified and addressed known vulnerabilities, including penetration testing for devices that handle sensitive data.
One area that catches software teams off guard: UI screens are labeling. Your user interface is considered labeling under FDA's framework. If a risk control measure manifests as a warning in the UI, that warning needs to be controlled just like a label on a physical device. How it appears, what it says, and how changes to it are managed all need to be documented and controlled.
Change control for SaMD: where software-specific audit findings cluster
Software teams push changes constantly, and that is by design. The compliance problem is that change control procedures are often written as if changes are discrete, infrequent events, when in practice software releases involve parallel feature development, hotfixes, platform updates, and version rollouts that interact with each other in complex ways. Maintaining audit-ready records through your development tools is one way teams reduce this exposure, but the procedural gaps still need to be closed.
Every software change needs an impact assessment that evaluates whether the change is significant under FDA's guidance, whether it requires a new 510(k) submission, and whether it affects any work currently in the pipeline. Teams running agile development with multiple workstreams often miss that last part. A change to one feature can affect a different feature currently in design, and that dependency needs to be documented and evaluated before the change ships.
Hotfixes are where I see the most consistent miss. When a hotfix addresses a patient safety issue, it qualifies as a correction, and if it reduces a risk to health, the 10-day reporting clock starts. Someone in the organization needs to evaluate every hotfix against that threshold. Most teams assume hotfixes are too small to trigger reporting requirements, and that assumption has produced findings.
Rollbacks are removals. When a software-only device rolls back to a previous version, you are removing a version from production and from the market, and that action needs to be evaluated for reportability just like a physical product removal would be.
Outsourcing and supplier management for cloud-native SaMD companies
Modern SaMD companies are almost entirely cloud-native, which means their supplier risk profiles look very different from a hardware manufacturer's.
If you use infrastructure as a service, platform as a service, or any third-party AI capabilities, those vendors are suppliers. AWS, Azure, and comparable providers will not let you audit them directly, but they publish SOC 1 and SOC 2 attestations, service level agreements, data processing agreements, and business continuity documentation. All of that belongs in your supplier file and needs to stay current. I have had to help teams pull together documentation they did not know they were missing, sometimes during an active inspection. That is not a position you want to be in.
For large language models and agentic AI integrations, the supplier considerations extend to model version management, data handling terms, and change notification. If the model you are using is updated, you need a process to evaluate whether that update affects your device's functionality or risk profile.
SOUP is a category I see mismanaged regularly. If your team has pulled MATLAB scripts or open-source libraries into your software, those are SOUP. If you use them, you need to stay current with vulnerability disclosures and version changes for those components, often on a more frequent monitoring cadence than your primary suppliers.
Corrections and removals: the software-specific interpretation most teams miss
The concept of corrections and removals as defined in FDA regulations maps onto software in ways that are not intuitive, and procedures written from a hardware mental model usually have gaps.
A hotfix that addresses a device malfunction is a correction. A version rollback is a removal. Both need to be evaluated for reportability under the applicable threshold: whether the action reduces a risk to health. If it does, the 10-day reporting clock for corrections starts. Procedures for corrections and removals need explicit language covering software scenarios, specifically hotfixes, version rollbacks, patch deployments, and third-party component updates that affect device behavior. Most procedures I review cover none of these explicitly.
Closing thought: use logic
SaMD and AI-enabled devices are not categorically different from other medical devices in terms of what the regulatory framework asks you to do. Identify the hazards, assess the risks, implement controls, verify they work, and document everything. The standards are more specific for software than for hardware in some areas, but the underlying structure is the same, and the documentation requirements for software submissions follow that same structure.
Most of the findings I see come from teams that have written documentation to satisfy a perceived checklist rather than to genuinely reflect how they manage risk and quality. Auditors are looking for whether your documentation tells a coherent story about how you built a safe device. When it does, inspections go well. When the documentation exists to fill folders without connecting to real quality decisions, auditors find the gaps.
Keep reading
If you are building out your SaMD compliance process, these related guides go deeper on the specific components:
- IEC 62304 software safety classes: what they are and how to apply them
- IEC 62304 and the software DHF: design controls that don't slow engineers down
- SaMD quality ops: why Jira and GitHub belong inside your QMS
- QMSR: your guide to 21 CFR Part 820
- What FDA investigators will look for under QMSR
- SaMD software documentation: 7 must-haves for premarket submissions
If you want to go deeper, including the Q&A where we covered benefit-risk analysis, software safety class justification, and specific audit scenarios in more detail, the on-demand recording is available at What auditors actually look for in software documentation.
BONUS RESOURCE: 3-in-1 SaMD Gap Assessment Tool
