Software Quality Assurance Compliance Standards
Software quality assurance (SQA) compliance standards define the structured requirements that development organizations, regulated industries, and government contractors must meet to demonstrate that software behaves as intended, is traceable to documented requirements, and does not introduce unacceptable risk into systems that rely on it. This page covers the principal regulatory frameworks, how SQA compliance is implemented through defined process stages, the common deployment contexts where these requirements arise, and the classification boundaries that determine which standard applies in a given situation. Understanding these distinctions is foundational to building a quality management system that satisfies audit, certification, and regulatory expectations simultaneously.
Definition and scope
Software quality assurance compliance refers to conformance with a documented set of requirements governing how software is planned, developed, tested, controlled, and released. The scope varies significantly by sector. In medical devices, the U.S. Food and Drug Administration's 21 CFR Part 820 — the Quality System Regulation — and its successor framework aligned with ISO 13485 impose mandatory SQA obligations on device manufacturers. In aerospace and defense, DO-178C, published by RTCA and adopted by the FAA under Advisory Circular AC 20-115D, establishes five levels of software criticality (Levels A through E), each with progressively stringent verification requirements. In financial services, the Office of the Comptroller of the Currency issues guidance on technology risk management that includes software development lifecycle controls.
The IEC 62304 standard, published jointly by ISO and IEC, addresses medical device software lifecycle processes and defines three software safety classes — Class A (no injury), Class B (non-serious injury), and Class C (serious injury or death) — which directly determine the depth of required testing and documentation. ISO/IEC 25010, the Systems and Software Quality Requirements and Evaluation (SQuaRE) standard, provides a quality model that defines eight product quality characteristics, including functional suitability, reliability, and security.
How it works
SQA compliance is implemented through a lifecycle of discrete, auditable phases. The following structure reflects the framework described in IEEE Std 730-2014, the IEEE Standard for Software Quality Assurance Processes:
- SQA Planning — A Software Quality Assurance Plan (SQAP) is drafted before development begins, identifying applicable standards, audit checkpoints, roles, and metrics. The SQAP must reference the specific version of any governing standard.
- Requirements traceability — Each functional requirement is assigned a unique identifier and traced forward through design, code, and test artifacts. Gaps in traceability are treated as nonconformances under most frameworks, including FDA 21 CFR Part 820.30.
- Code and design review — Formal inspection records document findings against defined entry and exit criteria. DO-178C, for example, mandates structural coverage analysis at the Modified Condition/Decision Coverage (MC/DC) level for Level A software.
- Testing and verification — Test plans, test cases, and test results are version-controlled and retained. Validation and verification compliance requirements differ: verification confirms that the software was built correctly; validation confirms it was the right software to build.
- Nonconformance and corrective action — Defects discovered during testing or post-release trigger a documented nonconformance process, feeding into CAPA compliance requirements where applicable.
- Configuration and change control — Every change to a controlled artifact — source code, test script, or specification — is logged, reviewed, and approved before merge. The governing principle is full traceability from change request to release.
- Audit and closure — Independent SQA audits verify that the SQAP was followed. Audit records are retained per the retention schedules specified in the applicable regulation or standard.
Common scenarios
Medical device software. A manufacturer developing firmware for an infusion pump must satisfy both FDA 21 CFR Part 820 and IEC 62304. The software is classified as Class C under IEC 62304, triggering full lifecycle documentation, a unit-level test suite, and mandatory anomaly resolution records.
Aerospace software. A supplier writing flight management code for a commercial aircraft must achieve DO-178C Level A compliance, requiring 100% MC/DC structural coverage, independent review of all verification outputs, and a tool qualification process for any automated test tool that generates outputs used as verification evidence.
Federal government IT. A contractor delivering software to a civilian agency must satisfy the NIST SP 800-53 control baseline assigned to the system's impact level. The SA (System and Services Acquisition) and SI (System and Information Integrity) control families directly impose software development and testing requirements.
Automotive software. Suppliers to OEMs certified under IATF 16949 must meet ASPICE (Automotive SPICE) process assessments alongside functional safety requirements in ISO 26262, which uses an Automotive Safety Integrity Level (ASIL) classification from ASIL A through ASIL D.
Decision boundaries
The selection of an applicable SQA standard is not discretionary — it follows from product category, intended use, and the regulatory jurisdiction of the market in which the product is released.
| Criterion | Applicable Standard |
|---|---|
| FDA-regulated medical device software | IEC 62304, FDA 21 CFR Part 820 / QSR |
| FAA-certified airborne software | DO-178C (RTCA) |
| Federal IT systems | NIST SP 800-53, FIPS 140-3 |
| Automotive safety-critical software | ISO 26262, ASPICE |
| General software product quality | ISO/IEC 25010 |
A key contrast exists between prescriptive and risk-based frameworks. DO-178C is largely prescriptive: it specifies exactly which objectives must be satisfied at each software level. IEC 62304, by contrast, scales requirements to software safety class, granting more flexibility at Class A while imposing comprehensive controls at Class C. Organizations operating under risk-based compliance QA approaches must document the rationale for any scoping decisions that reduce the applied control set, and those decisions must survive third-party audit scrutiny.
References
- FDA 21 CFR Part 820 — Quality System Regulation (eCFR)
- NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems
- IEEE Std 730-2014 — Software Quality Assurance Processes (IEEE Standards)
- ISO 13485 — Medical Devices Quality Management Systems (ISO)
- IEC 62304 — Medical Device Software Lifecycle Processes (ISO)
- ISO/IEC 25010 — Systems and Software Quality Requirements (ISO)
- FAA Advisory Circular AC 20-115D — RTCA DO-178C (FAA)
- RTCA DO-178C Publication Reference (RTCA)