510k software: documentation, change decisions, and eSTAR mapping

Overview

FDA's 2023 guidance, Content of Premarket Submissions for Device Software Functions, replaced the older lines-of-code framework with a risk-based documentation level system. Every 510(k) that includes device software functions must now be mapped to either a Basic or Enhanced documentation level, and the artifacts submitted must reflect that determination.

Getting the level wrong—or submitting the right level with incomplete evidence—is one of the most common reasons software submissions receive a Refuse to Accept (RTA) decision before substantive review begins.

This article is written for regulatory affairs leads, QA managers, and software engineering leads who are either building a 510(k) software package from scratch or evaluating whether a change to a cleared device requires a new submission. It covers how to select and justify a documentation level, what artifacts belong in each section of eSTAR, how to apply FDA's software-change decision logic with worked examples, and how to handle cybersecurity, AI/ML, predicate selection, and usability evidence. The goal is a package that passes acceptance review and holds up under substantive scrutiny.

---

FDA's software documentation levels at a glance

Tie this section to FDA's risk-based shift and decide which documentation level fits your device. FDA's 2023 guidance moved away from lines of code as a proxy for documentation depth because LOC is a poor predictor of clinical risk. The replacement framework asks manufacturers to assess the risk contributed by the software itself—hazard severity, the degree to which the software controls or influences patient outcomes, and whether a failure could cause or contribute to serious injury or death.

Basic documentation level applies when a software failure would result in minor injury or no injury, or when the software plays only an indirect role in a hazardous situation. At Basic level, FDA expects a description of the device and software, a high-level software architecture overview, a summary of the software development lifecycle (SDLC) process, and a summary of verification and validation activities. The documentation standard is intentionally lighter because the risk profile does not warrant the full audit trail required at Enhanced.

Enhanced documentation level applies when a software failure could contribute to serious injury or death, or when the software plays a direct causal role in a hazardous situation. At Enhanced, FDA expects the full set of software documentation artifacts: a complete Software Requirements Specification (SRS), detailed architecture and design documentation, full traceability from requirements through risk controls to tests, complete V&V protocols and results, SOUP/OTS documentation, a cybersecurity bill of materials and vulnerability management plan, and a list of unresolved software anomalies with risk rationale.

Selecting the level is a device-specific risk judgment, not a checkbox exercise. Document the reasoning explicitly in your submission—FDA reviewers expect to see the rationale, not just the label.

Mapping IEC 62304 safety class to FDA documentation levels (and why it's not one-to-one)

Start this mapping from your ISO 14971 hazard analysis and use IEC 62304 as supporting evidence. IEC 62304 classifies software units into Class A (no injury or damage to health possible), Class B (non-serious injury possible), and Class C (serious injury or death possible). These classes can inform your Basic vs Enhanced selection, but they are not a direct substitute for FDA's risk-based documentation level analysis.

The key difference is scope. IEC 62304 classification is determined at the software unit level and drives lifecycle activities within your development process. FDA's documentation level is determined at the submission level and drives what evidence you present to the agency. A device with only Class A and Class B software units might still warrant Enhanced documentation if the overall hazard analysis under ISO 14971 identifies unacceptable risk scenarios tied to software failure modes. Conversely, a device with some Class C units may have strong risk controls that, when documented thoroughly, support a well-justified Enhanced submission without inflated artifact scope.

The most defensible approach is to complete your ISO 14971 risk analysis first and identify which software failure modes contribute to hazardous situations. Use that analysis as the primary rationale for your documentation level selection and reference your IEC 62304 classifications as corroborating evidence, not as the determinative factor. FDA has made clear that the guidance does not require a one-to-one correspondence with 62304 safety classes.

---

What belongs in a 510(k) software package

The 2023 FDA guidance defines what to include at each documentation level, but the exact scope depends on your architecture, deployment model, and risk profile. Link the artifact set to the documentation level decision, then determine which artifacts you must produce before drafting begins.

Software in a medical device (SiMD)—such as firmware in an infusion pump—and software as a medical device (SaMD)—such as a standalone clinical decision support application—both require device software documentation, though the architecture evidence looks different for each. SaMD performs its medical purpose without being part of a hardware medical device. This distinction matters for architecture diagrams, deployment environment descriptions, and cybersecurity scope.

The sections below address each artifact category: what strong submissions include and where submissions commonly fall short.

SRS, architecture, and traceability

Per FDA guidance, the SRS and architecture form the documentary basis reviewers use to evaluate risk and V&V scope. The Software Requirements Specification should enumerate functional requirements, performance requirements, and safety-critical requirements clearly enough that a reviewer can trace each requirement to a hazard or risk control in the risk management file and to a test case in the V&V record. Ambiguous or incomplete requirements are the most upstream deficiency in any software submission, and they cascade into weak traceability and gaps in test coverage.

The architecture documentation should include a system architecture diagram showing major hardware and software components, data flows, and interfaces, as well as a software architecture diagram showing software items, their dependencies, and interfaces between them. Describe the execution environment, including operating system, hardware platform, and any cloud infrastructure where applicable. For cloud-deployed SaMD, also describe the multi-tenant isolation model, data storage and processing locations, and how the architecture supports availability and integrity under failure scenarios.

Worked traceability example: Requirement REQ-047 requires the software to display a low battery alert when battery reserve falls below 15%. The linked hazard is unexpected device shutdown during active therapy (severity: serious injury; probability before control: possible). The risk control is a software-enforced alert at the 15% threshold, confirmed by design testing. Test case TC-112 simulates battery at 14%, 15%, and 16% capacity and verifies alert behavior; the pass criterion is alert presence in 100% of trials at or below threshold. This slice—one requirement, one linked hazard, one risk control, one test case with pass criterion—is the minimum granularity FDA expects at Enhanced level. Your traceability matrix should cover all safety-critical requirements at this depth.

Verification and validation (including regression strategy)

Verification confirms that the software was built correctly against its specifications; validation confirms that the correct software was built for its intended use. Both are expected at Enhanced level; summaries suffice at Basic level.

Verification documentation should include unit test results, integration test results, and system-level test results with test protocols, results, and pass/fail determinations. For software with safety-critical functions, include code review records or static analysis results referencing MISRA C or an equivalent standard, depending on what your SDLC specifies. Validation documentation should include usability-informed simulated use or clinical use testing demonstrating the software performs as intended for its labeled indication.

Regression strategy is especially important when submitting a 510(k) for a software modification rather than a new device. FDA's software-change guidance expects manufacturers to demonstrate that changes did not introduce new failure modes in previously verified functionality. A strong regression record identifies which requirements were affected by the change, which test cases were re-executed, and the outcome of re-execution. This evidence supports both the 510(k) package and your internal change-control rationale if a future change is assessed as non-reportable.

SOUP/OTS and supplier assurance

Software of Unknown Provenance (SOUP) and off-the-shelf (OTS) software components must be documented because they introduce risk from sources outside your direct development control. IEC 62304 Section 8 defines the lifecycle requirements for SOUP, and FDA's 2023 guidance expects evidence that you have identified, evaluated, and monitored these components.

For each SOUP item, your documentation should include the component name, version, and supplier; the intended function within your device; the failure modes introduced by the component and how they are addressed in your risk analysis; the validation approach (qualification testing, supplier documentation review, or combination); and the ongoing vulnerability monitoring process.

Example SOUP risk rationale entry: Component OpenSSL 3.1.4 (TLS communication library), supplier OpenSSL Project, intended to encrypt data in transit. Failure modes considered include cryptographic vulnerabilities and memory corruption. Risk controls include version pinning, CVE monitoring via NVD feeds with a 30-day patch SLA for critical severity, supplier release note reviews at each update, and regression test suite re-execution after patches. Validation included integration testing of TLS handshake, certificate validation, and graceful failure on expired or revoked certificates. This level of specificity—supplier, version, function, failure modes, controls, and validation—is what distinguishes a defensible SOUP record from a boilerplate component list.

Version history and unresolved software anomalies

The version history should list all released software versions, the date of each release, and a summary of changes between versions. For submissions covering a new version of previously cleared software, this history establishes the chain from the cleared version to the submitted version and supports the change impact assessment.

Unresolved software anomalies are open defects that exist in the submitted software version. FDA does not require zero open defects at clearance; it requires evidence that each open defect has been evaluated for safety impact. The evaluation should determine whether the anomaly can cause the software to operate outside its intended performance, whether a workaround exists, and what the residual risk is after applying the workaround.

Example anomaly entry: ANO-0043 describes a 3–5 second refresh delay in the trending graph UI under high network latency (>500 ms). Severity is Minor because the primary numerical readout—used for clinical decisions—is unaffected. The risk rationale explains why clinical impact is negligible, the workaround is manual refresh and labeled guidance, and the planned resolution is targeted for the next maintenance release. FDA reviewers evaluate both the completeness of the anomaly list and the quality of the risk rationale; a thorough list with clear reasoning demonstrates a mature SDLC.

Cybersecurity artifacts under FD&C Act 524B

Section 524B of the FD&C Act, effective for submissions on or after March 29, 2023, establishes statutory cybersecurity requirements for "cyber devices"—devices that include software and can connect to the internet. For these devices, a 510(k) software package must include a specific set of cybersecurity artifacts beyond what the 2023 software documentation guidance requires.

The required elements under 524B, aligned with FDA's cybersecurity premarket guidance, include:

• Cybersecurity plan covering monitoring, identification, and postmarket vulnerability response, including a coordinated vulnerability disclosure (CVD) policy and procedures.
• Software Bill of Materials (SBOM): a machine-readable inventory of commercial, open-source, and off-the-shelf components; FDA recognizes SPDX and CycloneDX formats.
• Threat modeling addressing assets, threat actors, attack surfaces, and mitigations, with methodology (e.g., STRIDE) explained and mapped to controls.
• Vulnerability handling: process evidence for receiving and triaging reports with defined timelines.
• Security testing evidence: results from penetration testing, fuzzing, or static analysis appropriate to the threat model.
• Cybersecurity-related labeling such as hardening guidelines, network ports and protocols, and component information for secure operation.

For devices that are not "cyber devices" under the statutory definition—devices that do not connect to the internet—these 524B requirements do not apply, though FDA may still request a cybersecurity risk assessment as part of a general risk management review. Document your connectivity determination and rationale explicitly.

Usability and interoperability evidence

FDA's human factors guidance applies when use error could result in harm. For software-driven medical devices with clinical user interfaces—particularly SaMD used by clinicians to make or inform treatment decisions—usability testing is generally expected as part of the 510(k) package. The key question is whether use-related risks have been characterized and mitigated through design.

At a minimum, include a summary of formative and summative usability evaluations referencing IEC 62366-1 (Application of usability engineering to medical devices). If summative testing was conducted with end users, include the test protocol, participant selection rationale, use scenario definitions, and results. Where use errors were identified, document the design modifications made in response and the re-evaluation evidence. For devices where the user interface is administrative only and no clinical decision is influenced by the UI, a documented rationale for reduced usability testing scope may be acceptable—but the rationale must be explicit.

Interoperability testing applies when the device exchanges data with other medical devices or health IT systems. If your device uses HL7 FHIR to transmit clinical data to an EHR, include test results demonstrating conformance to the applicable FHIR profiles and error handling behavior under connectivity failure. If your device communicates using DICOM, include DICOM conformance testing evidence. Place interoperability test protocols and results in the V&V section of eSTAR alongside other system-level testing, and cross-reference them from the software architecture documentation where interfaces are described.

---

eSTAR section mapping for software artifacts (mini checklist)

The electronic Submission Template and Resource (eSTAR) is the current format for 510(k) submissions. It organizes content into a structured PDF-based template with named sections. Misplacing software artifacts—or omitting required attachments in favor of inline text where a separate file is needed—is a direct cause of RTA decisions. The following mapping reflects where FDA expects each major software artifact to appear.

• Device Description (Section 10): High-level description of the software, its intended use, the operating platform, and the deployment environment (cloud, embedded, standalone). Include the software version under review.
• Software Documentation (Section 15): The primary home for all software lifecycle artifacts—SRS, architecture diagrams, SDLC summary, V&V protocols and results, traceability matrix, SOUP/OTS list, version history, and unresolved anomalies list. At Basic level, summaries are acceptable; at Enhanced level, complete documents are expected, either embedded or as named attachments.
• Risk Management (Section 16): ISO 14971 risk management summary; cross-reference the traceability matrix from Section 15 to show how software-related hazards are controlled.
• Cybersecurity (Section 18): SBOM, threat model, CVD policy, security testing summary, and vulnerability handling procedures for cyber devices under 524B. Do not split these across sections—FDA reviewers expect cybersecurity artifacts to appear together here.
• Human Factors / Usability (Section 19): Summative usability evaluation results, critical task analysis, and use error summaries. For formative-only submissions (no summative), include the rationale.
• Labeling (Section 12): Cybersecurity-specific labeling elements (ports, protocols, hardening guidelines) belong here as part of the device labeling package, not in the cybersecurity section.
• Performance Testing (Section 17): Interoperability test results (FHIR, DICOM, IHE) and system-level performance testing that is not part of the software V&V protocols.

Common RTA misplacements include placing the SBOM in software documentation instead of the cybersecurity section, including only summaries in Section 15 for an Enhanced-level submission when complete documents are required, and omitting the version history entirely—which FDA treats as a missing required element rather than an incomplete one.

---

When a software change requires a new 510(k)

FDA's guidance Deciding When to Submit a 510(k) for a Software Change to an Existing Device provides the decision framework for cleared software. The core principle is that a new 510(k) is required when a software change could significantly affect the safety or effectiveness of the device—specifically, when it could introduce or modify a risk that was not assessed in the cleared submission. Not every software change meets this threshold, and many can be managed through internal change control without a new submission.

The decision is not binary. It requires a device-specific risk and performance analysis for each change. If the software changes affect clinical performance—the way the device acquires, processes, or displays clinically relevant data—a new 510(k) is generally required. Changes that are purely corrective and restore the device to its most recently cleared specification may not require a new submission, provided they do not introduce new failure modes or change the operating envelope.

Decision tree with worked examples

The FDA software-change guidance asks three sequential questions. Work through them in order and document your conclusion for each change.

Step 1: Could the change introduce a new risk or modify an existing risk identified in the original risk management file?

Step 2: If yes—could that modified risk affect clinical performance, intended use, or the safety profile of the device?

Step 3: If yes—does the risk analysis and V&V evidence support a finding that the device remains as safe and effective as the cleared version without new FDA review?

If Step 3 cannot be answered affirmatively with documented evidence, a new 510(k) is required. The following four scenarios illustrate where this logic lands in practice.

Scenario A — UI workflow change (no new 510(k)): A cleared vital signs monitor is updated to reorder the display of parameters on the primary screen. The clinical data displayed is unchanged; only the layout changes. Risk analysis confirms no safety-critical parameter is hidden or deprioritized. Usability review finds no increase in use error risk. V&V regression confirms the underlying data acquisition and alarm functions are unaffected. Outcome: Internal change control; no new 510(k).

Scenario B — Algorithm parameter change (new 510(k) required): A cleared arrhythmia detection SaMD is updated to adjust the sensitivity threshold for atrial fibrillation detection. The change affects clinical performance—detection rate, false positive rate, and specificity all shift. This is a direct modification to the intended use performance. Outcome: New 510(k) required; clinical performance evidence for the new threshold must be submitted.

Scenario C — New data input source (new 510(k) required): A cleared clinical decision support tool that previously accepted only EHR-sourced lab values is updated to also accept patient-reported data entered via a mobile app. The input data quality, provenance, and validation requirements differ from the original cleared configuration. Intended use expands, and new failure modes are introduced (unvalidated patient-reported values influencing clinical recommendations). Outcome: New 510(k) required.

Scenario D — Cloud infrastructure change (assess carefully): A cleared SaMD moves from on-premises deployment to a cloud-based architecture. The clinical algorithm is unchanged, but the operating environment, availability model, data latency, and cybersecurity architecture all change materially. Risk analysis must evaluate whether the new infrastructure introduces latency affecting time-critical functions, whether availability meets the original performance specification, and whether the cybersecurity posture is at least equivalent. If the analysis supports equivalence with documented evidence, internal change control may be defensible; if any of these questions cannot be affirmatively resolved, a new 510(k) is appropriate. Outcome: Risk-analysis dependent; Pre-Submission recommended.

One edge case worth flagging: patches labeled as "bug fixes" that alter alarm thresholds, change output values, or modify user workflow logic are functionally algorithm or UI changes. Apply the same decision logic, not a lower bar because the change was motivated by a defect.

Choosing Traditional vs Special vs Abbreviated for software modifications

For most software modifications that do require a new 510(k), the Traditional 510(k) path is standard—you are demonstrating substantial equivalence to a cleared predicate with new software documentation reflecting the changed version.

The Special 510(k) pathway is available for certain device modifications made by the original manufacturer. FDA has indicated that software changes may be eligible when the modification does not affect the intended use or alter the fundamental scientific technology and can be validated through design controls. The Abbreviated 510(k) pathway is available when a recognized standard covers the modification; some IEC 62304 and ISO 14971 conformance declarations can support abbreviated submissions, though the standard must be directly applicable to the modified device and function.

For cybersecurity-only changes—such as a patch that updates a SOUP component to remediate a critical CVE—FDA has provided flexibility. If the change strictly addresses a security vulnerability without altering clinical functionality, it may be manageable through internal change control. However, if the patch changes authentication steps, introduces processing latency affecting time-critical functions, or modifies user workflow in ways that could change use-error risk, the cybersecurity framing does not exempt it from the broader change-analysis requirement.

---

Picking a predicate for software devices

A 510(k) demonstrates to FDA that the device to be marketed is at least as safe and effective as a legally marketed predicate. For software-based medical devices, predicate selection introduces additional nuance because the cleared device's software claims, architecture, and intended use must be compatible with the substantial equivalence argument.

Start with product code identification. FDA's product classification database organizes cleared devices by product code, which maps to a classification panel and an associated device type. For SaMD, the most relevant product codes depend on the clinical function—diagnostic imaging software, clinical decision support, and patient monitoring each have distinct codes with different special controls. Your device's intended use must align with the product code's definition; choosing a predicate with a different product code is not automatically disqualifying, but you must explain why the technological characteristics are substantially equivalent despite the different code.

Special controls are the conditions attached to Class II devices that provide reasonable assurance of safety and effectiveness. For many software devices, special controls include performance testing standards, cybersecurity requirements, and labeling specifications. Your 510(k) must demonstrate compliance with the special controls applicable to your predicate's product code, not just technological similarity to the predicate device itself.

Common substantial equivalence pitfalls for software devices include: selecting a predicate based on clinical indication alone while ignoring differences in algorithm type or input data (for example, a pixel-based imaging algorithm versus a rule-based diagnostic algorithm); selecting a predicate cleared before cybersecurity special controls were established and then arguing that cybersecurity documentation is not required; and selecting a predicate with a narrower intended use while claiming equivalence for an expanded population or clinical context. In each case, the technological characteristics differ in ways that raise new questions of safety and effectiveness—which either requires performance data to bridge the gap or disqualifies the predicate.

---

AI/ML considerations, including PCCP in a 510(k) context

AI/ML software in a 510(k) requires the same core documentation as any device software function—SRS, architecture, V&V, traceability, SOUP, and unresolved anomalies—but several additional disclosure elements apply to the model itself. FDA expects a description of the training data (clinical setting, patient population, and data collection methodology), the model architecture and training approach, and performance metrics from a locked, prospectively defined test set not used during training or tuning.

A key submission risk for AI/ML devices is overstating generalizability. If the model was trained on data from three academic medical centers, the claims in the indications for use and in the performance summary must reflect that scope. A mismatch between training data representativeness and the claimed intended-use population is a common source of substantive review questions that delay clearance.

The Predetermined Change Control Plan (PCCP) is a mechanism FDA has been developing to allow manufacturers to describe certain anticipated modifications to AI/ML-based software in advance, gaining agreement on how those changes will be validated without requiring a new 510(k) for each update. In a 510(k) context, a PCCP describes the modification protocol (what can change), the impact assessment protocol (how changes will be evaluated), and the performance monitoring plan (how the device will be watched post-deployment). FDA has continued developing this framework; as of the current regulatory environment, including a PCCP is not universally required for AI/ML devices but is increasingly expected where model retraining is part of the intended lifecycle.

If you include a PCCP, the plan must be specific enough that a reviewer can assess whether proposed changes remain within the scope of the cleared intended use and whether the validation methodology is adequate to detect performance degradation. Rollback planning—documenting the version to which the device would revert if a post-market update fails performance thresholds—is a practical element that supports both the PCCP and the software lifecycle documentation. Include it in the architecture documentation alongside the software update mechanism description.

---

Pre-Submission strategy for software

A Pre-Submission (Q-Sub) meeting with FDA is an underused tool for software-heavy 510(k)s. It is most valuable when you face genuine uncertainty about documentation level, cybersecurity scope, or whether a predicate will support your intended-use claims. Submitting a well-formed Q-Sub question set before finalizing the eSTAR package can prevent documentation-level disputes during substantive review and surface reviewer expectations for novel software architectures or AI/ML disclosures.

Targeted questions worth raising in a Pre-Sub for software include:

• Documentation level confirmation: Present your risk analysis summary and proposed documentation level; ask whether FDA agrees the device qualifies for Basic or Enhanced based on the described failure modes and hazard severity.
• Cybersecurity scope confirmation: For devices near the boundary of the "cyber device" definition under 524B, ask whether the device's connectivity profile triggers the full 524B artifact set or whether a reduced cybersecurity assessment is acceptable.
• Predicate acceptability: Present your proposed predicate and explain the intended use and technological characteristics alignment; ask whether FDA agrees the predicate is a reasonable basis for substantial equivalence.
• AI/ML disclosure scope: If including a PCCP, present the proposed modification protocol and validation methodology; ask whether the plan is sufficiently specific to support post-market changes without a new submission.
• Interoperability validation approach: If the device exchanges data with other medical devices and the test methodology is novel or non-standard, ask whether the proposed evidence type is acceptable.

Submit the Q-Sub at least four to six months before your planned eSTAR filing to allow time for FDA's response and any necessary documentation adjustments.

---

Common eSTAR RTA deficiencies for software—and how to avoid them

RTA decisions for software submissions most often reflect structural or completeness issues rather than substantive disagreements about safety. The following deficiencies appear repeatedly and are preventable with a pre-submission completeness review.

• Missing documentation level rationale. Submitting software artifacts without a documented rationale for Basic vs Enhanced causes FDA to treat the selection as unsupported. Fix: include a one-to-two paragraph rationale in Section 15 citing your ISO 14971 analysis and the specific failure modes that drove the level selection.
• SRS that lacks safety-critical requirements. An SRS limited to functional requirements without explicit safety, performance boundary, and error-handling requirements is incomplete at Enhanced level. Fix: verify that the SRS addresses failure mode scenarios, not just nominal use cases.
• Traceability matrix that omits risk links. A requirements-to-tests matrix without the risk management bridge fails to demonstrate that risk controls are verified. Fix: add a risk control column linking each safety-critical requirement to the corresponding risk management file entry.
• SOUP list without version pinning or vulnerability monitoring. A generic list of third-party libraries without specific versions or monitoring procedures is insufficient. Fix: use the format described in the SOUP/OTS section above, with version, supplier, failure modes, and monitoring approach for each component.
• Cybersecurity artifacts split across sections. Placing the SBOM in Section 15 and the threat model in a general risk section causes reviewers to flag incomplete cybersecurity documentation even when all elements are present. Fix: consolidate all 524B artifacts in Section 18.
• Unresolved anomalies list that only contains "none." While a zero-anomaly list is acceptable if accurate, it is frequently questioned. Fix: if the list is genuinely empty, include a brief statement confirming that the anomaly resolution process was completed prior to submission with a reference to the final anomaly closure report.
• Missing version history for modification 510(k)s. Omitting the version history when submitting a new 510(k) for a software change leaves FDA without the change chain. Fix: include a version history table covering at minimum the cleared version and all intermediate versions up to the submitted version.

Addressing these structural items before filing resolves most RTA findings and shortens the acceptance cycle.

---

Software 510(k) readiness checklist (10 quick checks)

Run this checklist as your final structural and evidence pre-check before uploading your eSTAR package. These reflect the most common gaps identified in acceptance reviews.

1. Documentation level rationale documented — ISO 14971-based reasoning for Basic or Enhanced is written into Section 15, not implied.

2. SRS covers safety-critical requirements — error handling, performance limits, and failure mode behavior are specified, not just nominal functions.

3. Traceability matrix spans requirements → risk controls → test cases — every safety-critical requirement has a risk file link and a corresponding test result.

4. V&V protocols and results are complete — test cases include pass criteria; results show actual vs expected outcomes; regression scope is documented for modifications.

5. SOUP/OTS entries include version, function, failure modes, and monitoring — no generic component lists without risk context.

6. Version history covers the chain from cleared to submitted version — intermediate versions are listed with change summaries.

7. Unresolved anomalies include risk rationale for each open item — not a blank list and not a list without severity or residual risk assessment.

8. Cybersecurity artifacts are consolidated in Section 18 — SBOM (SPDX or CycloneDX format), threat model, CVD policy, and security test summary are all present if the device is a cyber device under 524B.

9. Usability evidence matches the risk profile — summative testing is included if use error could result in serious injury; rationale for reduced scope is documented if not.

10. Predicate selection is documented with intended-use and technological characteristics alignment — the basis for substantial equivalence is explicit, including any differences and why they do not raise new safety questions.

Once the checklist confirms all items, the filing decision reduces to a straightforward go/no-go: if any item remains unresolved, treat it as a gap to close before submission rather than a risk to carry into the review cycle. Teams that cannot clearly confirm an item should assign an owner, set a resolution date, and recheck before filing.

Managing the review cycle for a software 510(k) involves the same coordination challenges as any complex submission: version alignment across authors, QA review of final documents, and readiness confirmation before filing. Teams that keep regulatory, quality, and software reviewers working from the same controlled document set—rather than exchanging files by email—consistently close review cycles faster and with fewer last-minute deficiency corrections. Assyro's AI regulatory submission workspace supports this by allowing authors, RA, RegOps, and QA to review against the same controlled sequence state, with shared owners, comments, and traceability that reduce the version drift causing late-stage rework. For teams that also want a fast structural pre-check on eCTD packages within a broader regulatory program, Assyro's free eCTD validator runs 358 CFR, ICH, and FDA TRC checks across Modules 1–5 locally in the browser without sending files to a server—catching formatting issues before they become findings.