Acceptance criteria are the predefined, measurable requirements a medical device, component, process step, or test result must meet to be judged conforming. They are set before testing begins, expressed in quantitative or clearly observable terms, and used to make an objective pass or fail decision during design verification, incoming inspection, and process validation.
What is Acceptance Criteria?
Acceptance criteria mark the boundary between a conforming result and a nonconforming one. They take the form of numeric ranges, pass/fail thresholds, or clearly defined qualitative conditions tied to a requirement, specification, or risk control. A design verification test might specify “leak rate below 0.5 mL per minute at 37 degrees C”; an incoming inspection procedure might specify “zero critical defects, AQL 1.0 for major defects” for a purchased component.
Acceptance criteria sit downstream of requirements. A design input states what the device must do; a specification turns that into a measurable parameter; the criterion sets the limit that parameter must meet to pass. Without criteria fixed before testing, there is no objective basis for a pass or fail call, and auditors treat that gap as a documentation failure.
Why Acceptance Criteria Matter in Medical Device Development
Weak or missing acceptance criteria create real risk. Without numeric limits set in advance, a team can unconsciously shift the bar after seeing results, a pattern auditors and FDA investigators are trained to spot. Under the FDA’s QMSR, effective February 2, 2026, design verification is governed by ISO 13485:2016 Clause 7.3.6, incorporated by reference into 21 CFR Part 820, and records only mean something if criteria were fixed beforehand.
Patient safety is the deeper stake. A sterilization validation with a vague criterion, “adequate sterility assurance,” gives a technician nothing to measure against. “Sterility assurance level of 10^-6 or better” is unambiguous, and the gap between the two can decide whether a latent failure mode reaches a patient.
Cost and schedule sit on the line too. Ambiguous criteria are a common root cause of failed design verification, forcing retesting and CAPA work that delays submissions. Reviewers examining a design history file will flag any report where the criterion was undefined or changed after the fact without rationale.
How Acceptance Criteria Are Set
Acceptance criteria trace back through a chain of inputs:
- Design inputs and user needs, describing intended function and performance.
- Risk management outputs under ISO 14971, flagging parameters where failure could cause harm.
- Applicable standards, such as IEC 60601-1 for electrical safety or IEC 62304 for software verification.
- Statistical sampling plans, such as ISO 2859-1, for lot acceptance rather than a single unit.
- Historical process capability data, reflecting what the process can realistically hold.
A well-formed criterion is specific, measurable, and testable with equipment on hand. “Strong enough” is not a criterion; “withstands 50 N of axial load without visible deformation, per test method TM-014” is. Criteria should state the sample size and statistical basis, since one passing sample proves far less than a validated confidence level.
Criteria belong in the protocol before execution, not the report after. Test protocols, inspection plans, and process validation protocols (IQ, OQ, PQ) each carry a dedicated section that the report references rather than restating.
Common Challenges and Best Practices
Teams go wrong in predictable ways. Criteria are written after the data already exists, erasing the objectivity they were meant to provide. Criteria get copied from a similar product without checking whether the failure modes or use environment match, or stated qualitatively when a quantitative limit was achievable, such as “passes visual inspection” for something a gauge could measure.
Good practice means writing the criterion alongside the test method, before any sample exists. An engineer confirms it is achievable, a quality reviewer confirms it traces to a design input or risk control, and someone confirms the sample size supports the confidence level claimed. Any change after sign-off follows the same change control as the protocol, with documented rationale, not a quiet edit.
Traceability matters as much as the number. Every criterion should link back to a design input or risk control and forward to the record that closes it out. Criteria that cannot be traced both ways are a predictable audit finding.
How SJML Helps with Acceptance Criteria
SJML’s engineering and quality teams build acceptance criteria into test protocols from the earliest design verification and validation planning, rather than adding them after the fact. Working across mechanical, electronics, embedded, and software disciplines, SJML ties each criterion back to design inputs and ISO 14971 risk controls and checks it against the relevant standard, whether IEC 60601-1 electrical safety or IEC 62304 software verification. In-house labs support electrical safety, EMC, and reliability testing, so criteria can be validated against real equipment rather than assumptions. SJML’s QARA team keeps protocols and records aligned for audit and submission readiness.
Talk to SJML’s engineering team →
Frequently asked questions
A specification defines a parameter and its target range, such as tensile strength or leak rate. Acceptance criteria define the pass or fail limit applied during a specific test or inspection, including sample size and method. A specification can exist without a test ever being run against it.
Approval typically involves a cross-functional group. Design engineering confirms feasibility, quality assurance confirms traceability to risk controls and design inputs, and regulatory affairs confirms alignment with applicable standards. The protocol is signed off before testing begins, and any later change follows formal change control.
Yes, when a parameter genuinely cannot be reduced to a number, such as certain visual defect assessments. The criterion should still be as specific as possible, referencing a defect catalog or reference sample, so that two independent reviewers reach the same pass or fail conclusion.
A failure triggers a nonconformance or deviation record, followed by a root cause investigation. Depending on the finding, this can lead to a design change, an updated risk assessment, a corrected criterion with rationale, or a retest. The original failing result stays in the record even after a later retest passes.
ISO 13485:2016 Clause 7.3.6 requires design verification to confirm outputs meet input requirements, which depends on defined acceptance criteria. The FDA’s QMSR, effective February 2, 2026, incorporates ISO 13485:2016 by reference into 21 CFR Part 820, so US manufacturers now follow the same clause structure as the rest of the world.
Related terms
- Design Verification
- Design Validation
- Design History File (DHF)
- Process Validation (IQ/OQ/PQ)
- Sampling Plan (AQL)
