Start with process and purpose
Identify the medical-device lifecycle activity, responsible roles, inputs, outputs, interactions, risks, controls, decisions, and records before selecting documentation or testing.
Practitioner reference
Use the standard through the actual process
This guide translates selected ISO 13485:2016 clause areas into practical questions, actions, examples, evidence, and Computerized System Validation (CSV) or Computer Software Assurance (CSA) connections. It does not reproduce the copyrighted standard or replace an authorized copy.
Apply applicable requirements
Determine the clauses, regulatory incorporations, market-specific requirements, customer commitments, and approved QMS procedures that govern the activity.
Evaluate effectiveness
Look beyond the presence of a procedure. Confirm that controls operate, records are reliable, issues are detected, decisions are supported, and the process improves.
Scale software evidence
Base validation on intended use, failure impact, existing controls, configuration, supplier evidence, complexity, and uncertainty—not a fixed protocol count.
Connected quality system
Follow the evidence through the QMS
A credible quality system connects management, resources, realization, measurement, and improvement. The same event may cross several clause areas and computerized systems.
- 01Plan and governPolicy, objectives, processes, risk, responsibilities, and resources
- 02Realize productRequirements, design, suppliers, production, acceptance, and traceability
- 03Retain evidenceControlled documents, complete records, identifiers, status, and history
- 04Measure performanceFeedback, complaints, audits, process and product results, and data analysis
- 05Improve and sustainCorrection, corrective and preventive action, change, effectiveness, and review
Interactive practitioner reference
ISO 13485:2016 requirements explorer
Search the guide, then open a clause area to review its practical meaning, actions, examples, evidence, and software-assurance connection.
Primary referenceISO standard record
Showing 31 of 31 clause areas.
Quality management system
4 areas4.1General quality management system requirementsAre QMS processes, interactions, outsourced activities, risks, and records defined and controlled?
Plain-language interpretation
What this means in practice
Establish the processes needed for the quality management system (QMS), show how they interact, apply risk-based control, and retain evidence that the processes remain effective—including when work is outsourced.
Practitioner actions
- Map QMS processes, owners, inputs, outputs, interactions, controls, and records.
- Identify outsourced processes and define retained organizational responsibility.
- Set criteria, resources, monitoring, change control, and improvement mechanisms.
Typical evidence
- Quality manual and process maps
- Controlled procedures and responsibility matrix
- Supplier or service agreements
- Process metrics, review, and change records
Applied examples
How the requirement can appear in a real system
- An electronic QMS connects complaint, nonconformance, corrective and preventive action, change, document, and training processes.
- A hosted service is mapped across supplier platform controls, customer configuration, identity, interfaces, procedures, and records.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
For each computerized system, define intended use, supported QMS processes, GxP functions, electronic records, ownership, interfaces, and validation status.
4.1.6Software used in the quality management systemIs QMS software validated before initial use and after changes, proportionate to risk?
Plain-language interpretation
What this means in practice
Establish documented procedures for validating computer software used in the QMS before use and, as appropriate, after changes. The method and extent should be proportionate to risk from the software’s intended use.
Practitioner actions
- Define intended use, supported QMS process, regulated functions, records, users, interfaces, and boundaries.
- Assess failure impact and existing controls at the function level.
- Review supplier evidence for scope, version, configuration, method, results, and gaps.
- Select scripted, unscripted, exploratory, automated, or other evidence based on risk.
- Approve use with residual risk, open issues, monitoring, and reassessment triggers.
Typical evidence
- Software inventory and applicability assessment
- Intended-use and requirements records
- Function-level risk assessment
- Supplier-evidence evaluation
- Test records, deviations, traceability, and validation conclusion
- Change assessment and periodic or event-driven review
Applied examples
How the requirement can appear in a real system
- An electronic-QMS workflow is tested for routing, approval authority, audit history, effective dates, and reporting.
- A calculation spreadsheet is controlled for formula changes, input limits, protection, independent review, output, and retention.
- An artificial-intelligence document reviewer remains advisory; users verify source evidence, important omissions, and final disposition.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
A certificate or supplier statement is context, not proof that the customer configuration, workflow, interface, data migration, or operating control is fit for its intended use.
4.2.4Control of documentsAre approved documents current, available, protected from unintended use, and changed under control?
Plain-language interpretation
What this means in practice
Control creation, review, approval, revision, availability, distribution, external documents, and prevention of unintended use of obsolete documents.
Practitioner actions
- Define document types, ownership, review and approval, effective date, distribution, revision, and retention.
- Ensure users can identify and access the current approved version where work occurs.
- Control externally originated documents and obsolete copies.
- Assess document-workflow changes and data migration.
Typical evidence
- Document-control procedure
- Approval and effective-date records
- Revision history and distribution controls
- Obsolete-document and external-document records
Applied examples
How the requirement can appear in a real system
- An electronic document system prevents an obsolete work instruction from being presented as current on the production floor.
- A supplier specification is version-controlled, reviewed for applicability, and linked to the approved purchasing record.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Validate configured workflows, permissions, effective-date logic, revision history, search, viewing, printing, integration, and migration where failure could affect the QMS.
4.2.5Control of recordsDo records remain identifiable, legible, protected, retrievable, and retained for the required period?
Plain-language interpretation
What this means in practice
Control the identification, storage, integrity, protection, retrieval, retention, and disposition of QMS records. The complete record includes its meaning, context, attribution, and history—not only the visible final value.
Practitioner actions
- Define record types, owners, metadata, retention, retrieval, protection, archive, and disposition.
- Protect records from unauthorized change, loss, corruption, and loss of context.
- Verify backup restoration, migration, archive retrieval, and decommissioning where relevant.
Typical evidence
- Record-control and retention procedures
- Access and audit records
- Backup and restore evidence
- Migration reconciliation and archive retrieval tests
Applied examples
How the requirement can appear in a real system
- A laboratory record retains source data, calculations, specification, analyst, reviewer, timestamps, method version, changes, and result.
- A legacy QMS archive can retrieve a complete complaint and linked investigation after the transactional system is retired.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Test the controls that preserve a complete, accurate, attributable, and retrievable record throughout retention; a successful backup job alone does not demonstrate restoration or intelligibility.
Management responsibility
5 areas5.1Management commitmentDoes leadership provide direction, resources, and review for an effective QMS?
Plain-language interpretation
What this means in practice
Top management demonstrates commitment by setting direction, establishing accountability, providing resources, reviewing performance, and ensuring applicable requirements are understood and met.
Practitioner actions
- Set measurable quality objectives and assign accountable owners.
- Provide suitable people, infrastructure, competence, and validated technology.
- Review performance, risk, issues, and improvement actions.
Typical evidence
- Quality policy and objectives
- Management-review records
- Resource and responsibility decisions
- Escalation and action tracking
Applied examples
How the requirement can appear in a real system
- Leadership reviews recurring validation deviations and funds remediation of unsupported infrastructure.
- Management defines risk tolerance and decision authority for adoption of a cloud QMS platform.
Example status: Generalized learning examples; not records from a specific organization or project.
5.3Quality policyIs the quality policy suitable, understood, maintained, and used to guide decisions?
Plain-language interpretation
What this means in practice
Maintain a policy appropriate to the organization that commits to applicable requirements and QMS effectiveness, provides a basis for objectives, and is communicated and reviewed.
Practitioner actions
- Approve a policy consistent with products, regulatory responsibilities, and organizational direction.
- Connect measurable objectives and decisions to the policy.
- Communicate, review, and update the policy when needed.
Typical evidence
- Approved quality policy
- Communication and training evidence
- Linked quality objectives
- Periodic review record
Applied examples
How the requirement can appear in a real system
- A policy commitment to reliable product and process data is reflected in objectives for record integrity, system reliability, and issue closure.
Example status: Generalized learning examples; not records from a specific organization or project.
5.4Quality planningAre quality objectives and QMS changes planned without losing system integrity?
Plain-language interpretation
What this means in practice
Translate policy into measurable objectives and plan changes so the QMS remains coherent and controlled.
Practitioner actions
- Define objectives, measures, owners, resources, and review frequency.
- Plan QMS changes across process, people, procedure, data, supplier, and technology.
- Protect business continuity and record integrity during transition.
Typical evidence
- Quality plans and objectives
- Change and transition plans
- Readiness criteria and governance records
- Performance review and action records
Applied examples
How the requirement can appear in a real system
- An enterprise-resource-planning replacement plan covers material status, supplier records, traceability, interfaces, cutover, training, and fallback.
- A site transfer identifies changed responsibilities, records, infrastructure, and validation dependencies.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
System implementation is a QMS change, not only an information-technology project. Validation evidence should align with the changed process and control environment.
5.5Responsibility, authority, and communicationAre accountable roles, authority, independence, and communication paths clear?
Plain-language interpretation
What this means in practice
Define who is responsible and authorized for QMS processes and decisions, including independence where needed and escalation to management.
Practitioner actions
- Document process, system, Quality, technical, supplier, and release responsibilities.
- Align system roles and access with approved authority.
- Define deputies, escalation, and cross-functional communication.
Typical evidence
- Organization and responsibility records
- Role and access matrix
- Procedure and escalation paths
- Meeting and decision records
Applied examples
How the requirement can appear in a real system
- A system administrator can configure a workflow but cannot approve the QMS record solely because of administrative access.
- The process owner, system owner, Quality, information technology, and supplier roles are explicit for SaaS change assessment.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Role-based access should implement approved responsibility; a configured permission set must not silently create decision authority.
5.6Management reviewDoes management review suitable inputs, decisions, actions, resources, and QMS effectiveness?
Plain-language interpretation
What this means in practice
Use planned reviews to evaluate audits, feedback, complaints, process and product performance, corrective and preventive action, changes, regulatory developments, resources, and improvement opportunities.
Practitioner actions
- Define required inputs, reliable measures, review cadence, participants, decisions, and follow-up.
- Evaluate adverse trends, overdue actions, repeat issues, resource constraints, and planned changes.
- Record owners, due dates, escalation, and effectiveness follow-up.
Typical evidence
- Agenda and complete management-review inputs
- Minutes, decisions, and action tracking
- Metric definitions and source verification
- Follow-up and effectiveness evidence
Applied examples
How the requirement can appear in a real system
- A review examines validation deviations, recurring access issues, supplier outages, delayed corrective actions, and periodic-review backlog.
- A dashboard trend is challenged for source logic, exclusions, refresh failures, and whether it supports the decision claimed.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Dashboards used for QMS decisions need controlled definitions, verified source and transformation logic, access control, and visible handling of missing or stale data.
Resource management
3 areas6.2Human resources and competenceAre people competent for assigned work and is competence evidence reliable?
Plain-language interpretation
What this means in practice
Determine needed competence, provide training or other action, evaluate effectiveness where appropriate, and retain suitable records.
Practitioner actions
- Define competence by role and task, not by course completion alone.
- Control curricula, assignments, qualification, retraining, and temporary access.
- Evaluate whether training or other action achieved the intended competence.
Typical evidence
- Competence requirements
- Training and qualification records
- Effectiveness evaluation
- Access provisioning and removal records
Applied examples
How the requirement can appear in a real system
- An MES operator must complete the effective procedure and practical qualification before production access is enabled.
- A computerized-system assurance reviewer is qualified in the process, risk method, evidence evaluation, and applicable procedure.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Validate the training system functions that assign the correct curriculum, preserve version history, record completion, enforce prerequisites, and provide reliable qualification status.
6.3InfrastructureIs infrastructure suitable, maintained, and capable of supporting conforming product and QMS operation?
Plain-language interpretation
What this means in practice
Determine and maintain buildings, workspace, equipment, software, communications, utilities, and supporting services needed for product and QMS requirements.
Practitioner actions
- Identify infrastructure and service dependencies.
- Define qualification, maintenance, monitoring, backup, continuity, and obsolescence controls.
- Assess changes and failures for product, process, and record impact.
Typical evidence
- Infrastructure inventory and qualification
- Maintenance and monitoring records
- Continuity and recovery tests
- Change, incident, and obsolescence records
Applied examples
How the requirement can appear in a real system
- Manufacturing depends on MES, network, barcode printers, scanners, time service, interfaces, and controlled recipes.
- A cloud QMS depends on vendor service, identity provider, integrations, export capability, support, and business-continuity arrangements.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Include the actual operating and integration environment in the system boundary; successful application testing does not cover every infrastructure dependency.
6.4Work environment and contamination controlAre environmental and contamination conditions defined, controlled, monitored, and addressed?
Plain-language interpretation
What this means in practice
Control work-environment and contamination conditions needed for product safety, quality, personnel, and process performance.
Practitioner actions
- Define limits, monitoring, responsibilities, response, and records.
- Qualify facilities, equipment, sensors, alerts, and computerized monitoring as appropriate.
- Investigate excursions and assess product impact.
Typical evidence
- Environmental requirements and qualification
- Monitoring and alarm records
- Excursion investigations and disposition
- Cleaning and contamination-control records
Applied examples
How the requirement can appear in a real system
- A cleanroom monitoring system manages sensor data, alarms, review, investigation, and record retention.
- A warehouse system connects temperature excursions to affected inventory and disposition decisions.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Test alarm limits, delays, missing data, sensor or communication failure, user acknowledgment, time sequence, reporting, and linkage to investigation.
Product realization
10 areas7.1Planning of product realizationAre product processes, requirements, risks, verification, validation, and records planned coherently?
Plain-language interpretation
What this means in practice
Plan product realization so product requirements, risk management, resources, acceptance activities, traceability, and records form one controlled lifecycle.
Practitioner actions
- Define lifecycle stages, deliverables, responsibilities, criteria, risk activities, verification, validation, transfer, and records.
- Resolve conflicts between plans and established QMS processes.
- Update planning as design, supplier, manufacturing, or regulatory conditions change.
Typical evidence
- Product and project quality plans
- Risk-management plan
- Verification and validation plans
- Design-transfer and acceptance records
Applied examples
How the requirement can appear in a real system
- A connected-device plan aligns design controls, software lifecycle, cybersecurity, manufacturing transfer, supplier controls, verification, and validation.
- A sterile device plan connects component controls, process validation, environmental monitoring, packaging, and release records.
Example status: Generalized learning examples; not records from a specific organization or project.
7.2Customer-related processesAre customer, intended-use, regulatory, delivery, and change requirements understood before commitment?
Plain-language interpretation
What this means in practice
Determine and review stated and unstated requirements, applicable regulatory obligations, delivery and post-delivery needs, communications, and changes.
Practitioner actions
- Capture requirements and acceptance criteria before commitment.
- Review feasibility, ambiguity, risk, regulatory implications, and conflicts.
- Control changes and communicate them to affected functions.
Typical evidence
- Customer and regulatory requirements
- Contract and feasibility reviews
- Communication and change records
- Requirements traceability
Applied examples
How the requirement can appear in a real system
- A customer request for remote service is reviewed for cybersecurity, privacy, clinical workflow, labeling, support, and infrastructure impact.
- A new market requirement triggers assessment of language, reporting, registration, distribution, and complaint obligations.
Example status: Generalized learning examples; not records from a specific organization or project.
7.3Design and developmentDoes design control connect planning, input, output, review, verification, validation, transfer, and change?
Plain-language interpretation
What this means in practice
Control design from approved inputs through outputs, reviews, verification, validation, transfer, and later change. Maintain traceability and risk-management integration.
Practitioner actions
- Plan stages, responsibilities, reviews, interfaces, and records.
- Make design inputs complete, unambiguous, testable, and risk-informed.
- Verify outputs meet inputs; validate the resulting device meets user needs and intended use.
- Control transfer and design changes with impact assessment.
Typical evidence
- Design and development plan
- Inputs, outputs, and reviews
- Verification, validation, and traceability
- Transfer and change-control records
Applied examples
How the requirement can appear in a real system
- A surgical system connects user needs to system and software requirements, architecture, risk controls, verification, simulated-use validation, and transfer.
- A medical application traces clinical calculation, data exchange, user interface, cybersecurity, and deployment requirements to evidence.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Requirements, risk, test, source, and release tools that carry design evidence need controls appropriate to their role in the design-history record.
7.4Purchasing and supplier controlAre supplier controls proportionate to the effect of the purchased product or service?
Plain-language interpretation
What this means in practice
Define purchasing requirements, evaluate and select suppliers, monitor performance, verify purchased outputs, and control supplier changes based on risk.
Practitioner actions
- Classify supplied products and services by impact.
- Define technical, quality, regulatory, record, notification, continuity, and change requirements.
- Evaluate capability and evidence before approval; monitor actual performance.
- Assess supplier changes and purchased-output acceptance.
Typical evidence
- Supplier-selection and evaluation records
- Approved supplier list
- Purchasing requirements and agreements
- Incoming verification, monitoring, issue, and change records
Applied examples
How the requirement can appear in a real system
- A critical component supplier is controlled for specification, process changes, traceability, nonconformance, and delivery quality.
- A cloud QMS supplier is controlled for service, security, release notification, incident response, backup, export, subcontractors, and exit.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Supplier assurance evidence may reduce duplicate testing when it is credible and relevant, but customer configuration, data, interfaces, procedure, and intended use still need local assessment.
7.5.1Control of production and service provisionAre production and service activities performed under defined, controlled conditions?
Plain-language interpretation
What this means in practice
Use approved instructions, suitable equipment, competent personnel, process parameters, monitoring, acceptance activities, identification, and records to control production and service.
Practitioner actions
- Define work sequence, parameters, acceptance criteria, equipment, materials, personnel, and records.
- Control master data, recipes, status, exceptions, rework, and release steps.
- Maintain traceability and response to deviations.
Typical evidence
- Approved work instructions and master records
- Equipment and personnel status
- Executed production or service records
- Deviation, review, and release records
Applied examples
How the requirement can appear in a real system
- An MES enforces the approved routing, current work instruction, equipment status, material checks, parameter limits, exception handling, and electronic record.
- A field-service application presents the correct procedure, captures parts and measurements, and links work to the device history.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Validate critical workflows, configured rules, master data, interfaces, electronic signatures, exception paths, and the resulting production or service record.
7.5.6Validation of processes for production and serviceAre processes validated when later monitoring or inspection cannot fully verify the result?
Plain-language interpretation
What this means in practice
Validate special processes whose output cannot be fully confirmed by subsequent monitoring or measurement, using defined acceptance criteria, qualified equipment and people, approved methods, records, and revalidation.
Practitioner actions
- Identify special processes and their critical parameters.
- Define qualification stages, acceptance criteria, sampling, methods, personnel, and records.
- Maintain the validated state and define revalidation triggers.
Typical evidence
- Process-validation plan and protocol
- Equipment and personnel qualification
- Executed results and deviations
- Approval, monitoring, and revalidation records
Applied examples
How the requirement can appear in a real system
- A sterilization process is qualified for equipment, cycle development, performance, load patterns, monitoring, and routine release.
- A welding process is validated for equipment, program, operator, materials, parameters, inspection, and periodic requalification.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Software controlling or recording a special process should be assessed as part of the total process, including parameter enforcement, recipes, interfaces, alarms, records, and change.
7.5.8IdentificationCan product identity and status be determined throughout realization?
Plain-language interpretation
What this means in practice
Establish identification suitable for product, components, materials, configuration, and acceptance status throughout production and service.
Practitioner actions
- Define identifiers and status values at relevant stages.
- Prevent mix-up, duplicate identity, unauthorized relabeling, and ambiguous status.
- Reconcile identifiers across systems and physical labels.
Typical evidence
- Identification procedure and master data
- Label and barcode controls
- Status and transaction records
- Reconciliation and exception records
Applied examples
How the requirement can appear in a real system
- A warehouse scan verifies item, lot, location, and status before issue.
- An MES creates a unique serial number and maintains its relationship to order, configuration, route, and acceptance.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Test identifier creation, duplicate rejection, scanning errors, reprint, interface failure, status change, reconciliation, and historical retrieval.
7.5.9TraceabilityCan the organization reconstruct required product, component, process, and distribution relationships?
Plain-language interpretation
What this means in practice
Maintain traceability to the extent required by product, regulation, risk, and the QMS, including required lot, serial, component, production, inspection, and distribution information.
Practitioner actions
- Define the required genealogy and its authoritative sources.
- Control creation, transfer, correction, reconciliation, and retrieval of traceability data.
- Verify traceability through interfaces and system changes.
Typical evidence
- Traceability requirements and procedures
- Genealogy and device-history records
- Interface specifications and reconciliation
- Mock recall or retrieval evidence
Applied examples
How the requirement can appear in a real system
- An implantable-device record links serial number, critical components, operators, equipment, inspection, release, and distribution.
- ERP and MES data jointly reconstruct material lot, manufacturing order, device serial, nonconformance, and disposition.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Challenge incomplete, duplicate, incorrect, late, and failed interface transactions; prove end-to-end traceability rather than validating each system in isolation.
7.5.11Preservation of productIs product protected during processing, storage, handling, packaging, and distribution?
Plain-language interpretation
What this means in practice
Preserve conformity through suitable handling, packaging, storage, environmental control, stock rotation, transport, and protection from damage or deterioration.
Practitioner actions
- Define conditions, limits, monitoring, segregation, stock rules, packaging, and transport controls.
- Respond to excursions, damage, expiry, and compromised status.
- Link environmental and inventory records to product decisions.
Typical evidence
- Preservation procedures
- Environmental and inventory records
- Packaging and shipping evidence
- Excursion investigation and disposition
Applied examples
How the requirement can appear in a real system
- A warehouse system prevents issue of expired or quarantined material and records controlled status changes.
- A distribution process connects temperature-monitor data to shipment, affected product, investigation, and disposition.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Validate configured shelf-life rules, status blocks, inventory rotation, environmental interfaces, alerts, and reports where software affects preservation.
7.6Control of monitoring and measuring equipmentAre measurement resources suitable, calibrated, protected, and assessed when found out of tolerance?
Plain-language interpretation
What this means in practice
Identify monitoring and measuring equipment, maintain calibration or verification traceable to suitable standards, protect status and adjustment, and assess prior results when equipment is unsuitable.
Practitioner actions
- Define equipment, range, accuracy, calibration, verification, status, and interval.
- Control standards, software, environmental conditions, labels, and records.
- Evaluate product impact when equipment is out of tolerance.
Typical evidence
- Equipment inventory and requirements
- Calibration and verification records
- Status and traceability evidence
- Out-of-tolerance investigation and product-impact assessment
Applied examples
How the requirement can appear in a real system
- A torque tool is calibrated, status-controlled, protected from unauthorized adjustment, and linked to production records.
- An environmental sensor is assessed for drift and the impact on stored product during the affected period.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Validate calibration-system calculations, interval logic, status, reminders, access, equipment-to-record linkage, migration, and reports where these functions support acceptance.
Measurement, analysis, and improvement
9 areas8.2.1FeedbackDoes the organization collect and use post-production information as an early-warning input?
Plain-language interpretation
What this means in practice
Establish a feedback process that collects and reviews production and post-production information, connects it to risk management, and uses it for improvement and regulatory decisions.
Practitioner actions
- Define internal and external feedback sources, review frequency, ownership, thresholds, and escalation.
- Connect signals to complaint, risk, corrective action, design, supplier, and regulatory processes.
- Preserve source and decision traceability.
Typical evidence
- Feedback procedure and source records
- Trend and signal reviews
- Risk and process linkages
- Escalation and action records
Applied examples
How the requirement can appear in a real system
- Service trends reveal repeated connector damage that is evaluated for design, labeling, supplier, and training implications.
- Usability feedback identifies a recurring selection error before it becomes a confirmed complaint trend.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Ensure feedback pipelines and dashboards do not omit, duplicate, misclassify, or delay data in ways that hide a meaningful signal.
8.2.2Complaint handlingAre complaints received, evaluated, investigated, reported, trended, and linked to action?
Plain-language interpretation
What this means in practice
Maintain a controlled complaint process covering intake, evaluation, investigation, regulatory reporting, communication, risk, corrective action, and records.
Practitioner actions
- Define complaint criteria, intake channels, triage, reportability, investigation, closure, and timelines.
- Link affected product, device identifiers, events, risk, corrective action, and regulatory submissions.
- Control decisions not to investigate and maintain trend visibility.
Typical evidence
- Complaint procedure and complete record
- Investigation and reportability assessment
- Regulatory submissions and communication
- Trend, risk, corrective-action, and closure records
Applied examples
How the requirement can appear in a real system
- A complaint system routes a potential serious injury for timely reportability assessment and preserves the source communication and decision.
- An artificial-intelligence triage aid suggests categories, while a qualified person confirms complaint status, severity, reportability, and escalation.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Validate intake, duplicate detection, coding, routing, timelines, permissions, links, reports, and signatures. For AI assistance, test misses and false confidence, require qualified human review, retain sources, and monitor performance.
8.2.4Internal auditDo audits objectively evaluate QMS conformity and effectiveness?
Plain-language interpretation
What this means in practice
Plan and conduct audits based on process importance, performance, risk, and prior results, using independent auditors and controlled findings and follow-up.
Practitioner actions
- Maintain a risk-based audit program and criteria.
- Select competent, sufficiently independent auditors.
- Document evidence, findings, corrections, corrective actions, and follow-up.
Typical evidence
- Audit program and schedule
- Auditor qualification and independence
- Plans, evidence, reports, and findings
- Correction, corrective action, and follow-up
Applied examples
How the requirement can appear in a real system
- A process audit samples whether system access, electronic approvals, training status, and change records match approved procedures.
- An audit of supplier controls traces a critical SaaS service from selection through agreement, monitoring, release assessment, and incidents.
Example status: Generalized learning examples; not records from a specific organization or project.
8.2.5Monitoring and measurement of processesAre QMS processes monitored using reliable methods and acted upon when objectives are not achieved?
Plain-language interpretation
What this means in practice
Use suitable methods and measures to demonstrate that QMS processes achieve planned results, then correct or improve the process when they do not.
Practitioner actions
- Define process objective, measure, data source, calculation, threshold, owner, cadence, and response.
- Investigate adverse or misleading trends and data-quality problems.
- Connect action to risk and effectiveness review.
Typical evidence
- Process-monitoring procedure
- Metric definitions and data lineage
- Trend review and investigation
- Action and effectiveness records
Applied examples
How the requirement can appear in a real system
- A corrective-action metric distinguishes overdue records from records awaiting justified effectiveness evidence.
- A training-readiness measure excludes obsolete curricula and flags access granted before qualification.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Verify dashboard calculations, filters, exclusions, timestamps, refresh status, source changes, and access when metrics drive QMS action.
8.2.6Monitoring and measurement of productAre product acceptance activities complete, recorded, and approved by authorized personnel?
Plain-language interpretation
What this means in practice
Monitor and measure product characteristics at planned stages, retain evidence of conformity and release authority, and prevent release until planned arrangements are completed unless otherwise approved.
Practitioner actions
- Define inspections, tests, sampling, acceptance criteria, record, reviewer, and release authority.
- Prevent skipped or failed activities from appearing complete.
- Control exceptions, rework, retest, concession, and final disposition.
Typical evidence
- Inspection and test records
- Acceptance criteria and sampling plans
- Release authorization
- Exception, rework, and disposition records
Applied examples
How the requirement can appear in a real system
- Final inspection records the device configuration, measurements, calibrated equipment, result, reviewer, and release decision.
- An enterprise system blocks shipment when required inspection or disposition remains incomplete.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Test enforcement of completion, result limits, equipment status, reviewer authority, failure paths, interface timing, and release blocks.
8.3Control of nonconforming productIs nonconforming product identified, controlled, evaluated, and dispositioned to prevent unintended use?
Plain-language interpretation
What this means in practice
Control identification, segregation or electronic status, evaluation, investigation, disposition, rework, concession, and action after delivery.
Practitioner actions
- Define detection, containment, status, review, disposition authority, rework, concession, and escalation.
- Assess effect on related lots, devices, processes, suppliers, risk, and delivered product.
- Verify rework and retain complete decisions.
Typical evidence
- Nonconformance record
- Status and segregation evidence
- Investigation and disposition approval
- Rework, verification, and post-delivery action
Applied examples
How the requirement can appear in a real system
- An ERP and MES combination blocks a quarantined material lot from issue until authorized disposition.
- A post-delivery nonconformity triggers evaluation of affected devices, notification, regulatory reporting, correction, and field action.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Validate electronic status control, segregation, disposition authority, inventory and manufacturing interfaces, label changes, rework routing, and historical traceability.
8.4Analysis of dataAre quality data transformed into reliable evidence about QMS and product performance?
Plain-language interpretation
What this means in practice
Determine, collect, and analyze appropriate data on feedback, product conformity, processes, suppliers, and improvement needs using defined methods.
Practitioner actions
- Identify decisions, data sources, definitions, methods, periods, and owners.
- Verify completeness, accuracy, transformations, filters, and limitations.
- Review trends and link significant findings to risk and action.
Typical evidence
- Data-analysis procedure
- Metric definitions and source mapping
- Analysis and trend records
- Decisions, limitations, and follow-up
Applied examples
How the requirement can appear in a real system
- A supplier scorecard distinguishes delivery, incoming quality, critical defects, corrective-action response, and data completeness.
- Complaint analysis separates product family, event type, severity, market, denominator, coding changes, and late intake.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Pipelines, spreadsheets, statistical tools, and dashboards should be controlled and tested according to the importance of the decision they support.
8.5.2Corrective actionDoes corrective action remove the cause of detected nonconformity without creating unacceptable new risk?
Plain-language interpretation
What this means in practice
Investigate nonconformity, determine cause, evaluate needed action, implement changes, verify or validate them, evaluate effectiveness, and update risk information.
Practitioner actions
- Define the problem and contain immediate impact.
- Use evidence to determine root cause and extent.
- Assess proposed action across process, product, risk, supplier, training, documentation, and systems.
- Verify implementation and evaluate effectiveness with meaningful criteria and time.
Typical evidence
- Corrective-action record and containment
- Investigation and root-cause evidence
- Risk and change-impact assessment
- Implementation, verification, and effectiveness record
Applied examples
How the requirement can appear in a real system
- Repeated interface failures lead to root-cause analysis of mapping and retry logic, corrective change, regression, reconciliation, and effectiveness monitoring.
- Torque escapes lead to assessment of equipment, calibration, work instruction, training, system enforcement, prior product, and control effectiveness.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Validate corrective-action workflow, due dates, permissions, links, approval, effectiveness logic, audit history, and reporting. Closing the electronic form is not proof of effectiveness.
8.5.3Preventive actionAre potential nonconformities identified and addressed proportionate to their risk?
Plain-language interpretation
What this means in practice
Use trends, risk information, lessons, and other signals to identify potential nonconformity, determine cause, take proportionate action, and review effectiveness.
Practitioner actions
- Define signal sources and criteria for preventive action.
- Evaluate potential cause, impact, risk, and proportionality.
- Implement controls before occurrence and monitor whether they work.
Typical evidence
- Trend or risk signal
- Preventive-action assessment
- Implementation and change records
- Effectiveness and management-review evidence
Applied examples
How the requirement can appear in a real system
- A deteriorating supplier-delivery trend prompts capacity and continuity controls before production is interrupted.
- An approaching operating-system end-of-support date prompts upgrade planning, compatibility testing, cybersecurity review, and controlled transition.
Example status: Generalized learning examples; not records from a specific organization or project.
Clause 4.1.6 in practice
Risk-based validation of QMS software
Validation should demonstrate that the configured software is fit for the defined QMS use before initial use and after changes when appropriate. The evidence package should explain why the selected activities are sufficient.
- 01
Define intended use
State the process, users, functions, records, decisions, interfaces, configuration, and boundary.
- 02
Assess failure
Explain credible function-level failures and their product, patient, record, process, or regulatory impact.
- 03
Credit controls
Evaluate preventive, detective, supplier, procedural, technical, and human controls.
- 04
Select evidence
Use supplier evidence, reviews, demonstrations, scripted, unscripted, exploratory, automated, interface, migration, and recovery tests where useful.
- 05
Release and maintain
Resolve or accept issues, document rationale, approve use, monitor performance, and define reassessment triggers.
Scripted testing
Use when precision and repeatability matter
Detailed steps and expected results suit critical calculations, data mapping, access restrictions, electronic approvals, release blocks, traceability, and regression.
Unscripted or exploratory testing
Use when skilled investigation adds value
A charter, qualified tester, bounded scope, contemporaneous notes, observations, issues, and conclusion can expose workflow, usability, configuration, and unexpected-behavior risks.
Supplier evidence
Leverage after relevance is established
Review product and version, functions, configuration, method, environment, results, deviations, independence, and limitations; then close customer-specific gaps.
Operational evidence
Use lifecycle performance appropriately
Incidents, service levels, audit history, change performance, restore exercises, access reviews, and trend data can support ongoing validated-state decisions.
Cross-functional application
Apply clause requirements to system-supported work
A whole system is not simply “GxP” or “non-GxP.” Identify the functions, records, decisions, interfaces, and failure modes that matter.
| System context | Relevant clause areas | Primary assurance focus |
|---|---|---|
| Electronic QMS (eQMS) | 4.1.6, 4.2.4, 4.2.5, 8.2.2, 8.5.2 | Corrective and preventive action, complaints, documents, approvals, signatures, audit history, and retention. |
| Laboratory information management system (LIMS) | 4.1.6, 4.2.5, 7.6, 8.2.6 | Laboratory calculations, specifications, instrument interfaces, records, review, and release-supporting results. |
| Manufacturing execution system (MES) | 4.1.6, 7.5.1, 7.5.8, 7.5.9 | Routing, operator eligibility, recipes, parameters, exceptions, serial identity, traceability, and production records. |
| Enterprise resource planning (ERP) | 4.1.6, 7.4, 7.5.9, 8.3 | Purchasing, material status, genealogy, release, inventory, nonconformance, and interfaces. |
| Training system | 4.1.6, 6.2 | Curriculum version, assignment, prerequisites, completion, qualification, retraining, and access linkage. |
| Calibration system | 4.1.6, 7.6 | Equipment identity, intervals, standards, status, results, out-of-tolerance impact, and reporting. |
| Controlled spreadsheet | 4.1.6 | Critical calculation, input limits, formulas, protection, review, output, version, and retention. |
| AI-enabled QMS tool | 4.1.6 and the supported process clause | Bounded intended use, source evidence, reference evaluation, human review, monitoring, supplier change, and retained decision. |
United States regulatory context
Relationship to FDA’s Quality Management System Regulation
The U.S. Food and Drug Administration’s Quality Management System Regulation (QMSR) became effective on 2 February 2026 and incorporates ISO 13485:2016 by reference for applicable finished medical-device manufacturers, with additional U.S. requirements and interpretations.
Use the incorporated requirements
Apply the regulatory text, FDA implementation material, incorporated standard, other applicable parts of Title 21, and the organization’s approved QMS—not the ISO page alone.
Expect process-based evidence
Connect software validation to the QMS process, record, failure, control, supplier responsibility, change, and inspection narrative.
Implementation review
Common mistakes and better practice
Clause checklist as the QMS
Show process interactions, risks, controls, records, decisions, performance, and improvement—not only document titles.
Supplier certificate equals validation
Assess the customer’s intended use, configuration, workflow, data, interfaces, procedures, and evidence gaps.
One validation package for every system
Scale methods and evidence to the function, failure impact, existing control, complexity, and uncertainty.
Disconnected complaint, CAPA, risk, and change
Preserve traceability from signal through investigation, risk, action, implementation, and effectiveness.
Unverified dashboard
Control metric definition, source, transformation, filter, refresh, access, limitation, and response.
Backup presented as recovery
Test restoration, completeness, usability, context, security, and retrieval within the needed time.
Obsolete documents remain locally available
Control effective versions at the point of use and prevent unintended use of obsolete copies.
CAPA closure without effectiveness
Define what sustained result will show the cause was removed and evaluate it after sufficient time.
System-level GxP labels
Identify the specific functions, records, decisions, failure modes, and controls that create regulated impact.
Reusable review prompts
Nine practitioner assessment questions
- 1
What is the intended use of the process or system?
- 2
Which ISO 13485 clause areas and regulatory incorporations are actually applicable?
- 3
What product, patient, process, record, or regulatory decision could be affected by failure?
- 4
Which preventive and detective controls already reduce the risk?
- 5
What evidence exists from process design, suppliers, configuration, testing, operation, and monitoring?
- 6
Which test method best exposes the credible failure?
- 7
What record proves the activity and preserves its context?
- 8
What change, incident, trend, supplier event, or regulatory development should trigger reassessment?
- 9
What ongoing evidence shows the process and system remain in a validated state?
Primary references
Sources and related guidance
- ISO 13485:2016Official ISO record; consult an authorized copy for normative requirements.
- FDA Quality Management System RegulationOfficial FDA QMSR overview and implementation resources.
- 21 CFR Part 820Current U.S. electronic Code of Federal Regulations text.
- IEC 62304 practical guideMedical-device software lifecycle and risk-based evidence.
Revision history
| Version | Date | Change |
|---|---|---|
| 1.0 | 13 September 2026 | Initial practitioner guide based on the supplied CSVtoCSA content pack; source status and links reviewed. |