Complaint handling is a core quality system requirement under both FDA QMSR and ISO 13485. This guide covers what the regulations require, how to build a complaint management process that satisfies both, and where companies most commonly fall short.

What FDA QMSR requires

FDA QMSR (21 CFR Part 820), which took effect in February 2026 and replaced the prior Quality System Regulation, incorporates ISO 13485:2016 by reference. For complaints, the relevant requirements appear in ISO 13485 Clause 8.2, which the QMSR adopts with specific additions for U.S. device manufacturers.

Under QMSR, manufacturers must maintain complaint files. Each complaint must be evaluated to determine whether it represents a reportable event under 21 CFR Part 803 (Medical Device Reporting). If a complaint involves a device that may have caused or contributed to serious injury or death, or if a device malfunction could cause serious injury if it recurred, an MDR report to FDA is required within specific timeframes.

Additionally, 21 CFR Part 820.198 (the prior regulation’s complaint file requirement, now carried into QMSR) requires that procedures for receiving, reviewing, and evaluating complaints be established, that complaints be evaluated to determine whether an investigation is necessary, and that investigation findings and conclusions be documented.

What ISO 13485 requires

ISO 13485:2016 Clause 8.2.2 requires that procedures for handling customer feedback, including complaints, be defined and maintained. The organization must maintain records of complaint investigations. If an investigation determines that an activity outside the organization contributed to the complaint, relevant information must be exchanged between the organization and that party.

Clause 8.2.3 adds requirements specific to reporting to regulatory authorities. If a complaint meets the criteria for a reportable adverse event in any jurisdiction where the device is distributed, the organization must report to the relevant authority and maintain records of that report.

Together, these requirements create four distinct obligations: receive and log, investigate, report to regulators where required, and link findings to corrective action.

Define what counts as a complaint

Before building your complaint process, define what a complaint is. ISO 13485 defines a complaint as “written, electronic, or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, safety, effectiveness, or performance of a medical device after it has been released for distribution.”

The definition is broad. A sales call where a customer mentions that a device is harder to use than expected can be a complaint. An email asking whether a device can be used in a different way than labeled is a complaint. A service technician’s note that a device was found with a defect is a complaint.

The most common intake failure in complaint management is informal filtering: sales teams or customer service representatives deciding on their own that a customer concern is “not really a complaint” and not passing it to the quality team. Your complaint SOP must require that all personnel who receive any feedback about a distributed device route it to the complaint intake process, without pre-filtering. The quality team makes the determination of whether something qualifies as a complaint, not the person who received the call.

Step 1: Complaint intake and logging

Every potential complaint must be logged as soon as it is received. The initial log should capture:

• Date received
• How received (phone, email, field service report, sales team relay)
• Complainant information (name, contact, customer ID if applicable)
• Device identification (product name, lot number, serial number, model)
• Description of the complaint in the complainant’s own words
• Any patient or user harm alleged
• Whether the device is available for return or evaluation

Log every complaint, including those you subsequently determine do not require investigation. The record of having received and evaluated a complaint is itself a regulatory requirement.

Step 2: Determine whether investigation is required

Not every complaint requires a formal investigation. Your procedure should define the criteria for when investigation is required and when it is not.

Investigation is generally required when:

• The complaint alleges device malfunction, failure, or deterioration in performance
• The complaint alleges patient or user injury or illness
• The complaint involves a device with a lot or serial number that could be linked to other field units
• The complaint description suggests a potential systemic quality issue
• The complaint involves a device that may need to be returned for evaluation

Investigation may not be required when the complaint relates to user error with no device defect, misuse outside the labeled intended use, or a documented known characteristic of the device that has already been addressed in labeling or instructions.

Whatever your criteria, document the evaluation decision and the reason. “No investigation required” is not a sufficient record. “No investigation required: complaint describes user error in operating the device outside the labeled intended use; no device defect alleged; patient outcome not reported as adverse” is a sufficient record.

Step 3: Conduct the investigation

A complaint investigation must determine whether a device defect exists and, if so, identify the root cause. The depth of investigation should be proportionate to the severity of the complaint and the potential impact on patient safety.

A complaint investigation typically includes:

• Review of device production and testing records for the identified lot or unit
• Review of incoming inspection records for components used in the affected lot
• Physical evaluation of the returned device, if available
• Review of any other complaints for the same device or lot
• Review of the device’s complaint history for similar events
• Root cause analysis when a defect is confirmed

Document your investigation methodology, findings, and conclusions. If a root cause cannot be determined, document what was investigated and why a root cause could not be confirmed. An inconclusive investigation that is thoroughly documented is defensible. An investigation record that simply says “investigated, no defect found” is not.

Step 4: Evaluate for MDR reporting

Every complaint involving a U.S.-distributed device must be evaluated for MDR reporting under 21 CFR Part 803. The evaluation must be documented even when the conclusion is that reporting is not required.

MDR reporting is required if the device may have caused or contributed to:

• A death
• A serious injury (a life-threatening condition, a permanent impairment, or a condition requiring medical or surgical intervention to prevent such outcomes)
• A device malfunction that, if it were to recur, would be likely to cause or contribute to death or serious injury

Timeframes matter. A death or serious injury requires an MDR within 30 calendar days of becoming aware. A malfunction MDR has the same 30-day window. Five-day reports are required for events that require remedial action to prevent an unreasonable risk of substantial harm to public health.

Missed or late MDR reports are one of the most common complaint-related observations in FDA warning letters. Build MDR evaluation explicitly into your complaint workflow, with a defined decision point and a documented evaluation record for every complaint.

Step 5: Link to CAPA where required

Not every complaint requires a CAPA. A complaint that represents an isolated event with no identified systemic cause may be closed after investigation without a corrective action. But when investigation identifies a root cause that could affect other devices or future production, a CAPA must be initiated.

Your complaint procedure should define the criteria for CAPA initiation. Common triggers:

• A confirmed device defect linked to a manufacturing or design root cause
• A complaint trend: the same complaint type recurring across multiple lots or units
• An investigation finding that a current control failed to prevent a defect
• An MDR-reportable event

The CAPA opened from a complaint must reference the originating complaint record. The complaint record must reference the resulting CAPA. Both records should be retrievable together during an inspection or audit. Traceability between complaints and CAPAs is a standard audit check.

Step 6: Trend your complaint data

Individual complaint investigation is the reactive component of complaint management. Complaint trending is the proactive component. ISO 13485 Clause 8.4 requires analysis of data from complaints, including trend analysis, to identify opportunities for improvement.

Trending means looking at complaint data across a defined period to identify patterns: the same failure mode appearing across different lots, a rate of a particular complaint type increasing over time, complaints clustered around a specific manufacturing date or shift, or a specific customer population reporting disproportionate problems.

Define your trending methodology in your complaint procedure. Specify what data you will analyze, at what frequency (monthly, quarterly), what thresholds trigger escalation, and who reviews the trend analysis. The trending output should feed into your management review as one of the required inputs under ISO 13485 Section 5.6.

Common complaint handling failures in FDA inspections

FDA warning letters related to complaint handling frequently cite these issues:

• Failure to investigate complaints or document investigation findings
• No written procedures for complaint handling
• Complaints received by sales or service personnel not routed to the quality team
• MDR evaluation not documented for complaints involving potential adverse events
• Late MDR submissions or events that should have been reported but were not
• No trending analysis of complaint data
• Complaint file records incomplete or not maintained for required retention periods
• CAPAs not initiated when complaint investigation identified systemic root causes

A pattern in warning letters: complaint volume is high, investigation records are thin, and MDR evaluation is absent from the file. The picture this creates for an investigator is a quality system that is receiving signals from the field and not acting on them. That picture is difficult to recover from quickly.

Managing complaints in an eQMS

Complaint management is one of the highest-value use cases for an integrated eQMS. The connections that matter, complaint to investigation, investigation to CAPA, complaint to MDR evaluation record, complaint data to trending report, are difficult to maintain reliably in a spreadsheet or email-based system.

An eQMS complaint management application provides:

• Structured complaint intake forms with required field validation
• Automated workflow routing to quality reviewers
• Investigation templates aligned to regulatory requirements
• Built-in MDR evaluation decision trees with documented outcomes
• Direct linkage from complaint record to CAPA module
• Complaint trending dashboards with configurable alert thresholds
• Retention controls aligned to regulatory requirements
• Full audit trail on every complaint action

Cloudtheapp’s Complaints application is part of its 60+ app eQMS platform, purpose-built for medical device, pharmaceutical, biotech, and food safety companies. The module manages the full complaint lifecycle from intake through investigation, MDR evaluation, CAPA linkage, and trend reporting, with electronic signatures compliant with 21 CFR Part 11. Request a walkthrough to see the complaint management module.

Conclusion

Complaint handling is the point where the field reports back to the quality system. Done well, it closes a feedback loop that catches product problems before they become recalls and patient safety events. Done poorly, it becomes one of the fastest paths to an FDA warning letter.

Build your process around systematic intake, documented investigation, explicit MDR evaluation, disciplined CAPA linkage, and regular trending. The administrative discipline required is not excessive. The consequences of skipping it are.

This post created by and appeared first on Cloudtheapp