ISO 13485:2016 clause 7: Product realization

• Product realization process map or turtle diagrams showing inputs, outputs, resources, controls, and KPIs for each realization sub-process (7.1 through 7.6)
• Quality manual sections referencing product realization process interactions and sequence
• Cross-reference matrix linking product realization processes to QMS procedures (document control, records, management review)
• Evidence that process owners are assigned for each realization sub-process with defined responsibilities
• Process performance metrics or KPIs demonstrating the realization processes are monitored and effective

• Product realization processes are described in isolation with no documented interaction or sequence -- design hands off to manufacturing with no formal linkage
• Process map exists but has not been updated since the original QMS implementation; new product lines and outsourced processes are absent
• No linkage between the realization process map and the risk management activities required by 7.1 -- risk is treated as a separate, disconnected activity
• Quality manual references 'product realization' generically but does not identify the specific sub-processes (design, purchasing, production, servicing) actually performed by the organization

Review the current product realization process map and compare it against the actual product portfolio and any recent organizational changes such as new contract manufacturers or new product families.

• Have any new product lines or outsourced processes been added since this process map was last revised?
• How do you ensure that changes in one realization process (e.g., a design change) trigger appropriate reviews in downstream processes (e.g., purchasing specifications, production work instructions)?
• Where does risk management appear in your realization process flow?

• Product-specific quality plan or project plan showing defined realization stages, deliverables, milestones, responsible functions, and review gates
• Process flow diagrams specific to the product showing the sequence from customer requirements through design, V&V, transfer, production, and delivery
• Evidence that the quality plan references or incorporates applicable QMS procedures (document control, training, purchasing, CAPA) rather than operating in isolation
• Resource allocation documentation showing personnel, equipment, and facility assignments for the product realization project
• Risk management plan (per ISO 14971) integrated into the product realization plan -- not a separate standalone document with no cross-references
• Records showing the plan was reviewed and approved by appropriate functions before execution began

• A single generic quality plan is used for all products regardless of device class, risk profile, or complexity -- a Class III implantable and a Class I exam glove use the same planning template with no tailoring
• Product realization planning exists only in the design control procedure; no product-specific plan is created for individual projects, so unique risks and regulatory requirements are not addressed
• The quality plan was created at project kickoff but never updated as the project evolved -- scope changes, additional regulatory markets, and new supplier qualifications are not reflected
• Risk management is listed as a deliverable in the project plan but is not integrated into the stage-gate process -- the risk management file is completed retrospectively after design freeze
• Planning documents do not identify the specific processes needed for the product (e.g., sterilization validation, biocompatibility testing) and instead rely on generic references to 'applicable procedures'

Select one completed product (preferably higher risk class) and one active development project. Compare their quality plans against each other and against the generic procedure to assess whether product-specific tailoring occurred.

• Show me a revision history for this quality plan -- was it updated during the project, or is this the original version?
• How did you determine which realization processes were needed for this specific product versus your standard process set?
• Where in this plan does risk management feed into design decisions?

• Completed quality plan or product realization plan with defined content (stages, deliverables, responsibilities, V&V activities, acceptance criteria, records, risk management)
• V&V master plan or protocol matrix showing planned verification and validation activities mapped to design stages
• Process flow diagram for the specific product showing manufacturing steps, inspection points, and decision gates
• Resource plan identifying personnel competencies required, equipment, and facilities -- with evidence of actual allocation
• Evidence that planning outputs are controlled documents (revision history, approval signatures, distribution control)
• Evidence of plan updates when scope, schedule, or requirements changed during the project

• Planning output consists only of meeting minutes or email threads rather than formal, controlled documents -- there is no single document that captures the realization plan
• A quality plan template exists but was never completed for the sampled product -- blank sections remain for V&V activities, acceptance criteria, and resource requirements
• Planning outputs were created but are stored on a shared drive outside the document control system, with no revision history or approval signatures
• The product realization plan references a V&V master plan that does not exist -- the reference was copied from a template but the actual plan was never developed
• Planning outputs have not been updated since initial approval despite significant scope changes including addition of new intended markets requiring CE marking

Pull the same two products sampled in 7.1 and ask to see the physical or electronic planning documents. Verify they are in the document control system with proper metadata.

• Is this planning output maintained under your document control procedure? Show me the revision history.
• When the project scope changed to add the EU market, how was this quality plan updated?
• Who is responsible for maintaining this document throughout the product lifecycle?

• Risk management procedure referencing ISO 14971:2019, defining how risk management is integrated throughout product realization stages
• Product-specific risk management plan defining scope, risk acceptability criteria, risk management activities per realization stage, and responsibilities
• Risk management file containing: hazard identification, risk estimation, risk evaluation, risk control records, residual risk evaluation, risk/benefit analysis, production and post-production information review
• Evidence of risk management integration at each realization stage -- risk inputs to design (7.3.3c), risk considerations in V&V (7.3.6/7.3.7), risk-based process controls (7.5.1), risk-based sampling plans (8.2.6)
• Post-production risk monitoring records showing the risk management file is updated with field data, complaints, and CAPAs
• Records showing risk management activities are maintained and updated -- the file is not static after design transfer

• Risk management procedure references ISO 14971:2007 rather than the current 2019 edition -- risk acceptability criteria do not include the overall residual risk evaluation now required
• Risk management file was completed during design and has not been updated since product launch despite multiple complaint investigations and CAPAs that identified new hazards
• Risk management activities are documented only in the risk management file with no integration into design reviews, V&V protocols, or production process controls -- risk management operates as a parallel, disconnected activity
• Risk acceptability matrix uses a qualitative scale ('low/medium/high') without defined quantitative criteria for probability or severity, making risk evaluation inconsistent across assessors
• No documented requirements for risk management throughout product realization -- the organization has a risk management procedure but it does not specify when risk activities occur during realization stages

Select the risk management file for the sampled product. Verify it has been updated post-launch. Trace 2-3 risk control measures from the file to their implementation in design outputs or production process controls.

• When was the last time this risk management file was updated with post-production information?
• Show me a risk control measure in this file and then show me the corresponding process control or design feature that implements it.
• How does complaint data feed back into your risk management file?
• Which edition of ISO 14971 does your risk management procedure reference?

• Product-specific quality objectives documented in the quality plan -- measurable targets such as defect rates, reliability targets, biocompatibility pass criteria, or shelf-life goals
• Product requirements specification (PRS) or user requirements specification (URS) referenced from the quality plan
• Regulatory requirements matrix identifying applicable regulations and standards per intended market (e.g., FDA 21 CFR 820, EU MDR 2017/745, Health Canada SOR/98-282)
• Customer requirements documentation including explicit requirements (specifications, delivery) and implicit requirements (safety expectations, usability, environmental conditions)
• Design input document showing these requirements were formally captured and approved before design work began

• Quality objectives in the quality plan are copy-pasted from the organization-level quality policy ('ensure customer satisfaction') with no product-specific measurable targets
• Regulatory requirements matrix lists only the home market (FDA) despite the product being sold in 4 additional markets -- EU MDR and MDSAP requirements are absent from design inputs
• Customer requirements are captured informally in a sales briefing document but were never formally translated into product requirements with traceability to design inputs
• Product requirements include performance specifications but omit safety requirements, usability requirements, and packaging/labeling requirements
• Quality objectives are defined at project start but have no mechanism for monitoring or measuring achievement during or after the project

Compare the quality objectives in the sampled product's quality plan against the organization-level quality objectives to verify product-specific tailoring occurred.

• How do you distinguish between quality objectives for this product versus your organization-level quality objectives?
• When a new market is added after initial planning, how do you update the regulatory requirements matrix?
• Show me evidence that these quality objectives were monitored during the project.

• Product-specific process identification document or section within the quality plan listing processes required (e.g., sterilization, special coating, injection molding, software development)
• List of product-specific documents created (work instructions, test methods, inspection procedures, IFU) with evidence they were developed and approved before production
• Resource requirements document showing specific equipment, facilities, personnel competencies, and software tools needed for this product
• Evidence of resource procurement or allocation (capital equipment purchase orders, facility modifications, training records for new competencies)
• Gap analysis between existing process capabilities and product-specific needs, with plans to close identified gaps

• No product-specific process identification was performed -- the organization assumed all existing processes were sufficient without evaluating whether the new product introduced unique manufacturing, testing, or sterilization requirements
• The quality plan states 'standard processes apply' without identifying which specific processes are needed for this product or whether any new processes must be established
• Product requires electron beam sterilization but the organization only has EtO sterilization validated -- no gap was identified during planning and the issue was discovered during design transfer
• Resource requirements were not formally assessed -- key personnel left during the project and replacements were not identified, causing a 6-month project delay
• Product-specific test methods were developed ad hoc during V&V rather than being identified and planned during the realization planning phase

For the sampled product, compare the process identification in the quality plan against the actual processes used in production. Verify that any product-specific processes were identified during planning, not discovered downstream.

• What new processes or equipment did you need to establish specifically for this product that you did not already have?
• How did you identify competency requirements for the design team working on this product?
• Were any gaps found between existing capabilities and product needs? How were they closed?

• V&V master plan or protocol index listing all planned verification and validation activities with methods, acceptance criteria, and stage assignments
• Product-specific inspection procedures with defined inspection points, methods, sampling plans (per ISO 2859 or equivalent), and accept/reject criteria
• Test method procedures including equipment requirements, calibration status, and measurement uncertainty considerations
• Acceptance criteria with documented rationale -- traceable to design inputs, standards, regulatory requirements, or engineering analysis
• Sampling plan documentation with statistical justification (confidence level, AQL, sample size rationale)
• Evidence that V&V planning was completed and approved before testing began -- not created retrospectively to document what was already done

• V&V plan exists but does not map individual test activities to specific design input requirements -- there is no way to confirm all requirements have a corresponding verification or validation activity
• Acceptance criteria for a critical safety parameter (e.g., tensile strength of a suture) are stated as 'meets specification' without a quantitative limit -- the specification referenced does not exist
• Sampling plan uses n=3 for all incoming inspections regardless of lot size, supplier history, or component criticality -- no statistical basis is documented
• Inspection procedures reference test equipment that has not been calibrated or validated for the measurement range required
• V&V protocols were written after testing was completed -- protocol dates post-date the test execution dates in the lab notebooks

Select 2-3 acceptance criteria from the sampled product, including at least one safety-critical parameter. Trace each from the acceptance criterion back to the design input to verify completeness and adequacy.

• What is the statistical basis for your sampling plan? How do you determine sample sizes for different risk levels?
• Show me the acceptance criterion for [a specific safety-critical parameter] and trace it back to the design input requirement.
• Were any V&V protocols amended after testing began? Show me the change records.

• Record requirements matrix or list identifying all record types needed for the product (DHF records, DHR records, batch records, test reports, inspection records, calibration records, training records)
• Device History Record (DHR) for a recent production lot showing manufacturing records, in-process inspections, final test results, and release documentation
• Design History File (DHF) index showing the record types maintained and their completeness status
• Record retention schedule specifying retention periods per record type -- aligned with regulatory requirements (FDA: lifetime of device + 2 years; EU MDR: at least 10 years, or 15 years for implantables)
• Evidence that record requirements were defined during planning, not determined ad hoc during production

• No formal identification of required records was performed during product realization planning -- record types were determined ad hoc as production issues arose
• DHR for the sampled lot is missing in-process inspection records for a critical assembly step -- the planning documents do not specify that in-process records are required at this step
• Record retention periods are set at a blanket '5 years for all records' without considering regulatory requirements for specific markets (e.g., EU MDR requires 10 or 15 years depending on device class)
• Electronic records (test data from automated equipment) are not identified in the record requirements list and are stored in proprietary formats without a data migration or long-term accessibility plan
• Batch record templates were not developed during planning and were created by production operators without QA review, resulting in inconsistent formats and missing fields across lots

Pull one recent DHR and compare its contents against the record requirements defined in the quality plan. Identify any gaps between planned records and actual records maintained.

• How do you determine retention periods for different record types? Do these vary by market?
• Show me the DHR for the most recent production lot -- does it contain all the record types specified in your planning documents?
• How do you ensure electronic test data remains accessible and readable for the full retention period?

• Documented procedure(s) for determination of product requirements, covering all five categories (customer-specified, implied needs, regulatory, training, organizational)
• Documented procedure for contract/order review including the five review criteria (7.2.2 a-e), timing of review, authority for acceptance, and handling of amendments
• Documented procedure for customer communication covering all four categories (product information, enquiries/orders, feedback/complaints, advisory notices)
• Definition of 'customer' types applicable to the organization -- end users (clinicians, patients), purchasing organizations (hospitals, GPOs), distributors, and regulatory bodies
• Evidence that these procedures are implemented -- sample records of requirements determination, contract reviews, and customer communications for a recent product or order

• Customer-related processes are handled informally by the sales team with no documented procedures -- requirements are captured in emails and meeting notes with no formal review or approval process
• Documented procedure for requirements determination covers only customer-specified requirements (7.2.1a) and omits regulatory requirements (7.2.1c), user training needs (7.2.1d), and organizational requirements (7.2.1e)
• Contract review procedure exists but is limited to pricing and delivery terms -- technical requirements, regulatory compliance, and manufacturing capability are not part of the review
• Customer communication procedure does not include advisory notices (Field Safety Corrective Actions) or feedback/complaint channels -- it covers only sales inquiries and order processing
• Procedures exist but are written for a contract manufacturing model; the organization transitioned to OBL (own-brand labeling) and the procedures have not been updated to reflect the change in customer type and requirements flow

Review the documented procedures and then pull 2-3 recent contract reviews or order acceptances to verify the procedures are being followed in practice.

• How do you capture requirements from end users (clinicians, patients) in addition to purchasing organizations?
• Who is responsible for identifying applicable regulatory requirements for new markets?
• Show me how these three procedures interact -- does requirements determination feed directly into contract review?

• Requirements determination records showing systematic identification of all five requirement categories for a specific product
• Customer-specified requirements document including explicit requirements for product performance, delivery timelines, packaging, installation, servicing, and warranty
• User needs analysis or use case documentation identifying requirements not stated by the customer but necessary for safe and effective use
• Regulatory requirements matrix for all intended markets listing applicable regulations, standards, essential requirements, and market-specific labeling/language requirements
• Training needs analysis identifying user training requirements for safe and effective product use -- content, format, timing, and competency verification
• Organizational requirements document capturing internal requirements such as platform compatibility, manufacturing constraints, cost targets, and strategic objectives
• Traceability from determined requirements to design inputs (7.3.3) demonstrating requirements flow into the design process

• Requirements determination produced a single customer specification document but did not systematically address unstated needs, regulatory requirements, training needs, or organizational requirements -- four of five categories are absent
• User training requirements (7.2.1d) were not identified during requirements determination; the need for clinical training was discovered during post-market surveillance when adverse events were attributed to improper use
• Regulatory requirements matrix identifies FDA requirements but omits EU MDR requirements despite the product being sold in Europe -- the matrix was created for initial US launch and never updated for EU market entry
• Unstated requirements (7.2.1b) were not formally assessed -- there is no documented analysis of the use environment, user population characteristics, or foreseeable misuse scenarios
• Requirements determination was performed by the marketing team without involvement of regulatory, clinical, quality, or manufacturing functions, resulting in requirements that are technically incomplete and not verifiable

Select one recently launched product and verify that documented outputs exist for all five requirement categories. Trace at least 3 requirements from determination records into design inputs.

• How do you identify requirements that customers need but do not explicitly state? Who performs this analysis?
• Show me how training requirements were determined for this product. Were clinical users involved in the assessment?
• When you add a new geographic market, how does that trigger a review of regulatory requirements?

• Customer requirements specification document or database entries with unique requirement IDs, source (which customer or market input), and approval status
• Delivery requirements including timeline, packaging, shipping conditions (temperature, vibration, orientation), and labeling for transport
• Post-delivery requirements including installation specifications, commissioning protocols, preventive maintenance schedules, warranty terms and coverage, spare parts availability, and end-of-life/decommissioning obligations
• Purchase orders or contracts showing customer-specified requirements with evidence of capture in the requirements management system
• Customer meeting minutes or voice-of-customer records showing how explicit requirements were elicited and documented

• Customer requirements focus exclusively on device performance and omit delivery requirements -- the organization shipped temperature-sensitive reagents via standard ground shipping because delivery conditions were never specified as a requirement
• Post-delivery requirements (installation, servicing, preventive maintenance schedules) are managed informally by the field service team and are not captured in the formal requirements specification
• Customer requirements are captured in a sales proposal that is not revision-controlled and is not accessible to the design or manufacturing teams
• Multiple customers have different requirements for the same product, but there is no process to reconcile conflicting requirements or to define a product specification that satisfies all customer needs

Review the customer requirements specification for the sampled product and verify it includes both product requirements and delivery/post-delivery requirements.

• What post-delivery obligations does this product have? Show me where they are documented as requirements.
• How do you handle conflicting requirements from different customers or markets?
• Are delivery conditions (temperature, humidity, shock) specified as formal requirements?

• Use environment analysis documenting conditions of use (clinical setting, home use, ambulance, operating room) and environmental requirements (EMC, temperature, humidity, altitude, cleaning/disinfection compatibility)
• User population analysis identifying user characteristics (training level, physical abilities, language, experience with similar devices) that drive usability requirements
• Foreseeable misuse analysis identifying ways the device could reasonably be misused and the design features or warnings needed to mitigate risk
• State-of-the-art analysis documenting performance levels and features expected based on existing technology and competitor products
• Documented requirements derived from the above analyses, with traceability to design inputs

• No formal analysis of unstated requirements was performed -- the organization relied entirely on customer-specified requirements and assumed the customer identified all needs
• Use environment analysis considered only the primary clinical setting (hospital) but did not address home use, ambulance transport, or field clinic environments where the device is also used
• Foreseeable misuse was not analyzed; the product lacks protection against reasonably foreseeable misuse scenarios such as incorrect sensor placement or use without the prescribed accessories
• State-of-the-art analysis was not performed, and the device lacks features that are standard in all competitor devices (e.g., audible alarms for critical parameters), which clinicians expect as baseline functionality

Review the use environment and user population analyses for the sampled product. Verify that unstated requirements are documented and traceable to design inputs.

• How did you determine the use environment for this device? Were field visits conducted?
• What foreseeable misuse scenarios did you identify, and where are the corresponding design mitigations?
• Did you perform a competitive benchmarking or state-of-the-art analysis for this product?

• Regulatory requirements matrix listing all applicable regulations, standards, and guidance documents per intended market -- with specific clause references, not just standard numbers
• Process for identifying applicable regulatory requirements including regulatory intelligence sources (FDA database, EUDAMED, national CA databases, standards bodies)
• Evidence of regulatory requirement updates -- show that the matrix has been reviewed and updated within the past 12 months or when a new regulation took effect
• Competence records for the person(s) responsible for regulatory requirements identification -- regulatory affairs qualifications, training, experience
• Gap analysis between current product compliance and newly identified or changed regulatory requirements

• Regulatory requirements matrix lists 'ISO 13485' and 'FDA 21 CFR 820' at the standard level but does not break down requirements to the specific clause level -- individual requirements are not traceable to design inputs
• Product is marketed in Japan but the regulatory matrix does not include PMDA requirements or J-PAL/JIS standards -- only FDA and EU requirements are addressed
• No process exists for monitoring regulatory changes; the organization learned about the EU MDR transition from a customer inquiry rather than proactive regulatory intelligence
• Regulatory requirements were identified by a sales manager with no regulatory affairs training or qualifications -- critical requirements for biocompatibility (ISO 10993) and electrical safety (IEC 60601-1) were omitted
• Essential Requirements checklist for EU MDR references the MDD Essential Requirements rather than the updated GSPR (General Safety and Performance Requirements) of EU MDR Annex I

Review the regulatory matrix for the sampled product. Verify it covers all intended markets at the clause level and has been updated within the past 12 months.

• Has this regulatory matrix been updated since the FDA QMSR final rule took effect?
• How do you monitor regulatory changes in your intended markets?
• Show me the competence records for the person who maintains this regulatory matrix.

• Training needs assessment document identifying who needs training (user roles), what training is needed (content), when training is required (before first use, refresher intervals), and how competency is verified
• Instructions for Use (IFU) reviewed for adequacy -- covering safe use, contraindications, warnings, maintenance, troubleshooting, and disposal
• Clinical training materials including hands-on training protocols, simulation scenarios, and competency checklists
• Training delivery records or train-the-trainer program documentation for distributor-managed training
• Post-market data (complaints, adverse events) analyzed for training-related root causes -- evidence that training adequacy is monitored and updated

• No formal training needs assessment was performed -- the organization assumed the IFU was sufficient for user training without evaluating user competency requirements or the learning curve for complex device features
• Training materials were developed by marketing without clinical input and do not address safety-critical procedures such as device insertion, calibration verification, or emergency shutdown
• Training is offered but is not mandatory before first use -- hospitals can purchase and use the device with no requirement to complete training, despite the device requiring specialized clinical skills
• Training effectiveness is not evaluated -- there is no competency assessment, post-training test, or observed competency verification for any user group
• Post-market surveillance identified a cluster of use errors attributable to inadequate training, but the training needs assessment and IFU have not been updated to address the identified knowledge gaps

Review the training needs assessment and a sample of training materials for the sampled product. Cross-reference with post-market complaint data for use-error trends.

• Is user training mandatory before first use of this device? How is this enforced?
• How do you verify that training was effective -- is there a competency assessment?
• Have any complaints or adverse events been attributed to inadequate user training?

• Organizational requirements document or section within the product requirements specification covering internally driven requirements
• Manufacturing requirements including process constraints, equipment compatibility, production capacity, yield targets, and clean room classification requirements
• Cost targets including target cost of goods (COGS), maximum component costs, and cost reduction roadmap
• Platform or product family compatibility requirements ensuring the new product integrates with existing product lines, accessories, and software systems
• Supply chain requirements including sole-source avoidance, lead time constraints, and geographic sourcing restrictions
• Service and support requirements including field serviceability, diagnostic capabilities, remote monitoring, and spare parts strategy

• No organizational requirements were formally identified -- the quality plan addresses customer and regulatory requirements but does not document internal manufacturing constraints or cost targets that influenced design decisions
• Manufacturing constraints were communicated verbally to the design team but were never documented as formal requirements -- the product was designed with a component that cannot be soldered with existing reflow equipment
• Platform compatibility requirements were not specified, and the new device uses a different connector, power supply, and software interface than the existing product family, creating user confusion and inventory proliferation
• Cost targets were set by finance but not formally included in the product requirements -- the design met all technical requirements but exceeded the target COGS by 40%, making the product commercially unviable

Review the product requirements for the sampled product and verify that organizational requirements (manufacturing, cost, platform, service) are documented alongside customer and regulatory requirements.

• Were manufacturing constraints identified before design input review, or were they discovered during design transfer?
• Does this product need to be compatible with existing products in your portfolio? Where is that requirement documented?
• How are cost targets established and tracked as formal product requirements?

• Contract review procedure defining review criteria, timing (before commitment), authority levels, and documentation requirements
• Completed contract review records for the 3 sampled orders showing each of the five criteria (7.2.2 a-e) was evaluated with documented evidence
• Evidence that review occurred BEFORE commitment to supply -- timestamps showing review completion before order acceptance or contract signature
• Records of resolution of differences between quoted/proposed requirements and final contract requirements (7.2.2b)
• Feasibility or capability assessment records demonstrating the organization evaluated its ability to meet the defined requirements (7.2.2e)
• Evidence of management or authorized person approval for non-standard or high-risk orders

• Contract review is performed after the order has been accepted -- the sales team commits to delivery dates and specifications before QA, regulatory, or manufacturing review of the requirements
• Contract review for the sampled custom product order addresses pricing and delivery but does not evaluate regulatory compliance (7.2.2c), training availability (7.2.2d), or manufacturing capability (7.2.2e)
• An order amendment changed the sterilization method from EtO to gamma irradiation, but no contract review was performed for the amendment -- the original review was not updated to reflect the changed requirement
• Contract review records consist of a single signature on the purchase order with no evidence of what was actually reviewed or how the five criteria were assessed
• The organization accepted an order significantly exceeding its production capacity without a capability assessment -- chronic backorders and delivery failures resulted

Sample 3 contract/order reviews: one standard, one custom/modified, and one with post-acceptance amendments. Verify timing (before commitment) and substantive evaluation of all five criteria.

• Show me the timeline -- when was this contract review completed relative to when the order was accepted?
• For the custom product order, how did you assess whether you have the capability to meet the modified requirements?
• When the requirements changed after initial agreement, what triggered a new review?

• Product requirements document or specification referenced in the contract review, showing requirements are defined with measurable criteria
• Completeness check evidence -- a requirements checklist or review form showing all requirement categories were evaluated
• Records of requirements clarification -- correspondence or meeting notes where ambiguous or incomplete requirements were identified and resolved before acceptance
• Traceability from contract requirements to internal product specifications showing requirements were formally translated into design inputs or production specifications

• Contract references 'current product specification' without identifying the specific revision number -- when the specification was updated post-contract, the customer expected the original version
• Product requirements in the contract include subjective language ('high quality finish,' 'suitable for clinical use') that is not defined with measurable acceptance criteria
• Requirements review identified missing EMC requirements for the customer's use environment, but the order was accepted before the requirements were resolved -- clarification was deferred to 'after order acceptance'
• Contract specifies performance requirements but does not define the test method or conditions under which performance will be measured, leading to disputes during acceptance testing

Review the requirements documentation referenced in the sampled contracts. Check for ambiguous language, missing specification revisions, and deferred clarifications.

• Were any requirements in this contract identified as ambiguous or incomplete during review? How were they resolved?
• Does the contract reference a specific revision of the product specification?
• How do you handle verbal requirements from the customer that are not in the written contract?

• Comparison records showing a side-by-side review of quoted or proposed requirements versus final contract or order requirements
• Documented differences identified during comparison with resolution records showing how each difference was resolved and agreed upon
• Customer acknowledgment or agreement records for resolved differences
• Amendment or change order documentation when differences resulted in contract modifications

• No formal comparison between the proposal/quotation and the final purchase order was performed -- the order was processed based on the PO alone without verifying consistency with the original quotation
• Customer's purchase order specified a different sterilization method than what was quoted, but the difference was not identified during contract review -- it was discovered during production planning
• Differences were identified but resolution was not documented -- verbal agreement with the customer was made but no written confirmation exists
• Proposal specified delivery in 12 weeks but the purchase order specified 8 weeks -- the difference was not flagged during contract review, resulting in a late delivery and customer escalation

Select an order where the final PO differed from the initial quotation and verify the difference was identified and resolved during contract review.

• Show me the original quotation for this order alongside the purchase order -- were any differences identified?
• How do you handle situations where the customer's purchase order includes terms that differ from your proposal?
• Is there a documented agreement from the customer on how the differences were resolved?

• Regulatory compliance verification within the contract review -- documented check that the product has the required clearance/approval/registration for the market specified in the order
• Market authorization status register showing current clearance/approval status per market
• Evidence that market-specific requirements (labeling language, UDI, country-specific packaging, import licenses) were verified as achievable before order acceptance
• Policy or procedure for handling orders for markets where clearance is pending -- including communication to the customer and conditional acceptance controls

• Contract review does not include a regulatory compliance check -- there is no step to verify the product is cleared/approved for the market specified in the order
• An order was accepted for distribution in Brazil, but the ANVISA registration had expired 6 months earlier -- the contract review process did not check registration status
• Product was shipped to a market where the labeling did not meet local language requirements because the contract review did not evaluate market-specific labeling obligations
• Orders for a new product variant were accepted before 510(k) clearance was obtained, with no conditional acceptance controls or customer notification of the regulatory status

For the sampled orders, verify regulatory clearance status for the specific product-market combination. Check at least one order for a secondary market.

• How do you verify the regulatory clearance status before accepting an order? Is there a register or database you check?
• Have you ever had to reject or delay an order because regulatory clearance was not in place?
• How do you handle orders for markets that require specific labeling languages or UDI formats?

• Contract review records showing a check that user training is available or scheduled before product delivery
• Training availability schedule or rollout plan demonstrating training readiness for the product and market
• Customer training completion records or training enrollment confirmation referenced during contract review
• Conditional order acceptance records where delivery is contingent on training completion
• Distributor training agreements specifying training obligations and timelines

• Contract review does not include a training availability check -- the product was delivered before user training was available, resulting in improper use and a complaint
• Training is listed as available on the company website, but the online training module is still under development -- the contract review accepted the status without verifying the training was actually functional
• A distributor order was accepted without verifying the distributor's clinical training capability, despite the product requiring hands-on clinical training before use
• Training materials are available only in English, but the order is for a French-speaking market -- the contract review did not check language availability of training materials

Review 2-3 contract review records for products requiring user training. Verify training availability was checked and that training materials exist in appropriate languages.

• Is training for this product mandatory before first clinical use? How is this enforced?
• For distributor orders, how do you verify the distributor can deliver the required training?
• What happens if a customer orders the product but has not completed training -- do you have a hold or conditional release process?

• Capability or feasibility assessment records within the contract review -- documented evaluation of manufacturing capacity, technical capability, and resource availability
• Production capacity analysis showing current utilization, available capacity, and lead time for the ordered quantity
• Supply chain readiness assessment for critical components including lead times, inventory levels, and supplier capacity constraints
• Technical feasibility evaluation for custom or modified product orders showing the organization can meet the specified requirements
• Risk assessment for orders that require new capabilities, processes, or supplier qualifications not currently in place

• No formal capability assessment is performed during contract review -- the sales team commits to delivery dates based on standard lead times without checking actual production capacity or component availability
• A capability assessment was performed but used data that was 6 months old -- actual production capacity had decreased due to equipment downtime and personnel turnover, resulting in delivery delays
• Custom product order was accepted without evaluating whether the required manufacturing process (laser welding) is available and validated -- the organization does not have this capability in-house and no contract manufacturer was identified
• Capability assessment considers only manufacturing but does not evaluate test capability -- the product requires EMC testing that must be outsourced, and the test lab has a 12-week backlog
• A large order was accepted based on existing production capacity without a documented plan to scale production, resulting in chronic backorders

Review the capability assessments for the 3 sampled orders, focusing on the custom/modified order and the largest-volume order.

• How do you assess current production capacity when reviewing a new order? Are capacity data real-time or periodic?
• Show me how you assessed capability for the custom product order -- did you evaluate test capability and supplier readiness in addition to manufacturing?
• Have you ever declined or conditioned an order based on a capability assessment finding?

• Customer communication procedure or plan defining channels, responsibilities, response timeframes, and escalation paths for each of the four categories
• Product information distribution records -- catalogs, technical bulletins, IFU updates, product notifications sent to customers in the past 6 months
• Enquiry and order communication records showing timely response to customer questions, order confirmations, and amendment handling
• Customer feedback and complaint communication records showing receipt acknowledgment, investigation updates, and resolution communication
• Advisory notice records including Field Safety Corrective Action (FSCA) distribution, customer acknowledgment tracking, and effectiveness verification
• Customer communication metrics -- response time tracking, customer satisfaction data, complaint response time compliance

• Customer communication procedure covers sales enquiries and order processing but does not address advisory notices (FSCAs) or product information distribution -- these are managed ad hoc by different departments
• No documented arrangements exist for communicating product information updates -- when the IFU was revised, some distributors were not notified and continued distributing the obsolete version
• Customer complaint communication has no defined response timeframe -- the procedure states 'timely response' without specifying a quantitative target, and some complaints have no acknowledgment for over 30 days
• Advisory notice procedure exists but distribution lists are outdated -- customer who purchased the affected product through a distributor was not in the distribution list and did not receive the notice
• Communication arrangements are defined for direct customers but do not address communication through distributors -- there is no requirement for distributors to forward product information or advisory notices to end users

Review records for each of the four communication categories from the past 6 months. Verify advisory notice distribution lists are current.

• How do you ensure advisory notices reach end users when your products are sold through distributors?
• Show me the response time metrics for customer complaints -- what is your target and actual performance?
• When was the customer distribution list for advisory notices last reviewed and updated?

• Product information distribution procedure defining what information is communicated, when, how, and to whom
• Records of recent product information distribution -- IFU updates, specification changes, new product announcements, product discontinuation notices
• Version control of customer-facing product information -- evidence that outdated information is withdrawn or marked as superseded
• Website or portal content management showing product information is current and accurate
• Distribution records showing information reached all relevant customers and customer types (direct, distributors, end users)

• Product information on the company website has not been updated to reflect the latest IFU revision -- customers downloading the IFU receive an obsolete version with outdated safety warnings
• Product specification changes are communicated to direct customers but not to distributors -- distributors continue providing old specifications to end users
• No formal process exists for communicating product discontinuation to customers who rely on the product for ongoing patient care
• Product catalog lists a feature that was removed in the latest product revision -- marketing materials have not been updated to reflect the design change

Compare the current IFU revision in the document control system against the version available on the website and the version provided by a distributor.

• When the IFU was last revised, how did you ensure all distribution channels received the update?
• How do you manage product information accuracy on your website and in marketing materials?
• How do you communicate product discontinuation or end-of-life to customers?

• Enquiry and order handling procedure defining receipt, logging, routing, response, and confirmation processes
• CRM or order management system records showing enquiry tracking, response times, and order processing workflow
• Order confirmation records showing customer received written confirmation of accepted requirements
• Amendment handling records showing how post-order changes are documented, reviewed, and communicated to all affected parties (customer, production, quality)
• Response time metrics showing performance against defined targets for enquiries and order confirmations

• No formal system for tracking customer enquiries -- enquiries are received via email by individual sales representatives with no centralized log, and some enquiries go unanswered
• Order amendments are communicated verbally between the customer and sales representative but are not formally documented or communicated to production, resulting in products manufactured to the original specification
• Customer receives no written confirmation of accepted order requirements -- the only documentation is the customer's purchase order, which may differ from what the organization intends to deliver
• Response time for technical enquiries averages 15 business days with no defined target or escalation path for overdue responses

Review 3-5 recent customer enquiries and orders. Check response times and trace one post-order amendment through to production.

• Show me how a post-order amendment flows from the customer through to production -- what documents are updated?
• How do you ensure no customer enquiries are lost or go unanswered?
• Do customers receive a written confirmation of the requirements you have accepted?

• Customer feedback and complaint handling procedure defining channels for receiving feedback, triage criteria, investigation process, response requirements, and escalation paths
• Complaint log or database showing all complaints received in the past 12 months with status tracking (open, under investigation, resolved, closed)
• Sample complaint records showing receipt acknowledgment (with date), investigation, root cause determination, corrective action, and resolution communication to the customer
• Feedback trend analysis showing how complaint data and customer feedback are analyzed for patterns and fed into CAPA and management review
• Response time metrics for complaint acknowledgment and resolution -- with defined targets and actual performance data

• Customer feedback channel captures only formal written complaints -- verbal feedback from field service technicians, distributor reports, and clinical user observations are not captured in the complaint system
• Complaint handling procedure defines the investigation process but does not specify a response time for acknowledging receipt to the customer -- several complaints have no acknowledgment for over 60 days
• Complaint trend analysis is performed annually for management review but is not used for ongoing CAPA identification -- recurring complaints are investigated individually without recognizing the systemic pattern
• Distributor complaints are received by the sales team and are not consistently forwarded to the quality team for investigation -- several complaints were found in sales email archives that were never entered in the complaint system
• Customer is not informed of the investigation outcome or corrective actions taken -- the complaint file shows internal resolution but no evidence of communication back to the customer

Review 5-10 complaints from the past 12 months, including at least one from a distributor channel. Check acknowledgment timing, investigation completeness, and customer communication.

• How do you ensure that distributor-received complaints are forwarded to your quality team?
• Show me the complaint trend analysis for the past 12 months -- what patterns were identified and what actions were taken?
• How is the customer informed of the investigation outcome and corrective actions?

• Advisory notice procedure defining triggers for issuing a notice, content requirements, distribution mechanisms, acknowledgment tracking, effectiveness verification, and regulatory reporting
• Distribution list for advisory notices -- showing all affected customers, distributors, and regulatory authorities by market
• Records of a recent advisory notice (or drill/mock recall) showing the notice content, distribution records, acknowledgment tracking, and effectiveness measurement
• Acknowledgment tracking records showing the percentage of customers who confirmed receipt and understanding of the notice
• Effectiveness verification records showing that the corrective action was implemented by the affected customer base (e.g., devices returned, software updated, IFU replaced)
• Regulatory authority notification records associated with the advisory notice (FDA MDR, EU vigilance report)

• Advisory notice procedure exists but has never been tested through a mock recall or drill -- the organization cannot demonstrate the process works in practice
• Distribution list for advisory notices is maintained by sales and has not been updated for an extended period -- customers who purchased through distributors since the last update are not in the list
• Advisory notice was issued but acknowledgment tracking shows a minority of affected customers confirmed receipt -- no follow-up actions were taken to reach the remaining 55%
• No effectiveness verification was performed after the advisory notice -- the organization issued the notice but did not verify that the corrective action (device return, software update) was actually implemented by customers
• Advisory notice was issued to direct customers but distributors were not required to forward the notice to their end users -- the distribution agreement does not include advisory notice forwarding obligations

Review the most recent advisory notice or mock recall drill. Check distribution list currency, acknowledgment rate, and effectiveness verification. Review distributor agreements for advisory notice forwarding clauses.

• When was your last mock recall or FSCA drill? What was the acknowledgment rate and how quickly did you achieve it?
• How do you trace products sold through distributors to the end users for advisory notice distribution?
• What is your process for following up with customers who do not acknowledge an advisory notice?
• Do your distribution agreements require distributors to forward advisory notices to end users?

• Master design and development control procedure covering all elements of 7.3.1 through 7.3.10 -- with defined stage-gate process, deliverables per gate, approval criteria, and roles/authorities
• Supporting procedures or work instructions for specific design activities: design review conduct, V&V protocol development and execution, design transfer checklist, design change control, DHF management
• Design and development procedure revision history showing the procedure has been maintained and updated
• List of active design projects with current phase/stage status, and list of products released through the design process in the past 3 years
• Templates used for design planning, design inputs, design reviews, V&V protocols, design transfer, and design changes -- to assess consistency and completeness
• Training records demonstrating that design team members have been trained on the design and development procedures

• Design and development procedure is a high-level policy document that states 'design shall be planned and controlled' but does not define the stage-gate process, deliverables per stage, or gate criteria -- project teams are left to determine their own approach
• Procedure covers hardware design but does not address software design and development lifecycle (IEC 62304), despite the organization developing software-controlled medical devices
• Procedure was written years ago based on a previous edition of ISO 13485 and has not been updated for the current edition -- notably missing: design transfer requirements (7.3.8) and DHF requirements (7.3.10)
• Design team members have not been trained on the current revision of the design procedure -- training records show training on Revision B, but the procedure is now on Revision E
• Procedure exists but compliance is inconsistent -- some projects follow the procedure rigorously while others take shortcuts, and there is no mechanism to audit or enforce compliance across projects

Request the list of all design projects (active and completed in the past 3 years). Select 2 completed DHFs and 1 in-progress project for detailed review. Include at least one higher-risk device (Class II or III).

• How many active design projects do you have, and which are closest to design transfer?
• Does your design procedure address software design lifecycle per IEC 62304?
• When was this procedure last revised, and what prompted the revision?

• Design and Development Plan for each sampled project -- showing all required elements: stages (7.3.2a), review/V&V/transfer activities per stage (7.3.2b), responsibilities and authorities (7.3.2c), traceability methods (7.3.2d), resource requirements and competencies (7.3.2e/f)
• Plan revision history demonstrating the plan was updated as the project progressed -- compare Rev A (initial) against the current revision to see what changed
• Evidence that the plan was reviewed and approved by cross-functional stakeholders (R&D, QA, RA, Manufacturing, Clinical) before design work began
• Comparison between the planned activities/timeline and what actually occurred -- were stages added, removed, or resequenced during the project?
• For the in-progress project: current plan showing where the project stands relative to the plan, and any deviations or updates required

• Design plan for the completed project is Revision A (original version) with no updates despite the project spanning 3 years with multiple scope changes, additional regulatory submissions, and a 6-month delay -- the plan is not a living document
• Design plan was copied from a previous project template without tailoring -- the sampled project is for a Class III implantable device but the plan uses the same stages, timelines, and V&V activities as a Class I device plan
• Design plan does not define traceability methods (7.3.2d) -- there is no description of how design outputs will be traced back to design inputs, and no traceability matrix was planned
• Responsibilities are defined only as 'R&D Department' without identifying specific individuals or roles -- approval authorities for design reviews, V&V protocol approval, and design transfer are not specified
• Design plan for the in-progress project was written retrospectively 6 months after design work began -- the plan post-dates the earliest design input documents and design review minutes

Sample 2 completed DHFs (one higher-risk, one lower-risk) and 1 in-progress project. Compare design plans across projects to assess tailoring and check revision histories.

• Show me the original version of this design plan and the current version -- what changed and why?
• How was this plan tailored for this specific product compared to your standard template?
• For the in-progress project, is the plan still accurate, or have there been deviations?
• Who approved this plan, and were all relevant functions involved?

• Stage definitions within the design plan -- name, purpose, key activities, required deliverables, and exit/gate criteria for each stage
• Gate review records for at least 2 stage gates -- showing deliverables presented, evaluation against gate criteria, attendees, and the documented go/no-go decision
• Evidence that gate criteria were met before advancing -- not just a signature but documented assessment of each criterion
• Records of any stage gate that resulted in a hold or conditional proceed -- showing how conditions were resolved before advancing
• Comparison of planned stages against actual execution -- were any stages skipped, combined, or repeated?

• Design plan defines stages (concept, development, verification, validation, transfer) but does not define specific exit criteria or deliverables for each gate -- the decision to advance is based on informal consensus rather than documented criteria
• Gate review for the feasibility-to-development transition was conducted after detailed design work had already begun -- the gate review was a formality that rubber-stamped work already in progress
• The concept stage was skipped entirely -- design work began directly from a customer request with no formal concept evaluation, feasibility assessment, or initial risk assessment
• Gate review record shows all criteria marked as 'met' with no supporting evidence or discussion -- the record is a signature page with no assessment of individual deliverables
• Stage definitions are identical for all projects regardless of device classification, risk level, or complexity -- a Class I accessory follows the same 7-stage process as a Class III active implantable device

Review gate records for 2-3 stage transitions in the sampled projects. Focus on gates where the decision was most consequential (feasibility to development, validation to transfer).

• Show me a gate review where there were open issues or conditions -- how were they resolved before proceeding?
• Has a project ever been held or killed at a gate review? If not, how do you know the gate process is effective?
• Are design stages tailored by device risk classification, or does every project follow the same stages?

• V&V master plan or protocol index mapping specific verification and validation activities to design stages -- showing which tests, analyses, and reviews occur at each stage
• Design plan sections showing review, verification, validation, and transfer activities assigned to specific stages with rationale for the assignment
• Protocol development timeline showing V&V protocols were planned and prepared before the testing phase, not written concurrently with or after testing
• Design review schedule showing planned reviews at each stage and the actual review dates
• Design transfer plan or checklist showing when transfer activities begin and what must be completed before production release

• Design plan lists 'verification and validation' as activities in the V&V stage but does not map specific V&V activities to earlier stages -- component-level verification that should occur during development is deferred to the system V&V stage, creating a bottleneck and reducing the ability to identify issues early
• No V&V master plan exists -- V&V protocols were developed individually as needed during the project with no overall plan showing completeness or mapping to design inputs
• Design reviews are scheduled at each stage gate but are the only review activity -- there are no interim technical reviews, peer reviews, or design trade-off reviews within stages
• Design transfer is shown as a single event at the end of the project rather than a progressive series of activities integrated throughout development (e.g., DFM reviews during development, process capability studies during verification)
• Validation activities are all planned for the final stage, but the design plan does not account for the time required for clinical evaluation, biocompatibility testing, or software validation -- the schedule is unrealistic

Review the V&V master plan for one completed project and verify activities are mapped to stages. Check that the plan was approved before V&V execution began.

• At which stage does component-level verification begin? Is it before or after system-level V&V?
• How do you ensure V&V completeness -- that every design input has a corresponding verification or validation activity?
• When do design transfer activities begin -- at what stage?

• RACI matrix or responsibility assignment matrix within the design plan showing specific assignments for all design activities including inputs, outputs, reviews, V&V, transfer, and changes
• Design team roster with defined roles (project lead, systems engineer, V&V engineer, quality engineer, regulatory specialist, manufacturing engineer, clinical specialist) and named individuals
• Approval authority matrix showing who can approve key design decisions and deliverables -- with evidence of independence for design reviews (reviewer not the same person who performed the design work)
• Evidence that responsibilities were communicated and accepted -- team charter, kick-off meeting minutes, or signed role descriptions
• Delegation records where the primary responsible person was unavailable and authority was formally delegated

• Design plan assigns responsibilities to departments ('R&D,' 'Quality') rather than specific roles or individuals -- when personnel change, there is no clarity on who is responsible for specific design activities
• Design reviews are conducted and approved by the design project lead who also performed the design work -- there is no independence between the designer and the reviewer, violating the principle of independent review
• No RACI matrix or equivalent exists -- responsibilities are assumed based on job titles rather than formally assigned and documented in the project plan
• V&V protocol approval authority is assigned to the R&D manager who also serves as the project lead -- the person approving the test approach is the same person whose design is being tested
• Manufacturing engineering is not assigned any responsibilities in the design plan despite the product requiring complex manufacturing processes -- manufacturing involvement begins only at design transfer, too late to influence design for manufacturability

Review the responsibility assignments for the sampled projects. Check design review attendance records to verify independence. Verify cross-functional involvement throughout the project, not just at gate reviews.

• Who conducts design reviews, and are they independent of the design work being reviewed?
• When the lead V&V engineer was on leave during protocol execution, how was authority delegated?
• At what point in the project does manufacturing engineering get involved?

• Design traceability matrix (DTM) or requirements traceability matrix (RTM) linking: design inputs → design outputs → verification activities → validation activities -- with unique identifiers at each level
• Evidence that the matrix is maintained as a living document throughout the project -- revision history showing updates as requirements were added, changed, or deleted
• Traceability coverage analysis showing: (a) all inputs are traced to outputs (forward traceability), (b) all outputs are traced back to inputs (backward traceability), (c) all inputs have verification or validation coverage
• Gap analysis or completeness report from the traceability matrix -- any requirements without verification/validation coverage identified and addressed
• Tool or system used for traceability management (e.g., DOORS, Jama, Polarion, Excel) and evidence of its validation if used for regulatory purposes

• Traceability matrix exists but links design inputs to design outputs only -- there is no forward traceability to verification and validation activities, making it impossible to confirm all requirements have been tested
• Traceability matrix was created at the end of the project (retrospectively) rather than maintained as a living document -- the matrix creation date post-dates the design transfer approval date
• 15 design inputs have no corresponding design outputs in the traceability matrix -- these requirements were not addressed in the design and the gap was not identified until the audit
• Traceability matrix uses vague links such as 'verified by system testing' without referencing specific test protocol numbers, test cases, or acceptance criteria -- the link is not auditable
• Design inputs were renumbered mid-project when the requirements management tool was changed, breaking the traceability chain -- the matrix references old requirement IDs that no longer exist in the current system

Review the traceability matrix for one completed project. Perform forward traceability (3 inputs to V&V) and backward traceability (3 V&V activities to inputs). Identify any gaps.

• Pick 3 design inputs at random -- can you trace each one forward to the specific test that verifies it?
• When were the last updates made to this traceability matrix? Was it before or after design transfer?
• Are there any requirements in the matrix with no verification or validation coverage? How would you know?
• If a design input changes, how does the change propagate through the traceability matrix to identify affected tests?

• Resource requirements section of the design plan identifying specific personnel competencies, equipment, facilities, software, and external resources needed for the project
• Competency requirements for design team members -- education, training, experience, and skills required for their assigned roles
• Equipment and facility requirements including specialized test equipment, clean room access, prototyping capabilities, and their availability status
• External resource identification -- contract labs, consultants, clinical investigation sites, and contract manufacturers with qualification status
• Resource gap analysis and mitigation plan -- documenting how identified gaps (missing competencies, unavailable equipment) were addressed

• Resource requirements in the design plan list only headcount ('3 engineers') without defining the specific competencies required -- the project required biocompatibility expertise but no team member had this competency
• The project required use of a finite element analysis (FEA) software tool that was not validated for regulatory use -- the validation gap was not identified during resource planning
• External test lab was identified in the resource plan but its ISO 17025 accreditation had expired -- the accreditation status was not verified before sending samples for testing
• No resource planning was performed -- the design plan does not contain a resource section, and resources were allocated on an ad hoc basis as needs arose during the project
• Clinical investigation sites were needed for design validation but were not identified or qualified until 4 months into the validation phase, delaying the project by 6 months

Review the resource section of the design plan for one sampled project. Verify competency records for 2-3 key team members. Check qualification status of any external test labs used.

• What specific competencies were required for this project that were not available in-house?
• Were any resource gaps discovered during the project that should have been identified during planning?
• How was the external test lab qualified before being used for regulatory testing?

• Competence records for key design team members -- education, training, certifications, and relevant experience documented per clause 6.2
• Role-specific competency requirements defined in the design plan or job descriptions, matched against actual competence records
• Training records for design-specific skills: design control procedures, risk management (ISO 14971), usability engineering (IEC 62366), software lifecycle (IEC 62304), statistical methods
• Evidence of competence assessment -- not just attendance at training, but verification that competence was achieved (test, evaluation, supervised work)
• Records for any external consultants or contractors showing their qualifications and competence for the work performed

• Competency requirements for the design project are not defined -- there is no documented basis for determining what education, training, or experience is required for each role in the design team
• Design team member responsible for biocompatibility assessment has no training or experience in ISO 10993 -- competence was assumed based on their engineering degree without evaluating specific competency needs
• Training records show attendance at a brief design control overview training years ago, but no ongoing competence maintenance or refresher training -- competence is treated as a one-time event
• External consultant performing EMC testing has no documented qualifications or competence records on file -- the organization relied on the consulting firm's reputation without verifying individual competence
• Software developers have no documented training on IEC 62304 despite developing safety-critical software classified as Class B -- software design lifecycle competence is assumed based on programming experience

Select 2-3 design team members with specialized roles (V&V lead, risk management lead, software lead). Review their competence records against the defined requirements for their role.

• How do you determine what competencies are required for each role in a design project?
• Show me the competence assessment for the person who performed the risk analysis -- what qualifies them for this work?
• How do you maintain competence records for external consultants and contractors?

• Design Input Document or Product Requirements Specification containing all five categories of inputs with unique requirement identifiers
• Design input review records showing each requirement was evaluated for completeness, unambiguity, testability, and absence of conflicts -- with evidence of cross-functional review
• Design input approval records with signatures from R&D, Quality, Regulatory, Clinical, and Manufacturing representatives
• Evidence that design inputs are verifiable -- each requirement can be objectively tested or measured against defined criteria
• Records of input changes during the project -- design input revisions with impact assessment and re-approval
• Evidence that inputs were baselined (approved) before design output work began

• Design inputs address performance and functional requirements (7.3.3a) but omit usability requirements -- for a device used by home patients, there are no requirements for user interface simplicity, error prevention, or accessibility for elderly users
• Risk management outputs (7.3.3c) are not included as design inputs -- the risk management file identifies hazards and risk controls, but these are not formally captured in the design input document as requirements to be designed into the product
• Information from previous similar designs (7.3.3d) was not considered -- the organization's prior-generation device had a known failure mode that was addressed through a field corrective action, but the corrective action was not captured as a design input for the successor product
• Design inputs were not formally reviewed and approved before design work began -- the earliest design output documents pre-date the design input approval date by 3 months
• Design inputs contain subjective, non-verifiable requirements such as 'the device shall be easy to use' and 'the device shall be reliable' with no quantitative criteria or test methods defined

Review the complete design input package for one completed and one in-progress project. Check all five categories, verify approvals, and spot-check 5 requirements for verifiability.

• Show me a requirement that you consider non-verifiable -- how would you test 'the device shall be easy to use'?
• Which requirements came from risk management outputs? Show me the link between the risk file and design inputs.
• What lessons learned from the predecessor product were captured as design inputs for this project?
• Were any design inputs added or changed after the initial baseline? Show me the change records.

• Functional requirements with measurable performance criteria (e.g., measurement accuracy, throughput, response time, operating range)
• Performance specifications with quantitative limits and tolerances (e.g., 'measurement accuracy within +/- 5% across 20-40 degrees C operating range')
• Usability requirements derived from user profile analysis, task analysis, use environment analysis, and formative usability studies per IEC 62366-1
• Safety requirements derived from hazard analysis and risk assessment per ISO 14971 -- traceable to specific hazards and risk control measures
• Intended use statement that forms the basis for deriving all functional, performance, usability, and safety requirements

• Performance requirements specify 'measurement accuracy per IEC 60601-2-XX' without defining the specific accuracy requirement -- the standard provides a range of acceptable limits and the organization has not selected or justified a specific target
• Usability requirements are absent -- the design inputs include functional and performance requirements but do not address user interface design, error prevention, learnability, or accessibility despite the device being used by untrained home patients
• Safety requirements consist only of 'the device shall be safe' with no specific, testable safety criteria derived from the risk assessment -- there is no link between identified hazards and design input requirements
• Intended use statement is vague ('for diagnostic use in clinical settings') and does not specify the patient population, clinical indication, user profile, or use environment with sufficient precision to derive design requirements
• Functional requirements address normal operating conditions but do not address fault conditions, degraded performance modes, or end-of-life behavior

Review the functional, performance, usability, and safety requirements for the sampled product. Verify usability requirements exist and trace 2-3 safety requirements back to the risk management file.

• How were usability requirements derived? Was a formative usability study conducted?
• Show me the link between a specific hazard in the risk file and the corresponding safety requirement in design inputs.
• What fault conditions are addressed in your functional requirements?

• Regulatory requirements matrix listing all applicable regulations and standards at the clause level -- not just 'IEC 60601-1' but specific applicable clauses with pass/fail criteria
• Standards applicability assessment documenting the rationale for including or excluding specific standards (e.g., 'IEC 60601-1-2 EMC applicable because the device is electrically powered; IEC 60601-1-6 usability applicable because the device has a user interface')
• Market-specific regulatory requirements for all intended markets including product classification, regulatory pathway, essential requirements or GSPRs, and labeling requirements
• Process for monitoring standard revisions and regulatory changes during multi-year projects -- including impact assessment when a new edition of an applicable standard is published during design
• Evidence that regulatory requirements were reviewed and approved by a qualified regulatory affairs professional

• Regulatory requirements list consists only of standard numbers (e.g., 'IEC 60601-1, IEC 62304, ISO 14971') without identifying which specific clauses apply and what the specific requirements are -- the design inputs are not specific enough to drive design decisions or verification testing
• Product is intended for the EU market but the design inputs reference the Medical Device Directive (93/42/EEC) essential requirements rather than the EU MDR (2017/745) General Safety and Performance Requirements -- the regulatory transition was not reflected in design inputs
• Applicable standard IEC 60601-1 was updated to Edition 3.2 during the design project, but the design inputs still reference Edition 3.1 -- no impact assessment of the standard revision was performed
• Biocompatibility standard ISO 10993-1 is listed as applicable but the specific evaluation categories (cytotoxicity, sensitization, irritation, etc.) applicable to the device's contact nature and duration are not specified as design inputs
• Regulatory requirements were identified by the project engineer without involvement of regulatory affairs -- IVD-specific requirements (EU IVDR for diagnostic devices) were not identified

Review the regulatory matrix for one sampled project. Verify requirements are at the clause level. Check that standard editions are current and that a qualified RA professional was involved.

• Show me the specific IEC 60601-1 clauses that apply to this device -- not just the standard number.
• Has IEC 60601-1 been updated since your design inputs were approved? How did you assess the impact?
• Who identified the applicable regulatory requirements? Show me their regulatory affairs qualifications.

• Risk management file showing identified hazards, estimated risks, and specified risk control measures
• Traceability from risk control measures in the risk file to specific design input requirements -- showing each risk control has been translated into a testable design requirement
• Design input requirements derived from risk analysis -- labeled or categorized as risk-derived requirements for traceability
• Evidence of bidirectional traceability: risk file references design input IDs, and design inputs reference risk file hazard/risk IDs
• Records showing risk management outputs were reviewed and incorporated into design inputs at appropriate points during the design process -- not just at the end

• Risk management file identifies risk controls (e.g., 'alarm shall sound when battery is critically low') but these controls are not captured as formal design input requirements -- the design team informally addresses the risks without documenting them as verifiable requirements
• Risk management is performed by a separate team and the outputs are contained in a standalone risk management file with no formal linkage to design inputs -- the risk file and the design input document reference different requirement numbering systems with no cross-reference
• Risk controls in the risk file are described at a high level ('protective earth connection') but the corresponding design input lacks the specific implementation requirement (impedance limit, test method) needed for verification
• Only the initial risk assessment outputs were incorporated as design inputs -- residual risks identified during design reviews and risk control verification were not fed back into design inputs for additional mitigation
• Software-related hazards identified in the FMEA are not reflected in the software requirements specification -- the SRS was developed independently of the risk management process

Select 3-5 risk controls from the risk management file. Trace each forward to design inputs, outputs, and V&V activities. Document any broken links.

• Pick 3 risk controls from the risk file -- can you show me the corresponding design input requirement for each?
• When a new hazard was identified during a design review, how was it incorporated as a design input?
• Are software safety requirements in the SRS traceable to hazards in the risk management file?

• Predicate or predecessor device analysis documenting which prior designs were considered and what information was derived from them
• Lessons learned review records from previous design projects -- covering both internal lessons and publicly available information (FDA MAUDE, recalls, literature)
• Complaint and CAPA history analysis for predecessor devices -- with identified failure modes and design changes captured as design inputs for the new project
• Field performance data review from similar devices including reliability data, failure analysis reports, and post-market surveillance findings
• Design input requirements explicitly derived from prior design experience -- labeled or traceable to the source (prior complaint, prior CAPA, prior field failure)

• No formal analysis of previous similar designs was performed -- the design team started from scratch without reviewing the predecessor device's complaint history, CAPA records, or field performance data
• Predecessor device had a field corrective action for a battery overheating issue, but this failure mode was not captured as a design input for the successor product -- the same failure mode was repeated
• Lessons learned from the prior project are documented in a post-project review report but were never formally reviewed as inputs to the new project -- the lessons learned system is disconnected from the design input process
• Predicate device analysis for the 510(k) submission was performed but is limited to substantial equivalence -- it does not include a review of the predicate's complaint history, recalls, or known limitations as design inputs
• Publicly available safety information (FDA MAUDE reports, recall databases) for similar devices on the market was not reviewed as part of design input determination

For the completed project, check the complaint and CAPA history of the predecessor device. Verify that known failure modes were captured as design inputs for the new project.

• What was the most significant lesson learned from the predecessor device, and where is it captured in design inputs?
• Did you review FDA MAUDE reports or recall databases for similar devices? What did you find?
• Were any CAPAs from the predecessor device addressed as design inputs for this project?

• Manufacturing requirements including process constraints, DFM considerations, equipment compatibility, clean room requirements, and yield targets captured as design inputs
• Sterilization requirements if applicable -- method, sterility assurance level (SAL), bioburden limits, material compatibility
• Packaging and labeling requirements including protection during transport, shelf life, UDI, and regulatory labeling requirements per market
• Service, maintenance, and installation requirements captured as design inputs -- field serviceability, diagnostic capabilities, calibration intervals, installation specifications
• Environmental and disposal requirements including RoHS compliance, REACH restrictions, WEEE obligations, biocompatibility of materials in contact, and environmental impact considerations

• Manufacturing constraints were not included as design inputs -- the product was designed with a component that requires a manufacturing process (ultrasonic welding) not available in-house, and this was discovered during design transfer
• Sterilization requirements were not specified as design inputs beyond 'must be sterile' -- the specific SAL (10^-6), bioburden limit, and material compatibility with the sterilization method were not defined until the sterilization validation phase
• Packaging and shelf-life requirements were omitted from design inputs -- accelerated aging testing was performed after design verification as an afterthought rather than as a planned activity based on defined shelf-life requirements
• Installation requirements were not captured as design inputs -- the device requires specific environmental conditions (temperature, humidity, vibration) and electrical infrastructure (dedicated circuit, UPS) that were not communicated to customers before purchase
• Disposal requirements including hazardous material handling and WEEE compliance were not considered as design inputs despite the product containing lithium batteries and mercury-containing components

Review the 'other requirements' category of design inputs for the sampled product. Check that manufacturing, sterilization, packaging, and disposal requirements are included.

• What manufacturing constraints were identified as design inputs? Were any constraints discovered too late during design transfer?
• Where are sterilization requirements specified in your design inputs? Are they specific (SAL, bioburden, material compatibility)?
• Are disposal and environmental requirements (RoHS, WEEE, hazardous material) captured as design inputs?

• Complete design output package including: device master record (DMR) contents, engineering drawings with tolerances, software specifications, bill of materials, manufacturing procedures, test procedures, labeling artwork, packaging specifications, and IFU
• Evidence that design outputs are in a form suitable for verification against design inputs -- each output is traceable to specific inputs via the traceability matrix
• Design output review and approval records showing cross-functional review (R&D, Quality, Regulatory, Manufacturing) with approval signatures and dates
• Evidence that outputs were approved BEFORE release to the next stage -- approval dates precede verification/validation protocol execution dates
• Comparison of design output completeness against the design plan deliverables list -- are all planned outputs present?

• Design outputs consist primarily of engineering drawings and a BOM but do not include manufacturing procedures, inspection procedures, or test procedures -- these were developed later by manufacturing without formal design output status or approval
• Design output approval records show a single signature from the R&D project lead -- there is no evidence of cross-functional review by Quality, Regulatory, or Manufacturing before release
• Design outputs are not in a form suitable for verification against inputs -- the design input specifies 'tensile strength > 50N' but the design output drawing does not include a tensile strength specification, making verification impossible without interpretation
• Software requirements specification exists as a design output but the source code, software architecture document, and software test procedures are not included in the design output package -- software design outputs are incomplete
• Design outputs for labeling do not include the UDI format, GMDN code, or market-specific language requirements despite being required design inputs -- outputs do not address all inputs

Review the design output package for one completed project. Verify completeness against the design plan deliverables. Check approval records and trace 3 outputs back to inputs.

• Show me the design output that addresses design input requirement [specific ID] -- can I verify the output meets the input?
• Who reviewed and approved these design outputs? Were Quality and Regulatory involved?
• Are manufacturing procedures and test procedures considered design outputs under document control, or are they developed separately?

• Traceability matrix showing each design input mapped to one or more design outputs that address the requirement
• Specific design output documents (drawings, specifications, procedures) that demonstrate how each selected input requirement is met
• Gap analysis or coverage report from the traceability matrix identifying any inputs without corresponding outputs
• Design review records where output-to-input compliance was assessed
• Records of any design inputs that were intentionally excluded from outputs -- with documented rationale and approval for the exclusion

• Several design input requirements have no corresponding design output in the traceability matrix -- these requirements were not addressed in the design and the gaps were not identified until audit
• Design output for a performance requirement ('operating temperature range 15-40C') consists only of a component datasheet showing the component operates in that range -- there is no system-level specification or verification that the assembled device operates in the full range
• Traceability is at the document level only ('output: Device Specification') rather than at the requirement level -- the design specification is 50 pages long, and the specific section addressing the input requirement is not identified
• Design input requirement for electromagnetic immunity was mapped to a design output, but the output specifies immunity levels below those required by the input -- the output does not actually meet the input

Select 5 design inputs at random from the traceability matrix and trace each to its corresponding output. Select 3 outputs and trace backward. Document any gaps.

• Show me the specific output that addresses design input [selected ID].
• Are there any design outputs that do not trace back to a design input? Why do they exist?
• How do you verify that the output actually meets the input, not just references it?

• Bill of materials (BOM) with component specifications, approved manufacturers/suppliers, and acceptance criteria sufficient for purchasing
• Manufacturing work instructions or process specifications with sufficient detail for production (process parameters, equipment settings, operator instructions, in-process controls)
• Inspection and test procedures for incoming, in-process, and final acceptance with equipment requirements and acceptance criteria
• Service and maintenance documentation including troubleshooting guides, spare parts lists, calibration procedures, and preventive maintenance schedules
• Evidence that production and service personnel can execute their tasks from the design output documentation without relying on undocumented tribal knowledge

• BOM lists generic component descriptions ('10k ohm resistor') without specifying package type, tolerance, temperature coefficient, or approved manufacturers -- purchasing cannot procure the correct components without contacting the design engineer
• Manufacturing work instructions for a critical assembly step state 'apply adhesive per engineering specification' but the referenced engineering specification does not define the adhesive type, quantity, cure time, or cure temperature -- operators rely on verbal instructions from the design engineer
• Service documentation does not exist -- field service technicians rely on design engineers to provide repair instructions on a case-by-case basis, creating a dependency on individual knowledge
• Test procedure specifies test equipment by generic description ('oscilloscope') without defining bandwidth, accuracy, or calibration requirements -- different test stations use different equipment, producing inconsistent results
• Design outputs provide production information but do not address installation requirements -- the device requires specific environmental conditions and utility connections that are not documented

Review the BOM, work instructions, and service documentation for one sampled product. Walk one manufacturing work instruction against actual production practice.

• If the design engineer who created this product left the company, could production continue without any loss of knowledge?
• Show me the work instruction for the most complex assembly step -- is it sufficient for a trained operator?
• Does field service have complete documentation to diagnose and repair this product?

• Product acceptance criteria documented in design outputs -- either embedded in the device specification or referenced in standalone acceptance test procedures
• Final release test protocol with specific pass/fail criteria for each test, traceability to the design input requirement being verified, and required test equipment
• Rationale documentation for acceptance criteria limits -- showing how limits were derived from design inputs, standards, or engineering analysis (not arbitrary)
• In-process acceptance criteria at critical manufacturing steps -- not just final release testing
• Statistical basis for acceptance sampling plans where applicable

• Design outputs reference acceptance criteria as 'per applicable specifications' without identifying the specific specification, revision, or test clause -- the acceptance criteria are not self-contained or auditable
• Final release acceptance criteria include functional testing but omit visual inspection criteria, labeling verification, and packaging integrity checks -- the release process does not verify all product requirements
• Acceptance criteria limits do not align with design input requirements -- design input specifies 'measurement accuracy +/- 5%' but the final release test acceptance criterion is '+/- 10%' with no documented rationale for the discrepancy
• Acceptance criteria are defined for the final product only, with no in-process acceptance criteria at critical manufacturing steps -- defective product is not detected until final test, increasing scrap and rework
• Acceptance criteria exist in an informal 'test engineering handbook' that is not a controlled document and is not referenced from the design outputs

Review the acceptance criteria for the sampled product. Trace 3 criteria back to design inputs. Check for criteria that are less stringent than the corresponding input requirement.

• Show me the acceptance criterion for [specific safety-critical parameter] and the design input it verifies.
• The design input says +/- 5% but the acceptance criterion says +/- 10% -- what is the documented rationale?
• Are there in-process acceptance criteria at critical manufacturing steps, or only final release criteria?

• Essential characteristics list identifying product characteristics critical for safety and proper use -- explicitly flagged in design outputs and traceable to risk analysis
• IFU content showing how essential characteristics are communicated to users -- including contraindications, warnings, precautions, operating parameters, and maintenance requirements
• Labeling specifications showing safety-critical information (warnings, symbols, use conditions) derived from essential characteristics
• Quality control procedures showing that essential characteristics receive enhanced inspection, testing, or monitoring -- acceptance criteria for essential characteristics are tighter or sampling is increased
• Evidence that essential characteristics are communicated to production and quality -- operators know which characteristics are safety-critical and why

• No explicit list of essential characteristics exists -- the design team informally knows which characteristics are safety-critical, but this is not documented or communicated to production, quality, or service personnel
• Essential characteristics are identified but are not distinguished from non-essential characteristics in the device specification -- all characteristics have the same treatment in quality control with no risk-based prioritization
• IFU does not adequately communicate essential operating parameters -- the device has a critical operating temperature range but the IFU does not include a warning about use outside this range
• Labeling omits safety-critical symbols required by applicable standards (IEC 60417, ISO 7000) for the identified essential characteristics
• Essential characteristics are defined at design output stage but are not communicated to or tracked by the post-market surveillance team -- field failures related to essential characteristics are not flagged for priority investigation

Review the essential characteristics documentation for the sampled product. Verify they are communicated in the IFU and receive enhanced quality control attention.

• Show me the essential characteristics list -- how were these characteristics identified?
• How do essential characteristics receive different treatment in quality control compared to non-essential characteristics?
• Are essential characteristics communicated in the IFU? Show me the specific warnings and precautions.

• Design review records for each planned stage showing: date, attendees with functional affiliation, agenda, materials reviewed, discussion/decision summary, action items with owners and due dates, and approval/rejection of the design stage
• Attendee records demonstrating cross-functional participation -- R&D, Quality, Regulatory, Manufacturing, Clinical, and other specialist personnel as appropriate to the stage
• Evidence of reviewer independence -- at least one reviewer who was not directly involved in performing the design work being reviewed
• Action item tracking records showing all design review actions were completed and verified before advancing to the next stage
• Design review presentation materials or packages showing what information was provided to reviewers for their assessment

• Design review was conducted by the 3-person design team only -- no representatives from Quality, Regulatory, Manufacturing, or Clinical participated, and there was no independent reviewer
• Design review minutes consist of a signature page only with no record of what was discussed, what concerns were raised, or what the basis for the decision was -- the review is not substantive
• Design review identified 7 action items, but 3 remain open and unresolved -- the project advanced to the next stage despite incomplete actions, and there is no documented justification for proceeding with open actions
• Design reviews were conducted at project milestones but not at the stages defined in the design plan -- the plan calls for reviews at concept, detailed design, and pre-verification, but reviews occurred only at the feasibility and final stages
• The design review was chaired and signed off by the project lead who also performed the design work -- there is no evidence of independent review by personnel not directly responsible for the design

Review design review records for at least 2 stage reviews from each sampled project. Check attendee independence, action item completion, and substance of the review discussion.

• Who at this design review was independent of the design work being reviewed?
• Show me the action items from this review -- are they all completed? How was completion verified?
• Were any design review actions still open when the project advanced to the next stage? What was the justification?
• How do you ensure the right cross-functional representation at each design review?

• Design review minutes showing systematic evaluation of design outputs against design input requirements -- not just a project status update
• Requirements compliance assessment presented at the design review -- showing which requirements are met, which are at risk, and which have gaps
• Traceability matrix reviewed at the design review showing current coverage status (inputs traced to outputs to V&V)
• Risk assessment update reviewed at the design review -- showing how identified risks are being addressed by the design
• Technical analysis or trade-off study results presented to support design decisions

• Design review discussed project schedule, budget, and resource issues but did not evaluate whether the design meets the input requirements -- the review was a project management meeting, not a technical design review
• No requirements compliance assessment was presented at the review -- reviewers had no information on which requirements are met, at risk, or not yet addressed
• Design review concluded with 'design is on track' but did not provide evidence or analysis to support this conclusion -- the assessment is subjective without data
• Traceability matrix was not reviewed at the design review despite showing 12 requirements with no corresponding design output -- reviewers were not informed of the coverage gaps

Review the minutes and presentation materials for 2 design reviews from each sampled project. Assess whether a requirements compliance evaluation was performed.

• At this design review, what specific requirements compliance data was presented to the reviewers?
• Were any requirements identified as at-risk or not yet addressed? What was the follow-up?
• Was the traceability matrix reviewed? What was the coverage status at this point?

• Action item log from design reviews with: unique ID, description, owner, due date, status, and evidence of closure
• Action closure records showing what was done to resolve each action item and who verified the closure
• Evidence that action items were verified as effective -- not just marked as 'done' but confirmed to have resolved the identified problem
• Escalation records for overdue or unresolved actions -- showing how open actions are managed when they exceed the due date
• Records showing the disposition of open actions at stage gate transitions -- if actions remained open, documented justification for proceeding

• Design review generated 8 action items, but the action log has no closure evidence for 3 of them -- actions were assigned but never tracked to completion
• Action items are recorded in design review minutes but are not entered into a tracking system -- there is no mechanism to monitor due dates or follow up on overdue actions
• Action closure consists of the owner self-certifying 'done' with no description of what was done and no independent verification -- the problem may not have been adequately resolved
• Project advanced from the verification stage to validation with 5 open design review actions, including one related to a safety-critical design issue -- no risk assessment or justification for proceeding with open actions was documented
• Design review minutes state 'no concerns noted' and generate zero action items for every review -- this pattern across multiple reviews suggests reviews are not sufficiently rigorous

Review the action item log for all design reviews in the sampled projects. Verify closure evidence and check for open actions at stage transitions.

• Show me the most significant action item from this project's design reviews -- what was the issue and how was it resolved?
• How many design review actions remain open? Are any related to safety or regulatory compliance?
• Has a project ever been held at a stage gate because of open design review actions?

• Design verification plan or V&V master plan showing all planned verification activities mapped to design input requirements -- with methods, acceptance criteria, and responsible personnel
• Verification test protocols with pre-defined test methods, sample sizes, acceptance criteria (traceable to design inputs), and required test equipment -- approved BEFORE testing began
• Verification test reports showing actual results compared to acceptance criteria, pass/fail conclusions, and approval signatures
• Traceability matrix showing which verification activities cover which design input requirements -- demonstrating complete coverage
• Records of verification failures including failure investigation, root cause analysis, design correction, and re-verification results
• Equipment calibration records for test equipment used during verification, valid at the time of testing

• Verification protocols were written after testing was completed -- protocol approval dates post-date the test execution dates, indicating the protocols were reverse-engineered from the results rather than pre-planned
• Verification test report shows all tests passed, but the raw test data reveals values that are near the acceptance limit -- no engineering analysis of the margin was performed, and there is no assessment of whether the design is robust or barely passing
• A verification test failed but there is no failure investigation or root cause analysis in the DHF -- the test was simply repeated with a different sample until it passed, with no documentation of why the first failure occurred
• Verification covers functional performance but does not include verification of safety-critical characteristics, labeling accuracy, or packaging integrity -- verification scope is incomplete against the design inputs
• Verification test equipment was not calibrated at the time of testing -- calibration certificates show a gap during the verification testing period, invalidating the results

Review 3-5 verification test reports from the completed project. Check protocol pre-approval, traceability to inputs, calibration status, and failure handling. Verify complete input coverage.

• Show me the protocol approval date and the test execution date for this verification test -- which came first?
• Were there any verification test failures during this project? Show me the failure investigation records.
• How do you confirm that all design inputs are covered by verification activities?
• Show me the calibration status of the test equipment used for this verification test at the time of testing.

• Design validation plan defining the validation strategy, methods, user population, use conditions (actual or simulated), sample size with statistical rationale, and acceptance criteria traceable to user needs
• Validation protocols covering functional validation, usability validation (per IEC 62366-1), clinical evaluation (if applicable), biocompatibility evaluation (per ISO 10993), software validation (per IEC 62304), and any other applicable validation activities
• Validation results and reports showing the product meets user needs and intended use -- with pass/fail conclusions, statistical analysis, and approval signatures
• Evidence that validation units were production-equivalent -- built using production processes, materials, and equipment, not hand-built prototypes
• Clinical evaluation report (CER) if clinical data is required -- demonstrating clinical safety and performance
• Timeline evidence that validation was completed before commercial release -- validation report approval dates precede the first product shipment date
• Records showing validation results were reviewed at the final design review before design transfer

• Design validation was performed on hand-built prototypes using non-production materials and processes -- the validation does not represent the actual production product
• Usability validation per IEC 62366-1 was not performed -- the organization relies on functional testing and clinical evaluation but has no summative usability test demonstrating the device can be used safely and effectively by representative users
• Validation was completed after the first product was shipped commercially -- the validation report approval date post-dates the first commercial sale by 4 months
• Clinical evaluation relies entirely on literature review with no clinical investigation data -- but the device has novel features not covered by existing clinical literature and a clinical investigation is needed per EU MDR Article 61
• Validation sample size is n=3 with no statistical rationale -- for a device with a claimed 95% success rate, n=3 provides insufficient statistical confidence to demonstrate the claim
• Software validation was limited to system-level testing and did not include validation of safety-critical software functions identified in the risk analysis -- software validation scope is inadequate for the software safety classification (Class B per IEC 62304)

Review the complete validation package for one completed project. Verify production-equivalent units, realistic use conditions, usability testing, sample size rationale, and timing relative to commercial release.

• Were the validation units built using the production process, or were they prototypes?
• Was summative usability testing performed per IEC 62366-1? Show me the results.
• What is the statistical basis for your validation sample size?
• Was validation completed before the first commercial shipment? Show me the dates.

• Design transfer procedure defining the activities required to transition design outputs into production specifications -- including a transfer checklist or work breakdown
• Design transfer checklist or record for the sampled project showing: DMR review and approval, process validation completion, equipment qualification, operator training, incoming inspection procedures, labeling and packaging finalization, DHF completeness review
• Process validation records (IQ/OQ/PQ) demonstrating manufacturing processes produce conforming product -- completed before design transfer signoff
• Manufacturing readiness assessment showing production capability verification -- equipment, tooling, fixtures, clean room, personnel training, supplier qualification
• Design transfer meeting minutes or review record with cross-functional approval (R&D, Quality, Manufacturing, Regulatory) and a formal decision to release to production
• Records of any issues identified during design transfer and their resolution before final transfer approval

• No formal design transfer procedure exists -- the transition from design to manufacturing occurred informally when the design engineer sent drawings to the production floor without a structured readiness assessment
• Design transfer was approved before process validation (IQ/OQ/PQ) was completed -- production began using unvalidated processes, and validation was completed retrospectively
• Design transfer checklist shows 5 items marked as 'not applicable' including operator training and incoming inspection procedures -- these items are applicable but were deferred, not truly N/A
• Manufacturing identified 12 producibility issues during the first production runs that should have been identified during design transfer -- DFM (Design for Manufacturability) review was not part of the transfer process
• Design transfer was a single event rather than a progressive process -- manufacturing engineering was not involved during design, and the transfer revealed fundamental manufacturability problems requiring design changes
• The DHF was not reviewed for completeness before design transfer -- the transfer record does not include a DHF completeness assessment, and the DHF is missing several required documents

Review the design transfer record and checklist for one completed project. Verify process validation completion, operator training, DMR approval, and DHF completeness review -- all before production began.

• Was process validation (IQ/OQ/PQ) completed before the first production run? Show me the dates.
• Were DFM reviews conducted during design, or were manufacturability issues discovered during transfer?
• Was the DHF reviewed for completeness as part of design transfer? Who performed the review?
• What issues were identified during design transfer, and how were they resolved?

• Design change control procedure defining the change request, impact assessment, review, verification, validation (as appropriate), approval, and implementation process
• 3 design change records (ECOs/ECNs) with complete documentation: change request, impact assessment, review records, re-verification results, re-validation results (if applicable), approval signatures, and implementation records
• Impact assessment records showing evaluation of the change on: product requirements, risk analysis, regulatory submissions, other product configurations, manufacturing processes, labeling/IFU, and already-delivered product
• Re-verification and re-validation records where applicable -- demonstrating the change does not adversely affect the product
• Records of changes that occurred after design transfer -- showing the change control process was applied to production design changes, not just during the development phase
• Regulatory impact assessment -- determining whether the change requires a new or supplemental regulatory submission (510(k), amendment, significant change notification)

• Design changes during production are processed through a manufacturing change process separate from the design change control procedure -- the change is not evaluated against design inputs, risk analysis, or regulatory impact
• A component substitution was made by purchasing when the original component went obsolete -- the substitution was implemented without engineering evaluation, impact assessment, or formal design change approval
• Impact assessment for a design change evaluates only the changed component but does not assess the impact on the system, other product configurations that share the component, or the risk management file
• A design change that affects the device's electromagnetic emissions profile was implemented without assessing the regulatory impact -- the change should have triggered a reassessment against IEC 60601-1-2 and potentially a supplemental 510(k)
• Design changes made during clinical investigation or post-market are not retroactively captured in the DHF -- the DHF reflects the original design but not the current production design after 15 post-transfer changes
• Change control records show review and approval but no re-verification or re-validation -- the organization approved the change without objectively demonstrating it does not adversely affect the product

Sample 3 design changes: one during development, one at design transfer, and one after transfer (during production). Verify complete change control documentation for each.

• Show me a design change that occurred after design transfer -- did it go through the same change control process as changes during development?
• How do you determine whether a design change requires re-verification, re-validation, or a new regulatory submission?
• How do you prevent unauthorized changes -- what controls ensure all changes go through the formal process?
• Is the DHF updated to reflect post-transfer design changes?

• Change identification system -- unique ECO/ECN numbers, sequential numbering, and database or log entries for every design change
• Complete change history for the sampled product from initial release to current revision -- showing every change in chronological order with identification, description, and approval date
• Revision history in design output documents (drawings, specifications, software versions) showing what changed at each revision with cross-reference to the authorizing change order
• Design History File entries for each design change -- demonstrating the DHF contains or references the complete change control records
• Change log or register providing a searchable index of all changes by product, date, type, and status

• Design changes are not uniquely identified -- changes are described in emails, meeting notes, or margin annotations on drawings without a formal change order number or tracking system
• Complete change history cannot be reconstructed -- changes during development were tracked in project notes that were not retained, and only post-transfer changes have formal ECO documentation
• Drawing revision history shows 'updated per design review' without referencing a specific change order or describing what changed -- the revision history is not traceable
• DHF does not contain design change records for changes made after design transfer -- post-transfer changes are in a separate manufacturing change system and are not cross-referenced in the DHF
• Change log shows ECO numbers with gaps -- ECO-2024-025, -026, -028 (no -027) -- the missing change number raises questions about a lost or deleted change record

Request the complete change history for one sampled product. Verify continuity and completeness. Check for gaps in change order numbering sequences.

• Can you produce the complete change history for this product from initial design to the current production revision?
• Are there any changes during the development phase that do not have formal change order documentation?
• Show me the drawing revision history -- does each revision reference a specific change order?
• What happened to ECO number [identify a gap in the sequence]?

• Change review records showing cross-functional evaluation of the proposed change -- with attendees, discussion summary, impact assessment results, and the review decision
• Impact assessment for each change covering: effect on product requirements (design inputs), risk analysis, regulatory submissions, other product configurations, manufacturing processes, labeling/IFU, already-delivered product, and customer notification requirements
• Evidence that review included representatives from all affected functions -- not just R&D but also Quality, Regulatory, Manufacturing, Supply Chain, and Service as applicable
• Review decision documentation -- approve, approve with conditions, or reject -- with rationale

• Design change was reviewed only by the design engineer who proposed the change and their manager -- no cross-functional review by Quality, Regulatory, or Manufacturing was performed
• Impact assessment is a checklist with all boxes marked 'no impact' -- no analysis or rationale is provided for why the change has no impact on risk, regulatory submissions, or manufacturing processes
• Change review did not assess impact on already-delivered product -- a safety-related change was implemented on new production but no evaluation was performed to determine whether a field corrective action is needed for product already in the field
• Change classified as 'minor' and given an expedited review that bypassed the full impact assessment -- but the change involved a material substitution that could affect biocompatibility

Review the impact assessments for all 3 sampled design changes. Verify cross-functional participation and substantive evaluation of all impact categories.

• Show me the impact assessment for this change -- why was there 'no impact' on the risk analysis when the change involves a new material?
• Was the impact on already-delivered product evaluated? What was the conclusion?
• Who reviewed this change? Were Quality and Regulatory involved?

• Re-verification plan or scope determination for each change -- documenting which verification tests need to be repeated and the rationale for the scope (why some tests are repeated and others are not)
• Re-verification protocols with acceptance criteria traceable to the affected design input requirements
• Re-verification test reports showing results, pass/fail conclusions, and approval
• Rationale documentation for any verification tests NOT repeated -- justification for why the change does not affect those tests
• Comparison of re-verification results to original verification results where applicable -- to detect any degradation

• No re-verification was performed for a component substitution -- the change was approved based on datasheet comparison alone without any physical testing to confirm the substitute component performs equivalently in the device
• Re-verification scope was arbitrarily limited to the specific test associated with the changed parameter -- no assessment was performed to determine whether the change could affect other parameters or tests
• Re-verification was performed but used a different protocol or acceptance criteria than the original verification -- making comparison impossible and raising questions about the validity of the re-verification
• Change approval record states 're-verification not required' for a design change involving a PCB layout modification -- no rationale is documented for why the physical layout change does not require EMC or thermal re-verification

Review the re-verification records for all 3 sampled changes. Assess the scope rationale and verify test results are acceptable.

• How did you determine which verification tests needed to be repeated for this change?
• What analysis supports the conclusion that this change does not affect [specific test not repeated]?
• Were the re-verification acceptance criteria the same as the original verification? If not, why?

• Re-validation determination records for each change -- documented assessment of whether the change affects the device's ability to meet user needs and intended use
• Re-validation plan and results (if applicable) -- using production-equivalent units under actual or simulated use conditions
• Documented rationale for changes where re-validation was not performed -- explaining why the change does not affect user needs, intended use, safety, or clinical performance
• Clinical evaluation update assessment -- determining whether the change affects the clinical evaluation and whether additional clinical data is needed

• No assessment was performed to determine whether re-validation is needed -- the change control record is silent on validation, and there is no documented decision or rationale
• Re-validation was deemed not necessary for a user interface change (button layout, alarm thresholds) without assessing whether the change could affect usability or create use errors -- a usability re-validation should have been considered
• Re-validation was determined to be needed but was deferred 'until the next validation cycle' -- the change was implemented in production before re-validation was completed
• Rationale for not performing re-validation states 'change is minor' without a technical analysis of the change's impact on user needs, intended use, safety, or clinical performance

Review the re-validation determination for all 3 sampled changes. Verify documented rationale exists and that re-validation (if needed) was completed before implementation.

• For this change, show me the documented determination of whether re-validation was needed.
• This change affects the user interface -- was a usability re-assessment or re-validation performed?
• Was the change implemented before or after re-validation was completed?

• Change approval records with approval signatures, dates, and approval authority designation
• Approval authority matrix showing different approval levels for different change significance categories (critical, major, minor)
• Evidence that approval occurred BEFORE implementation -- approval dates precede the implementation date (first use in production, first product shipment with the change)
• Implementation records confirming the change was implemented as approved -- including effective date, affected product serial numbers or lots, and communication to affected parties
• Records showing whether the change applies retroactively to in-process inventory, finished goods, or already-delivered product

• Design change was implemented on the production line before formal approval -- the production team received verbal authorization from the design engineer but the formal ECO was not approved until 2 weeks after production began with the changed design
• Approval authority for a safety-critical design change was the R&D project engineer -- the organization's procedure requires VP-level approval for safety-critical changes, but this requirement was not followed
• Change was approved but implementation records do not specify the effective lot or serial number -- it is impossible to determine which units in the field incorporate the change and which have the original design
• Approval record shows a single electronic signature with no evidence that the approver reviewed the impact assessment, re-verification results, or re-validation determination -- the approval may be uninformed
• Change was approved for one product configuration but was inadvertently implemented across all product configurations -- the implementation exceeded the scope of the approval

Verify approval timing, authority level, and implementation records for all 3 sampled changes.

• Show me the approval date and the first production date with this change -- which came first?
• What approval authority level is required for this change significance? Was the correct authority used?
• Can you identify exactly which product lots or serial numbers incorporate this change?
• How was the change communicated to the production floor? Show me the communication record.

• Design History File (DHF) for each sampled product -- organized and indexed for efficient retrieval
• DHF index or table of contents listing all documents included or referenced, with document numbers, revision levels, and locations
• DHF completeness assessment record -- evidence that the DHF was reviewed for completeness, typically at design transfer and periodically thereafter
• All required DHF contents: design plan, design inputs, design outputs, design review records, verification records, validation records, design transfer records, design change records (including post-transfer changes), risk management file reference
• Design change history within the DHF -- showing all changes from initial design through the current production revision
• Evidence that the DHF is maintained as a living document -- updated when post-transfer design changes occur, not frozen at design transfer

• No formal DHF exists -- design records are scattered across network drives, project management tools, email archives, and engineering lab notebooks with no single index or point of access
• DHF exists but is incomplete -- missing design review minutes for multiple planned reviews, missing verification test reports, and the validation report is an unsigned draft
• DHF contains only records from the design development phase and does not include the 18 post-transfer design changes -- the change records are in a separate manufacturing change control system not referenced from the DHF
• DHF index lists 42 documents but only 35 can be located -- 7 documents referenced in the index are missing or have been superseded without updating the index
• DHF was assembled retrospectively at the end of the project by collecting documents from various locations -- the DHF was not maintained as a living collection throughout the project, resulting in gaps where documents were lost or never properly filed
• DHF is maintained per product model but the organization has 12 product variants sharing a common platform -- the DHF does not clearly delineate which records apply to which variants, making it impossible to reconstruct the design history for a specific variant

Perform a completeness audit of the DHF for one completed product. Compare the index against design plan deliverables and 7.3.1-7.3.9 requirements. Verify retrieval of 5 randomly selected documents from the index. Check that post-transfer changes are included.

• Show me the DHF index -- are all documents listed in the index retrievable?
• Are post-transfer design changes included in the DHF? Show me the most recent change record.
• When was the DHF last reviewed for completeness? Who performed the review?
• For product families with multiple variants, how do you distinguish variant-specific design records from platform records?

• Purchasing SOP/procedure document with revision history -- verify it covers the full lifecycle from requisition to receipt and includes provisions for both products and services
• Approved Supplier List (ASL) showing supplier name, materials/services supplied, qualification status, last evaluation date, risk classification, and approval authority -- verify at least 3 critical suppliers have current qualification status
• Quality agreements or supplier quality manuals for top 5 critical material suppliers -- verify they define quality requirements, change notification obligations, right of access/audit, and nonconformity handling
• 3 recent purchase orders for critical components -- verify they reference applicable specifications, quality requirements, and acceptance criteria
• Supplier file for one critical supplier -- verify it contains initial qualification records, ongoing performance data, and any corrective actions
• Evidence the purchasing procedure is integrated with the document control system (controlled copy, current revision at point of use)

• No documented purchasing procedure exists; purchasing relies on informal processes where buyers select suppliers based on personal relationships or lowest price without documented quality criteria
• Purchasing procedure exists but does not address services (e.g., sterilization, calibration, testing labs) that directly affect device quality -- only covers material purchases
• Procedure has not been updated to reflect current purchasing practices; the organization migrated to an ERP system but the SOP still describes the legacy paper-based process
• Quality agreements are missing for a significant proportion of critical component suppliers; the organization relies solely on purchase order terms which do not adequately define quality requirements
• No mechanism in the procedure to escalate or block purchases from suppliers with open corrective actions or declining performance scores

Select 3 purchase orders for critical components from the last 6 months and trace each through the full purchasing chain: ASL status, quality agreement, PO content, incoming inspection records, and any nonconformities found at receipt.

• How do you handle emergency or urgent purchases when the normal approval process cannot be followed?
• What happens when a critical supplier notifies you of a process or material change?
• Can you show me how purchased services (sterilization, testing, calibration) are controlled under this procedure?

• Supplier risk classification procedure or matrix defining how suppliers are categorized (e.g., critical, major, minor) based on the effect of supplied products on final device quality and safety
• Approved Supplier List with risk classification column populated for all active suppliers -- verify at least 80% of suppliers have a documented risk level
• Critical component list or bill of materials mapping showing which purchased items directly affect device safety, performance, or sterility
• Control matrix or table showing what controls apply at each risk level (e.g., critical = annual audit + incoming inspection + quality agreement; minor = CoC review only)
• Evidence of differentiated controls in practice -- compare supplier files for one critical vs. one non-critical supplier to verify different control levels are actually applied
• Supplier audit frequency plan aligned to risk classification -- verify frequencies are defined and actually followed

• All suppliers receive identical controls regardless of risk -- critical biocompatible raw material supplier receives the same annual questionnaire as the office supply vendor
• Supplier risk classification was performed at initial qualification but has never been updated despite changes in supplied products, device risk class, or regulatory requirements
• Critical component list does not include outsourced special processes (sterilization, coating, heat treatment) which are classified as non-critical despite directly affecting device safety
• Control matrix defines audit frequency for critical suppliers as annual, but a significant proportion of critical suppliers have not been audited within the defined schedule
• Single-source critical suppliers are not identified or given enhanced controls despite representing the highest supply chain risk

Pick one critical and one non-critical supplier from the ASL. Compare the actual controls applied (audit records, incoming inspection depth, quality agreements) to what the control matrix requires for each risk level.

• When was the last time you reclassified a supplier's risk level, and what triggered it?
• How do you identify and manage single-source suppliers of critical components?
• If a critical supplier's quality agreement expires, what controls prevent continued purchasing?

• Supplier evaluation procedure defining criteria for initial qualification, evaluation methods (audit, questionnaire, sample testing, certification review), and approval authority
• Completed supplier evaluation forms for at least 3 suppliers qualified in the last 12 months -- verify criteria were applied consistently and evaluation was completed before first purchase
• Supplier audit reports for critical suppliers -- verify audits assess the supplier's QMS, manufacturing capability, and product-specific controls relevant to the supplied items
• First article inspection or sample evaluation records demonstrating the supplier's product meets specifications before production use
• Evidence of evaluation criteria being applied before first purchase -- check the date of evaluation approval vs. first PO date for 2 recently added suppliers
• Supplier evaluation scoring or rating methodology with defined pass/fail thresholds

• Supplier evaluation criteria are entirely subjective (no scoring, no minimum thresholds) -- evaluation forms contain only open-text fields with no structured assessment against defined requirements
• New critical component supplier was qualified based solely on ISO 13485 certificate review without verifying actual manufacturing capability or product quality through audit or sample testing
• First purchase order to a new supplier was placed 3 months before the supplier evaluation was completed, with product used in production during the interim
• Supplier evaluation does not include assessment of sub-tier supplier controls for suppliers who outsource critical processes (e.g., plating, sterilization, testing)
• Evaluation criteria do not address regulatory requirements specific to the supplied product (e.g., biocompatibility, sterility, electrical safety)

Select 3 suppliers added to the ASL in the last 12 months. For each, verify the evaluation was completed before the first PO, criteria were consistently applied, and the evaluation addressed product-specific quality requirements.

• Can you show me an example of a supplier that did NOT pass your evaluation criteria? What happened?
• How do you evaluate a supplier's capability to handle design or process changes that may affect your product?
• Do your evaluation criteria differentiate based on the risk classification of the purchased product?

• Supplier re-evaluation schedule showing planned frequency for each supplier (or risk category) with evidence of adherence -- verify no critical suppliers are overdue
• Supplier performance scorecards or dashboards for at least 3 critical suppliers showing metrics tracked (quality, delivery, responsiveness, corrective action effectiveness)
• Supplier re-evaluation records from the last cycle demonstrating that all criteria were assessed and a disposition decision was made (approved, conditionally approved, suspended)
• Evidence that performance data influences purchasing decisions -- meeting minutes, status change records, or PO routing showing performance-based supplier selection
• Trend analysis of supplier quality metrics over at least 12 months for critical suppliers
• Records of any supplier status changes (conditional approval, suspension, removal) triggered by performance monitoring

• Re-evaluation schedule defines annual frequency for critical suppliers, but a significant proportion of critical suppliers have not been re-evaluated within the defined timeframe with no documented justification for the delay
• Supplier scorecards track delivery performance but do not include quality metrics (incoming rejection rate, nonconformities, CAPA effectiveness) despite these being required by the procedure
• Performance data is collected but never analyzed or acted upon -- one supplier has a 15% incoming rejection rate over the past year with no corrective action initiated
• Re-evaluation consists only of reviewing the supplier's ISO certificate expiration date with no assessment of actual product quality or delivery performance
• Supplier monitoring data is not used as input to purchasing decisions -- buyers continue to place orders with suppliers that have been flagged for quality issues

Review the re-evaluation schedule for compliance. Select the supplier with the worst incoming inspection rejection rate and verify whether the monitoring system captured the trend, triggered corrective action, and influenced purchasing decisions.

• What triggers an unscheduled re-evaluation of a supplier outside the normal cycle?
• Can you show me a supplier whose status was changed (suspended, conditionally approved) based on monitoring data?
• How is supplier performance data communicated to the purchasing team to influence vendor selection?

• Supplier evaluation records including completed evaluation forms, audit reports, questionnaire responses, and performance reviews for at least 3 critical suppliers
• Action tracking log or CAPA system entries showing corrective/preventive actions resulting from supplier evaluations with target dates, responsible parties, and closure evidence
• Supplier audit reports with findings, observations, and corresponding supplier responses or corrective action plans
• Evidence of follow-up verification that supplier corrective actions were implemented and effective (not just acknowledged)
• Supplier files demonstrating complete evaluation history over at least 2 re-evaluation cycles
• Records of supplier status changes (approved, conditional, suspended, disqualified) with documented justification for each change

• Supplier audit identified major findings, but there is no record of corrective actions requested from the supplier, no follow-up, and the supplier remains approved with no conditions
• Evaluation records exist for initial qualification but no records exist for subsequent re-evaluations despite the procedure requiring annual re-evaluation
• Actions arising from supplier evaluations are tracked informally via email and are not entered into the CAPA or action tracking system, making it impossible to verify closure
• Supplier file for a critical sterilization contractor contains only the initial audit report from years ago with no subsequent evaluation records despite the procedure requiring annual assessment
• Records do not include the evaluation criteria that were used, making it impossible to determine whether the evaluation was adequate

Pull the complete supplier file for 2 critical suppliers. Verify evaluation records are complete, actions from audits are documented and closed, and the file demonstrates the full evaluation lifecycle.

• How long does it typically take to close a corrective action from a supplier audit?
• What happens if a supplier fails to respond to a corrective action request?
• Who reviews and approves the closure of supplier corrective actions?

• Supplier capability assessment records demonstrating evaluation of manufacturing processes, quality system, capacity, and technical competence relevant to the product being supplied
• First article inspection or qualification sample test reports verifying the supplier can produce product meeting all specifications
• Supplier audit reports assessing manufacturing capability, process controls, and quality system maturity for critical suppliers
• Supplier quality history data (if existing supplier) showing defect rates, on-time delivery, and corrective action responsiveness over at least 6 months
• Technical evaluation records for suppliers of critical or custom components including process capability studies (Cpk), measurement system analysis, or similar quantitative assessments

• Capability assessment for a new supplier of precision-machined implant components consists only of a self-assessment questionnaire with no on-site audit or sample evaluation to verify claimed capabilities
• Supplier was qualified based on ISO 13485 certification alone without assessing their specific capability to produce the organization's components to required tolerances and specifications
• No process capability data (Cpk/Ppk) is required or reviewed for suppliers of critical-dimension components where process variation directly impacts device safety
• Quality history shows persistent quality issues (incoming rejections averaging 8% over 12 months) but supplier remains approved with no enhanced controls or development plan

Select one recently qualified critical supplier and review the depth and rigor of the capability assessment performed. Verify it went beyond certificate review to include product-specific evaluation.

• What do you do if a qualified supplier's capability degrades over time?
• How do you assess capability for services (testing, sterilization) vs. physical components?
• Do you require process capability data from suppliers of critical-dimension components?

• Supplier scorecard or performance dashboard showing tracked metrics (incoming rejection rate, on-time delivery percentage, lot acceptance rate, corrective action response time) for critical suppliers
• Incoming inspection data aggregated by supplier showing acceptance/rejection trends over at least 12 months
• Delivery performance tracking records showing on-time vs. late delivery rates by supplier
• Evidence of performance-based actions: corrective action requests triggered by poor performance, supplier development plans, or status changes
• Supplier performance review meeting minutes where scorecard data was discussed and decisions made

• Supplier performance metrics are limited to on-time delivery only with no quality metrics tracked despite the procedure requiring quality, delivery, and responsiveness measurement
• Incoming inspection data shows one supplier had 12 lot rejections in the past year, but no performance trend analysis or corrective action was initiated
• Performance data is collected monthly but only reviewed at the annual re-evaluation -- deteriorating trends go undetected for up to 11 months
• Supplier with declining delivery performance (from 95% to 72% on-time over 6 months) is retained without corrective action or alternative source qualification

Pull incoming inspection rejection data for the last 12 months, identify the 3 suppliers with the highest rejection rates, and verify whether corrective actions were initiated and performance monitoring intensified for each.

• What threshold of incoming rejection rate triggers a corrective action request to the supplier?
• How do you handle a critical single-source supplier whose quality performance is declining?
• Can you show me a specific instance where performance data led to a change in supplier status?

• Component criticality assessment or risk analysis linking purchased items to their impact on device safety, performance, and regulatory compliance
• Bill of materials or component list with criticality classification for each purchased item (e.g., critical, major, minor based on effect on final device)
• Risk management file cross-reference showing how purchased component risks are identified and controlled in the product risk assessment (per ISO 14971)
• Control matrix mapping component criticality levels to required supplier controls (audit frequency, incoming inspection level, quality agreement requirements)
• Evidence of periodic review of criticality classifications when device design, intended use, or regulatory requirements change

• No formal criticality assessment exists for purchased components; all items are treated identically regardless of their impact on device safety and performance
• Criticality assessment addresses only direct material components but excludes packaging materials, process chemicals, and outsourced services that directly affect device quality
• Raw material supplier for a biocompatible polymer used in a Class III implant is classified as 'minor' with minimal controls because the assessment only considers manufacturing defect risk, not material specification compliance risk
• Criticality classification was performed once at initial product design and has not been updated following three design changes that introduced new critical components

Select 3 components identified as high-risk in the product risk management file and verify they are classified as critical in the purchasing system with corresponding enhanced supplier controls.

• How does your product risk analysis under ISO 14971 feed into supplier and component criticality decisions?
• When a design change introduces a new purchased component, how is its criticality assessed?
• Do you consider regulatory classification of the final device when determining component criticality?

• Procedure or policy defining how device risk classification influences supplier control requirements (e.g., Class III devices require on-site supplier audits while Class I may accept self-assessment questionnaires)
• Evidence of enhanced controls for suppliers to higher-risk devices: more frequent audits, tighter incoming inspection sampling, additional testing requirements, or more comprehensive quality agreements
• Supplier audit program showing frequency and depth aligned to device risk classification and component criticality
• Records demonstrating that changes in device risk classification (e.g., reclassification from Class II to III due to intended use change) triggered reassessment of supplier controls

• Supplier control program applies identical requirements across all product lines regardless of whether the final device is Class I, II, or III
• Organization manufactures both Class I and Class III devices using common components from the same suppliers, but the same minimal controls (annual questionnaire only) apply to all without considering the higher risk application
• Supplier audit frequency is based solely on spend volume rather than device risk classification, resulting in high-spend/low-risk suppliers being audited more frequently than low-spend/high-risk critical component suppliers
• No documented rationale exists for why current supplier control levels are considered proportionate to device risk

Compare supplier controls for one component going into the organization's highest-risk device vs. a similar component in their lowest-risk device. Verify the controls are demonstrably proportionate to the respective device risk.

• If you reclassified a device from Class II to Class III, would your supplier controls change automatically? How?
• How do you determine what constitutes 'proportionate' control for a given risk level?
• Do you consider the regulatory consequences of a supplier quality failure when setting control levels?

• 3 purchase orders for critical components -- verify each references applicable product specifications, drawing numbers with revision levels, material specifications, quality requirements, and acceptance criteria
• Purchase specification documents or engineering drawings referenced by POs -- verify they are current revisions and contain sufficient detail to define the product
• Quality requirements specified in POs or referenced quality agreements -- verify they include CoC requirements, inspection/test requirements, packaging/labeling requirements, and change notification obligations
• Evidence that PO templates or purchasing system enforces inclusion of required quality information for different purchasing categories
• Comparison of PO requirements against the product specification to verify completeness -- no critical requirements should be missing from the PO

• Purchase orders for precision-machined components reference drawing numbers without revision levels, meaning the supplier could manufacture to an obsolete drawing revision
• PO for a biocompatible raw material specifies only the material grade but does not include biocompatibility requirements, lot traceability requirements, or certificate of analysis requirements
• Purchase orders use generic descriptions ('sensors as per agreement') rather than referencing specific part numbers, specifications, and quality requirements
• PO template does not include fields for quality requirements, resulting in quality information being communicated informally or not at all
• POs for outsourced sterilization services do not specify the validated cycle parameters, bioburden limits, or sterility assurance level requirements

Select 3 POs for critical components placed in the last 3 months. For each, verify all required quality and technical information is specified or referenced, including current revision levels of all drawings and specifications.

• How do you ensure purchase orders reference current revision levels of specifications and drawings?
• What quality clauses are standard on your purchase orders, and where are they documented?
• How do you handle supplementary requirements that vary by product or device family?

• Document control system or ERP records demonstrating version control of purchase orders, including retention of all revisions with change history
• Quality agreement register showing current agreements, revision status, and review dates for all suppliers with quality agreements
• Supplier agreement/contract files with controlled copies, revision history, and evidence of mutual acceptance (signatures from both parties)
• Traceability records linking purchase orders to receiving records, incoming inspection records, and inventory lot numbers
• Records of PO changes communicated to suppliers with acknowledgement of receipt
• Record retention schedule compliant with regulatory requirements for purchasing records

• Purchase orders are modified verbally or by email without formal revision control, resulting in discrepancies between the PO on file and what the supplier actually received
• Quality agreements were signed years ago and have never been reviewed or updated despite significant changes in products supplied, quality requirements, and regulatory obligations
• Purchasing records are retained in individual buyer email accounts rather than in a controlled system, making retrieval for regulatory inspections impractical
• Cannot trace a specific received lot of raw material back to the purchase order, specification revision, and supplier that provided it

Select one critical material lot in inventory and trace backwards: receiving record, incoming inspection record, PO, and specification. Verify all links are intact and document revisions are controlled.

• How long do you retain purchasing records, and does this meet regulatory requirements for your markets?
• When was the last time your quality agreements were reviewed and updated?
• How do you handle verbal or email changes to purchase orders?

• PO review and approval procedure defining review responsibilities, criteria, and workflow for different purchasing categories
• PO approval records showing evidence of quality or engineering review before release to supplier for at least 3 recent critical component orders
• Review checklists or approval workflows in the ERP/purchasing system demonstrating that POs are reviewed for adequacy of technical and quality requirements
• Records of PO revisions or amendments where errors or omissions were caught during review before issuance to the supplier
• Evidence that quality function participates in PO review for critical purchases (approval signatures, workflow assignments)

• No formal review of purchase requirements before POs are sent to suppliers -- buyers create and release POs without quality or engineering review
• PO review process exists but is limited to price and delivery review; technical specifications and quality requirements are not assessed during the review
• Critical component PO was issued with an obsolete drawing revision because no technical review verified the referenced documents were current -- supplier manufactured to outdated specifications (Major NC)
• PO for a new custom component was issued without quality reviewing the acceptance criteria or inspection requirements, resulting in the supplier's first shipment being rejected for using wrong test methods

Review the PO approval workflow for 3 critical component orders. Verify that quality/engineering review occurred before release, referenced documents are at current revision, and the review process would catch common errors (wrong spec, missing requirements).

• How often do you issue PO amendments or revisions after the initial order? What are the most common reasons?
• Does the quality function review POs before release for critical component purchases?
• How does the review process ensure referenced specifications and drawings are at the correct revision level?

• Purchase orders or quality agreements specifying product approval requirements (e.g., first article inspection approval, PPAP requirements, sample submission before production)
• PO or specification clauses requiring supplier process approval or validation (e.g., 'supplier shall validate welding process per IQ/OQ/PQ protocol approved by [organization]')
• Equipment qualification requirements in purchasing documents for suppliers using critical manufacturing equipment
• Supplier process validation records where the organization required and reviewed the supplier's validation package before approving production
• First article or qualification sample approval records demonstrating the organization formally approved the supplier's product and process before series production

• No product approval requirement specified in POs for custom-manufactured components -- supplier ships production quantities without any first article or sample approval
• PO for outsourced injection molding does not specify requirements for mold qualification, process validation, or tool approval despite the molding process being classified as a special process
• Quality agreement requires first article approval, but several sampled purchase orders do not reference this requirement and product was shipped to production without first article sign-off
• Equipment requirements not specified for a supplier performing laser welding of a critical implant subassembly -- supplier changed laser equipment without notification
• No mechanism to require supplier re-approval when the supplier changes processes, equipment, or manufacturing location

Select 2 suppliers performing special processes and review their POs/agreements for completeness of product, process, and equipment approval requirements. Verify first article or process approval was completed before production began.

• For your outsourced sterilization, what specific approval requirements are in the purchase order or service agreement?
• How do you approve a supplier's process changes before they affect your product?
• What is your PPAP or first article inspection process for new supplier qualifications?

• Purchase orders or quality agreements specifying personnel qualification requirements for critical activities (e.g., 'welding operators shall be qualified per AWS D17.1', 'test technicians shall be certified to IPC-A-610 Level 3')
• Supplier audit records where personnel qualifications were verified during on-site assessment
• Personnel qualification requirements for outsourced inspection and testing services (e.g., NDT inspector certifications, calibration technician qualifications)
• Training and certification requirements specified in purchasing documents for suppliers of services affecting product quality
• Records of supplier personnel qualification verification (copies of certifications, training records, or audit notes confirming qualifications)

• No personnel qualification requirements specified in POs or quality agreements for a supplier performing critical welding operations on implant components
• Quality agreement requires 'qualified personnel' without defining the qualification standard, training requirements, or certification needed
• Outsourced NDT (non-destructive testing) supplier PO does not specify the required NDT operator certification level despite the inspection being a critical acceptance test
• No verification that outsourced calibration lab technicians hold appropriate qualifications, despite the lab not being accredited to ISO/IEC 17025

Review POs or quality agreements for 2 suppliers performing special processes or critical inspections. Verify that personnel qualification requirements are specified and that evidence of supplier compliance exists (audit records, certificates on file).

• For your outsourced testing laboratory, what inspector qualification requirements do you specify?
• How do you verify that supplier personnel qualifications remain current over time?
• Have you ever rejected a supplier's work because their personnel were not adequately qualified?

• Purchase specifications or quality agreements detailing specific qualification requirements for personnel performing critical manufacturing, inspection, or testing operations at the supplier
• Records demonstrating that personnel qualification requirements were communicated to the supplier and acknowledged (signed quality agreements, PO acknowledgements)
• Evidence that supplier personnel qualifications are verified periodically, either through audits, certification reviews, or records requests
• Examples of qualification requirements for different activity types (e.g., manufacturing operator requirements vs. quality inspector requirements vs. test technician requirements)
• Supplier responses or evidence demonstrating compliance with specified personnel qualification requirements

• Purchase documents contain no requirements for personnel performing critical inspection activities at a contract testing laboratory, relying entirely on the assumption that an ISO 17025-accredited lab automatically has qualified personnel
• Personnel qualification requirements are specified in the quality agreement but not referenced or reinforced in individual purchase orders, creating ambiguity about applicability
• No distinction in qualification requirements between operators performing manual assembly of Class I vs. Class III device components at the same contract manufacturer
• Supplier audit found that personnel performing visual inspection of critical components had no documented training or qualification records, despite the quality agreement requiring qualified inspectors

Select one outsourced inspection/testing supplier and one contract manufacturer. Verify that purchase documents specify personnel qualification requirements and that evidence exists of supplier compliance.

• How do you ensure supplier personnel maintain their qualifications over time, especially for special process certifications that expire?
• What action do you take if you discover during a supplier audit that personnel performing critical operations are not qualified per your requirements?
• Do you require the supplier to notify you if qualified personnel leave and are replaced?

• Purchase orders or quality agreements specifying QMS requirements (e.g., ISO 13485 certification, specific QMS elements, or compliance with the organization's supplier quality manual)
• Current ISO 13485 or ISO 9001 certificates for critical suppliers -- verify scope covers the products/processes supplied to the organization and certificates are not expired
• Quality agreement clauses defining specific QMS requirements including document control, record retention, change notification, CAPA, and traceability requirements
• Audit provisions in quality agreements granting the organization and regulatory authorities right of access to the supplier's facilities and records

• QMS requirements not specified in purchase documents for a critical component supplier -- no certification requirement, no quality agreement, and no audit provisions
• Supplier's ISO 13485 certificate has expired but purchasing continues without any evaluation of the supplier's current QMS status
• ISO 13485 certificate is required but the scope of certification does not cover the specific process or product supplied to the organization (e.g., certificate covers design but not manufacturing)
• Quality agreement does not include change notification requirements, allowing the supplier to make process changes without the organization's knowledge or approval

Review quality agreements and certificates for 3 critical suppliers. Verify QMS requirements are specified, certifications are current and scope-appropriate, and agreements include adequate quality provisions (change notification, audit rights, CAPA).

• What QMS requirements do you apply to suppliers who are not ISO 13485 certified?
• How do you verify that your supplier's ISO certification scope covers the products and processes they provide to you?
• Do your quality agreements require suppliers to notify you of changes to their QMS certification status?

• Incoming inspection procedure defining inspection methods, sampling plans (with statistical rationale), acceptance criteria, and escalation procedures for nonconforming material
• Incoming inspection records for at least 3 recent receipts of a critical component -- verify records include date, lot number, quantity, inspector, test results, acceptance decision, and approval signature
• Sampling plan documentation (e.g., ANSI/ASQ Z1.4 or equivalent) with rationale for sampling level selection based on supplier history and product risk
• Inspection work instructions or checklists for critical incoming materials detailing the specific tests, measurements, and acceptance criteria to be applied
• Records of incoming material rejections showing nonconformity disposition, supplier notification, and CAPA initiation when required
• Evidence of reduced or tightened inspection based on supplier performance history as defined in the sampling plan

• No incoming inspection is performed for materials from 'approved' suppliers -- material is released to production based solely on the supplier's certificate of conformity without any verification
• Sampling plan for critical component incoming inspection uses fixed sample sizes with no statistical rationale and no provision for switching between normal, tightened, and reduced inspection based on lot history
• Incoming inspection records for a critical raw material show only 'PASS' with no measurement data, making it impossible to determine what was actually inspected or whether the acceptance criteria were met
• Incoming inspection procedure does not define how to handle material that arrives without a required certificate of conformity or certificate of analysis
• Critical dimensions specified on the drawing are not included in the incoming inspection checklist, and inspection is limited to visual inspection and quantity verification only

Review incoming inspection records for 3 recent lots of a critical component. Verify that actual measurements (not just pass/fail) are recorded, sampling plans were followed, and acceptance criteria match the product specification.

• What do you do if a certificate of conformity is missing or incomplete when material arrives?
• How does your sampling plan adjust based on supplier quality history?
• Can you show me a recent incoming material rejection and how it was handled?

• Incoming inspection and test records for at least 5 recent receipts of critical materials -- verify each record includes: date, material identification, lot/batch number, quantity received, inspector name, tests performed, actual results vs. acceptance criteria, and disposition (accept/reject)
• Certificates of conformity or certificates of analysis received from suppliers with verification that they match the lot received and that values meet specifications
• Records of nonconforming incoming material including quarantine, investigation, disposition (return, scrap, use-as-is with engineering justification), and supplier notification
• Calibration status of measurement equipment used during incoming inspection (cross-reference equipment ID on inspection record to calibration database)
• Evidence that incoming inspection records are retained for the period required by regulatory requirements and the organization's record retention procedure

• Incoming inspection records consist only of a receiving stamp showing the date and receiver's initials with no indication of what inspections were performed or their results
• Certificates of analysis from the supplier are on file but were never compared against the organization's incoming inspection specifications to verify that all required parameters meet the organization's requirements
• Incoming inspection records for several sampled lots are missing entirely -- material was released to production and the inspection records cannot be located
• Records do not identify which specific measurement instruments were used during incoming inspection, making it impossible to assess the impact if equipment is later found out of calibration
• Nonconforming material was dispositioned as 'use as is' with no documented engineering justification or risk assessment, and no concession record exists

Pull incoming inspection records for 5 recent critical material lots. Verify completeness of records, actual measurement data recorded (not just pass/fail), traceability to inspection equipment, and proper disposition of any nonconformances.

• How do you link incoming inspection records to the specific PO and specification revision?
• What is your record retention period for incoming inspection records, and does it meet regulatory requirements?
• How do you handle material that needs to be released urgently before incoming inspection is complete?

• Purchase orders or quality agreements specifying source inspection requirements including inspection methods, witness points, hold points, and release criteria
• Source inspection reports or records from supplier site visits showing what was verified, test results, and disposition decisions
• Defined witness and hold points in supplier manufacturing process for critical items (e.g., 'organization must witness sterilization cycle validation runs')
• Release method specification in purchasing documents (e.g., 'product shall not be shipped until source inspection is complete and product is released in writing by organization's quality representative')
• Source inspection procedures defining who can perform source inspections, their qualifications, and the scope of verification activities

• Source inspection is performed informally at the supplier during periodic visits, but no requirements for source inspection are specified in the PO or quality agreement, and no formal source inspection reports are generated
• PO requires source inspection but does not define what is to be inspected, the inspection methods, or the acceptance criteria -- leaving the scope to the inspector's judgment
• Quality agreement specifies the organization's right to perform source inspection, but in practice source inspections have not been performed for multiple years despite the supplier producing critical implant components
• Release method not specified -- supplier ships product after internal release without waiting for the organization's source inspection approval

If source inspection is performed, review 2 source inspection reports for completeness. If not performed, verify that the rationale for not requiring source inspection is documented and justified for critical outsourced processes.

• For which suppliers or products do you perform source inspection, and why?
• How do you ensure product is not shipped before source inspection is complete?
• When was the last source inspection performed, and what did it cover?

• Production control plan or manufacturing plan for a specific product line showing all process steps, control points, inspection stages, and acceptance criteria
• Production batch record (device history record) for a recently completed batch -- verify it documents all process parameters, in-process checks, material usage, personnel, and equipment used
• Work instructions or SOPs at each critical production workstation -- verify they are current revision, legible, and accessible to operators
• Environmental monitoring records for controlled areas (temperature, humidity, particulate counts) showing compliance with defined limits
• Equipment maintenance and calibration records for production equipment used in the most recent batch
• Production personnel training records demonstrating competence for assigned tasks

• Production batch record does not capture all required process parameters -- injection molding batch record shows only cycle time and temperature but omits pressure, hold time, and cooling time which are validated parameters
• Work instruction at an assembly workstation is a superseded revision while the current controlled revision is newer; operator has been following outdated procedures (Major NC)
• Environmental monitoring for the clean assembly area shows temperature excursions on 3 occasions in the last month with no documented investigation or impact assessment
• Preventive maintenance for a critical sealing machine is overdue by 6 weeks with no documented risk assessment or justification for delay
• No evidence that production operators were trained on updated work instructions following a recent process change

Walk the production floor for one product line. At 3 different workstations, compare the actual practice against the work instruction, verify operator training records, and check the batch record for completeness of process parameter documentation.

• What happens if an environmental excursion occurs during production? Show me a recent example.
• How do you handle production interruptions or shift handovers to ensure continuity of controlled conditions?
• What is the process for releasing product from one production stage to the next?

• Production control documentation integrating requirements for infrastructure (equipment, facilities, utilities), work environment (cleanroom classification, temperature/humidity limits), and personnel competence (training requirements per role)
• Infrastructure qualification records for production facilities (cleanroom certification, utility qualification, HVAC validation)
• Work environment specifications and monitoring records demonstrating compliance (temperature, humidity, particulate counts, differential pressure)
• Competence requirements matrix for each production role showing required training, skills, and qualification criteria
• Validation master plan or register identifying all production processes requiring validation and their current validation status

• Production control documentation addresses process steps and acceptance criteria but does not specify environmental requirements, leaving cleanroom conditions undocumented despite production occurring in a controlled environment
• Competence requirements for production operators are defined generically ('trained on job duties') without specifying the specific skills, knowledge, and qualifications needed for each distinct production role
• Infrastructure qualification records for the production facility are from the original construction with no evidence of periodic requalification despite facility modifications
• Validation master plan has not been updated in 3 years and does not include 2 new production processes introduced in the last 18 months

For one product line, verify that documented production requirements address all five elements: infrastructure, work environment, personnel competence, validation, and monitoring. Check each against actual records to confirm implementation.

• How are changes to production infrastructure (new equipment, facility modifications) controlled and qualified?
• What happens if environmental monitoring shows conditions outside specified limits during production?
• How do you ensure validation status is current for all production processes?

• Product specifications, engineering drawings, and bills of materials available at production workstations -- verify they are current controlled revisions
• Visual aids, reference samples, or limit samples used to communicate product characteristics at workstations where visual inspection is performed
• Digital work instruction system or shop-floor display showing real-time product specifications for the item currently in production
• Evidence that product characteristic information is updated at the point of use when engineering changes are released
• Master device record or device master file contents accessible to production and quality personnel

• Engineering drawings at the CNC machining workstation are uncontrolled photocopies with handwritten markups that do not match the current revision in the document control system
• Product specifications are available only in the quality department filing system and are not accessible to production operators on the shop floor
• Visual reference samples for cosmetic acceptance criteria have degraded over time and no longer accurately represent the acceptable quality level
• Bill of materials at the assembly station lists a component part number that was superseded -- the operator is using the correct new part from memory but the documentation has not been updated
• Product specifications are available in English only, but several production operators read only Spanish and no translated versions or visual aids are available

At 3 production workstations, verify that current-revision product specifications are accessible to operators. For each, compare the revision of the specification at the workstation to the revision in the document control system.

• When an engineering change is released, how quickly are the new specifications available at the production workstation?
• How do you ensure that only current revision drawings are used in production?
• For operators who perform visual inspections, how are acceptance criteria communicated and standardized?

• Work instructions or standard operating procedures for critical production operations -- verify they are detailed enough for a trained operator to perform the task consistently
• Risk assessment or determination criteria used to identify which operations require documented work instructions vs. those covered by training alone
• Training records for operators showing they have been trained on and demonstrated competence with the applicable work instructions
• Production floor observation of an operator performing a task governed by a work instruction -- verify the steps are being followed
• Work instruction review and revision records showing periodic review for adequacy and updates following process changes

• Critical soldering operation for an active implantable device has no documented work instruction; operators rely on verbal training from senior operators, resulting in inconsistent technique between operators
• Work instruction for a sterile packaging operation is so generic ('seal product in pouch per procedure') that it provides no actual guidance on sealing parameters, seal inspection criteria, or packaging sequence
• Work instructions exist but operators are not following them -- observation shows the operator performing assembly steps in a different order than documented, skipping a verification step
• Work instruction was last reviewed years ago and references equipment and materials that have been replaced since the review
• No work instructions exist for final inspection operations; inspectors use personal notes and memory for acceptance criteria and test methods

Select 2 critical work instructions and observe the corresponding operations being performed on the floor. Note any deviations between the documented procedure and actual practice.

• How do operators request a change to a work instruction if they identify a better method?
• What is your process for updating work instructions when a process change is implemented?
• How do you verify that new or temporary operators can perform critical tasks using only the work instructions and their training?

• Equipment qualification records (IQ/OQ) for critical production equipment demonstrating it was verified as suitable before use in production
• Preventive maintenance schedule and completed maintenance records for at least 3 critical pieces of production equipment -- verify maintenance is performed on schedule
• Equipment capability studies (process capability, machine capability, or Gage R&R) demonstrating the equipment can consistently produce within specifications
• Equipment logbooks or usage records showing operating history, breakdowns, and corrective maintenance
• Equipment change control records showing that modifications to production equipment are formally evaluated and approved
• Spare parts inventory and replacement schedule for critical wear items

• Ultrasonic welding equipment used for producing Class III implant assemblies was purchased and placed into production with no installation qualification (IQ) or operational qualification (OQ) -- only process validation (PQ) was performed
• Preventive maintenance for the injection molding machine is overdue by 3 months; the maintenance schedule shows 4 missed PMs in the last year with no documented impact assessment
• Equipment capability study for a CNC lathe was performed during initial qualification and has not been repeated despite the equipment being rebuilt and calibrated multiple times since then
• No equipment logbook exists for the sterilizer; equipment downtime events and corrective maintenance are not recorded, making it impossible to assess equipment reliability
• Production equipment was modified by maintenance (new controller installed) without going through the change control process and without assessing the impact on process validation status

Select 2 critical production machines on the floor. For each, verify IQ/OQ records exist, preventive maintenance is current, and recent capability data confirms suitability.

• What happens to product if a critical piece of equipment breaks down during a production run?
• How do you determine when equipment needs to be requalified vs. just recalibrated?
• Do you track equipment downtime, and if so, what is the downtime trend for your most critical equipment?

• Inspection and test plans identifying the monitoring and measuring equipment required at each production stage, including equipment specifications (range, resolution, accuracy)
• Calibrated measuring equipment at production workstations with current calibration labels -- verify equipment is appropriate for the measurement being performed
• Gauge R&R or measurement system analysis studies for measuring equipment used to accept/reject product on critical dimensions
• In-process inspection records showing the measurement equipment used (equipment ID traceable to calibration records)
• Equipment inventory or master list of all monitoring and measuring equipment used in production, with calibration status

• In-process dimensional inspection of a critical feature with a tolerance of ±0.01mm is performed using a caliper with resolution of 0.02mm -- the equipment cannot reliably discriminate conforming from nonconforming product
• Measurement equipment at the inspection station has an expired calibration sticker and continues to be used for production acceptance decisions
• No Gauge R&R study exists for the go/no-go gauges used to accept implant components on critical fit dimensions, despite acceptance decisions being made solely based on these gauges
• Production batch record does not identify which specific measurement instrument was used for in-process checks, preventing traceability if equipment is later found out of calibration
• Temperature monitoring equipment in a controlled storage area has not been verified against a traceable standard and shows 3°C drift from the reference thermometer

At 3 in-process inspection points, verify the measuring equipment is calibrated, appropriate for the measurement (resolution vs. tolerance), and identified in the inspection record.

• How do you determine the appropriate measurement equipment for a given inspection task?
• What happens to product that was measured with equipment later found to be out of calibration?
• Do you perform measurement uncertainty analysis for critical measurements?

• In-process inspection records from a current or recent production batch showing measurements taken, results recorded, and pass/fail decisions documented at each control point
• Final inspection and test records for a completed batch with all required tests performed, results within acceptance criteria, and formal release approval
• Process monitoring data (control charts, SPC data, trend charts) for critical process parameters demonstrating ongoing monitoring
• Evidence that inspection frequency and sampling plans are followed as defined in the inspection and test plan
• Nonconformity records from in-process or final inspection showing detection, segregation, and disposition of nonconforming product

• In-process inspection plan requires 100% inspection of a critical weld, but batch records show the inspection was performed on only a small sample without documented justification for the reduced inspection level
• SPC control chart for a critical process parameter shows an out-of-control condition (7 consecutive points above the mean) but no investigation was triggered and production continued
• Final inspection records show only pass/fail results with no actual measurement data; when asked to reproduce a measurement, the inspector obtained a different result from what was recorded
• Process monitoring for sterilizer temperature shows data recorded at 30-minute intervals as required, but data for a 2-hour period during a production batch is missing with no explanation
• In-process inspection data is recorded on loose sheets of paper that are not traceable to specific batch records

Review complete in-process and final inspection records for 2 recent batches. Check that all required inspections were performed, actual measurement data is recorded, and any out-of-specification results triggered appropriate action.

• What training do your inspectors receive, and how is their competence verified?
• How do you investigate when SPC data shows an out-of-control trend?
• What is the process for handling nonconforming product discovered during in-process inspection?

• Product release procedure defining release authority, required verifications (all inspections complete, batch record reviewed, any deviations closed), and documentation requirements
• Batch release records for at least 2 recently shipped batches showing formal release approval by authorized personnel with evidence that all prerequisite checks were completed
• Shipping and delivery procedures including packaging verification, shipping condition requirements, and delivery confirmation processes
• Post-delivery activity procedures covering installation (if applicable), customer feedback monitoring, and field service/support requirements
• Evidence that released product cannot be shipped until all release criteria are met (system controls, physical segregation, or hold/release workflow)

• Product batch was shipped to the customer before the final inspection report was completed -- investigation revealed the warehouse released the product based on a verbal approval that was never formally documented
• Release authority is defined as the Quality Manager, but batch records show release signatures from 3 different people, including a production supervisor who is not an authorized releaser
• Post-delivery complaint was received indicating product was damaged during shipping, but the investigation found no defined shipping condition requirements (temperature, vibration, orientation) for the product
• No mechanism exists to prevent shipment of product that has open deviations or pending investigations -- warehouse releases product when the production order is marked 'complete' regardless of quality holds

For 2 recently shipped batches, verify the release date precedes the ship date, all required inspections/tests were completed before release, and the release was authorized by personnel with defined release authority.

• What physical or system controls prevent shipment of product that has not been formally released?
• If a deviation is discovered after batch release but before shipment, what is the process?
• How do you handle post-delivery activities such as installation and field servicing?

• Labeling procedure defining label issuance, verification (including line clearance), application, and reconciliation processes
• Label verification records from a recent batch showing label content verification against the approved master label, correct UDI/lot/expiry information, and reconciliation of used, damaged, and returned labels
• Packaging procedure defining packaging materials, methods, sealing parameters, and inspection criteria
• Packaging validation records (seal strength, distribution simulation, sterile barrier integrity) demonstrating packaging processes are validated
• Label control records showing issuance, quantities, and reconciliation for at least 2 recent batches
• Line clearance records showing verification that previous product labels and materials are removed before the next product run

• Line clearance procedure requires verification that all labels from the previous product are removed before starting a new batch, but line clearance records show this step was not performed for several recent changeovers
• Label reconciliation shows 15 labels were issued but only 12 are accounted for (10 applied + 2 damaged); the 3 unaccounted labels were not investigated and could represent a mix-up risk
• Packaging seal strength for a sterile barrier system has not been validated -- sealing parameters were set based on the machine operator's experience rather than a formal validation (IQ/OQ/PQ)
• UDI labels are printed by production operators from an uncontrolled template; no verification step exists to confirm the printed UDI matches the approved device identification database
• Label storage area has no access control; any employee can access label stock, creating a risk of unauthorized label issuance or use of obsolete labels

Observe one labeling/packaging operation. Review label reconciliation records for 3 recent batches. Verify line clearance was performed, labels were verified against the approved master, and any discrepancies in reconciliation were investigated.

• How do you control and reconcile labels for products with multiple label variants (different languages, markets, configurations)?
• What happens if a label discrepancy is found during reconciliation?
• How often do you perform packaging seal integrity testing, and what are the acceptance criteria?

• Product cleanliness specifications defining acceptable limits for particulate contamination, chemical residues, bioburden, and endotoxin levels as applicable to the product type and intended use
• Cleaning procedures (SOPs) for each cleaning step in the manufacturing process, including cleaning agents, parameters, equipment, and operator requirements
• Cleaning validation protocol and report demonstrating the cleaning process consistently achieves the specified cleanliness levels
• Routine cleanliness testing records (particulate counts, bioburden testing, TOC analysis, endotoxin testing) for at least 3 recent production batches
• Environmental controls and cleanroom procedures that support product cleanliness during manufacturing, assembly, and packaging

• No documented cleanliness specifications exist for products that are cleaned prior to sterilization -- cleaning is performed 'as needed' based on operator judgment without defined acceptance criteria
• Cleaning validation was performed on the original cleaning equipment; the cleaning line has since been replaced and no revalidation was performed
• Bioburden limits for pre-sterilization product are not defined despite the sterilization validation being based on a maximum bioburden assumption that must be verified
• Routine bioburden testing frequency was reduced from weekly to monthly without documented risk assessment or justification
• Cleaning procedure specifies 'clean with IPA' but does not define concentration, contact time, volume, wiping method, or number of wipe cycles, making consistent cleaning unlikely

Review the cleaning validation report and 3 recent routine cleanliness test results. Verify that the cleanliness specifications are defined, the cleaning process is validated, and routine testing confirms ongoing compliance.

• How did you establish your cleanliness specifications? What standards or risk assessments were used?
• How do you link your pre-sterilization bioburden limits to your sterilization validation assumptions?
• What is your cleaning agent qualification process, and how do you evaluate cleaning agent changes?

• Cleanliness requirements for products cleaned in-house, including particulate limits, bioburden limits, endotoxin limits, and chemical residue limits with rationale for each limit
• Cleaning process validation protocol, execution records, and final report demonstrating the process consistently achieves required cleanliness
• Cleaning procedure defining parameters (temperature, time, chemistry, agitation, rinse cycles) based on the validated process
• Routine cleanliness monitoring records showing ongoing compliance with validated limits

• Cleaning process for orthopedic implants prior to passivation and sterilization has no formal validation -- cleaning parameters were established based on supplier recommendation without verification of cleaning effectiveness
• Validated cleaning process specifies 3 ultrasonic cleaning cycles, but production records show only 2 cycles were performed due to time constraints, and no deviation was raised
• Endotoxin limits are not included in cleanliness specifications for products that will contact cerebrospinal fluid despite the clinical risk of pyrogen reactions

Review the cleaning validation report and compare validated parameters against 2 recent production batch records to verify parameters were maintained during routine production.

• How do you verify that your cleaning process continues to meet the validated parameters in routine production?
• What triggers revalidation of your cleaning process?
• How are cleaning agent lot changes or supplier changes managed?

• Instructions for use (IFU) specifying cleaning and reprocessing instructions for devices supplied non-sterile
• Pre-cleaning specifications ensuring the product is in a suitable state for customer cleaning/sterilization
• Validation data supporting the customer cleaning/sterilization instructions provided in the IFU
• Compatibility testing data demonstrating the product is compatible with recommended cleaning agents and sterilization methods

• Reusable surgical instrument is supplied non-sterile with instructions to 'clean and sterilize before use' but no specific cleaning method, parameters, or sterilization cycle recommendations are provided
• IFU provides cleaning instructions that were not validated -- recommended cleaning agents were selected based on general literature rather than product-specific validation studies
• Material compatibility with the recommended sterilization method (e.g., autoclaving) was not tested, and field complaints indicate product degradation after repeated reprocessing

For one reusable device supplied non-sterile, verify that IFU cleaning/sterilization instructions are backed by validation data and that material compatibility with the recommended reprocessing methods has been tested.

• How many reprocessing cycles is this device validated for, and where is this communicated to the user?
• Have you validated the cleaning and sterilization instructions you provide in your IFU?
• How do you monitor field feedback related to reprocessing issues?

• Manufacturing cleanliness controls including cleanroom classifications, gowning procedures, material transfer protocols, and in-process handling requirements
• In-process cleanliness testing records for products manufactured under controlled cleanliness conditions
• Cleanroom environmental monitoring records (particulate counts, microbial monitoring) for areas where products that cannot be subsequently cleaned are manufactured
• Material and component cleanliness requirements for incoming materials used in products where post-manufacturing cleaning is not possible

• Product is manufactured in a controlled environment but no in-process cleanliness testing is performed to verify that manufacturing controls are effective at maintaining product cleanliness
• Cleanroom gowning procedures are not followed consistently -- observation shows operators entering the controlled area without proper gowning
• Material transfer procedures from uncontrolled to controlled areas do not include decontamination or cleaning of incoming materials

Observe the clean manufacturing area, verify gowning and material transfer compliance, and review 3 months of environmental monitoring data for any excursions and their resolution.

• How do you validate that your controlled environment conditions are sufficient to meet product cleanliness requirements?
• What action is taken when environmental monitoring shows excursions in the clean manufacturing area?
• How do you control raw material cleanliness for materials entering the clean manufacturing area?

• Cleanliness specifications for non-sterile products where cleanliness is clinically significant (e.g., wound care products, diagnostic devices, blood-contacting non-sterile accessories)
• Manufacturing controls designed to maintain cleanliness including controlled environment requirements, handling procedures, and packaging controls
• Final cleanliness testing records demonstrating product meets cleanliness specifications at release
• Risk assessment documenting why cleanliness is significant for the device's intended use and how cleanliness levels were determined

• Non-sterile wound care product has no documented cleanliness specifications despite direct skin contact being the intended use
• Manufacturing controls for a non-sterile diagnostic device with cleanliness requirements consist only of operator wearing gloves -- no environmental controls, no cleanliness testing, and no formal specifications
• No risk assessment documents the cleanliness significance determination for any non-sterile products in the portfolio

Identify non-sterile products where cleanliness is significant. For one such product, verify cleanliness specifications exist, manufacturing controls are defined, and release testing confirms compliance.

• How did you determine which non-sterile products require cleanliness controls?
• What cleanliness testing do you perform on non-sterile products at final release?
• How do you establish cleanliness limits for non-sterile products when no specific standard applies?

• List of process agents used during manufacturing that contact the product (lubricants, cutting fluids, mold release agents, flux, cleaning solvents, adhesive primers)
• Residue specifications defining maximum allowable residue levels for each process agent, with rationale for limits (typically based on biocompatibility or functional impact)
• Validated removal process for each process agent, including cleaning method, parameters, and demonstrated effectiveness
• Routine residue testing records demonstrating process agent levels are within specified limits after the removal process

• Machining lubricant is used during CNC manufacturing of implant components but no residue limits are defined and no residue testing is performed after cleaning -- the assumption is that the cleaning process removes it, but this has never been validated
• Mold release agent is used in injection molding of a patient-contacting component but is not listed in the process agent inventory and was not considered during biocompatibility evaluation
• Flux residue limits for PCB assembly are defined but no residue testing is performed on production units -- testing was only done during the initial cleaning validation years ago
• Process agent was changed from one supplier to another without evaluating the impact on residue characteristics or cleaning process effectiveness

Request the process agent inventory and select 2 agents used on patient-contacting products. Verify residue limits are defined, the removal process is validated, and routine testing records demonstrate compliance.

• How do you manage changes to process agents (new suppliers, formulation changes)?
• Are process agent residues included in your biocompatibility evaluation?
• What is the validated shelf life of your cleaning agents, and how is expiry controlled?

• Installation procedure defining installation steps, required tools and equipment, safety requirements, and acceptance criteria for verifying correct installation
• Installation checklists or records for at least 2 recent installations showing all steps completed, acceptance criteria met, and sign-off by qualified personnel
• Installation qualification (IQ) protocol and records for installed equipment-type devices
• Training records for installation personnel (internal or third-party installers) demonstrating competence
• Post-installation testing or verification records confirming the installed device meets performance specifications

• Installation procedure exists but lacks specific acceptance criteria -- the only verification is 'device powers on' without checking calibration, functional performance, or safety features
• Third-party installation technicians are used for international markets but their training and qualification records are not maintained by the organization
• Installation records for several sampled installations are incomplete -- several checklist items are unsigned and the final acceptance test results are not documented
• Installation acceptance criteria were not updated when a new software version was deployed, causing installers to use obsolete commissioning procedures

Review installation records for 2 recent installations (ideally one internal and one by a third party). Verify all checklist items are completed, acceptance criteria are defined and met, and installation personnel are qualified.

• How do you ensure third-party installers follow your installation procedures?
• What happens if the post-installation acceptance test reveals the device does not meet specifications?
• How do you handle installation in different markets where infrastructure or electrical standards differ?

• Service procedures or service manuals defining service activities, including preventive maintenance schedules, repair procedures, calibration requirements, and acceptance criteria
• Service work order records for at least 3 recent service events showing activities performed, parts replaced, measurements taken, and verification that the device meets performance specifications after service
• Service personnel training and qualification records demonstrating competence for the specific devices and service activities
• Service parts inventory and traceability records showing that replacement parts are controlled and traceable
• Service measurement equipment calibration records

• Service procedures specify preventive maintenance intervals but do not include acceptance criteria for verifying device performance after maintenance -- service technicians perform the work but do not confirm the device meets specifications before returning it to service
• Third-party service organizations are authorized to service devices but the manufacturer has not provided them with current service manuals, required test equipment, or training on the latest device version
• Service records show a critical safety component was replaced but the replacement part is not traceable to an approved supplier or lot number
• Service measurement equipment is not included in the organization's calibration program, and several instruments used for post-service verification have no calibration records

Review 3 recent service work orders for completeness. Verify post-service functional testing was performed, parts are traceable, and service personnel were qualified for the specific activity.

• How do you control replacement parts used during servicing to ensure they meet product specifications?
• What post-service verification is performed to confirm the device meets safety and performance requirements?
• How do you manage service documentation when device design changes occur?

• Procedure defining how service activity feedback and findings are evaluated against complaint criteria to determine if formal complaint handling is required
• Service report evaluation records showing evidence that each service event was assessed for potential complaint classification
• Examples of service events that were escalated to the complaint handling process with documented rationale for the escalation
• Training records for service personnel on complaint identification criteria

• Service reports documenting repeat device failures are not evaluated against complaint criteria -- the same failure mode has been serviced 8 times across different units without triggering a complaint or investigation
• No documented criteria exist for service personnel to determine when a service finding constitutes a complaint vs. routine maintenance
• Service organization is separate from the quality organization and there is no formal process for service information to be reviewed by quality for potential complaint handling
• Customer-reported safety concerns documented in service reports were not escalated to the complaint handling system because they were classified as 'service requests' rather than complaints

Review 5 recent service reports and evaluate whether any contained findings that should have been escalated to the complaint handling process. Verify the evaluation criteria were applied in each case.

• In the last 12 months, how many service events were escalated to the complaint system?
• If the answer is zero, how do you explain that no service findings warranted complaint handling?
• How do service technicians in the field report potential complaints?

• Service data analysis reports showing trending of service events by failure mode, device type, and frequency
• Examples of CAPAs or improvement actions initiated based on service data analysis
• Design change records where service field data was used as input to design improvements
• Preventive maintenance schedule adjustments based on service frequency and failure mode data
• Management review records showing service data analysis as an agenda item and input

• Service data is collected but never analyzed for trends -- individual service events are closed as completed without aggregation or trending across the fleet
• The same failure mode appears in 15 service reports over 6 months but no CAPA was initiated because each event was treated in isolation
• Service data is not included as an input to management review, missing the opportunity to identify systematic improvement opportunities
• No feedback loop exists between field service findings and the design team, despite service data indicating a recurring design-related failure mode

Review the last 12 months of service data trending. Identify the top 3 failure modes and verify whether each has been evaluated for CAPA or improvement action.

• What is the most common service failure mode, and what action has been taken to address it?
• How often is service data analyzed for trends?
• Can you show me a specific improvement that was made based on service data?

• Sterilization validation protocol and report demonstrating the sterilization process achieves the required sterility assurance level (SAL) using the validated parameters
• Sterilization batch records for at least 3 recent cycles showing all critical process parameters recorded (time, temperature, pressure, gas concentration, humidity, exposure time, aeration time as applicable)
• Biological indicator (BI) and chemical indicator (CI) results for each sterilization batch
• Production batch-to-sterilization batch traceability matrix showing which production lots were included in each sterilization load
• Sterilization cycle printouts or data logger records providing continuous parameter recording during the cycle
• Parametric release criteria (if used) with validation evidence supporting parametric release

• Sterilization batch records show manually recorded temperature readings at the start and end of the cycle but no continuous monitoring data (chart recorder or data logger) to verify parameters were maintained throughout the entire cycle
• Biological indicator results are recorded as pass/fail without recording the BI lot number, D-value, or incubation conditions, making it impossible to verify the BI challenge level
• Cannot trace production batch 2024-0087 to a specific sterilization batch -- the sterilization load record lists the product name and quantity but not the production batch/lot numbers
• Sterilization validation was performed using a single product family as a worst-case load configuration, but new products have been added to the sterilization loads without evaluating whether the validation still covers the new load configuration
• EtO sterilization aeration parameters are not recorded in the batch record despite being critical validated parameters for ensuring residual EtO levels meet ISO 10993-7 limits

Review sterilization batch records for 3 recent cycles. For each, verify all validated parameters are recorded, BI/CI results are documented, and production batch traceability is maintained.

• When was your sterilization process last revalidated, and what triggered the revalidation?
• How do you handle a sterilization cycle where parameters deviate from validated ranges?
• What is your process for adding new products or load configurations to validated sterilization cycles?

• Validated parameter ranges for each sterilization cycle type (e.g., EtO: temperature, humidity, gas concentration, exposure time, aeration time; radiation: minimum and maximum dose; steam: temperature, pressure, exposure time)
• Sterilization batch records with parameter data compared against validated ranges -- verify each parameter is within the validated range for at least 3 recent cycles
• Continuous monitoring data (chart recorders, data loggers, PLC printouts) providing real-time parameter data throughout the cycle
• Sterilization equipment calibration records for temperature, pressure, gas concentration sensors, and timing devices
• Deviation records for any sterilization cycles where parameters exceeded validated ranges, with investigation and product disposition

• Validated sterilization exposure parameters have a defined acceptable range, but several recent batch records show parameters outside the validated range with no deviation raised or investigation performed
• Steam sterilization cycle printout shows a pressure drop during the hold phase that is outside the validated range, but the batch was released because the final BI was negative -- no formal deviation investigation was conducted
• Gas concentration sensor for the EtO sterilizer has not been calibrated in 14 months despite the calibration schedule requiring annual calibration
• Radiation dose monitoring records show 2 pallets received doses below the validated minimum dose, but the batch was not quarantined pending investigation

For 5 recent sterilization batches, compare recorded parameters against the validated ranges from the sterilization validation report. Identify any parameters outside range and verify deviation investigation was performed.

• What is your process when a sterilization parameter deviates from the validated range?
• Do you accept a negative BI result as sufficient to release a batch when parameters were out of range?
• How often do you perform sterilization equipment maintenance and sensor calibration?

• Traceability matrix or database linking production batch/lot numbers to sterilization batch numbers for at least 5 recent production lots
• Sterilization load records identifying all production lots included in each sterilization cycle
• Device History Record (DHR) showing sterilization batch number as part of the production history for finished devices
• Shipping records showing sterilization traceability is maintained through distribution (sterilization lot or batch number on shipping labels/documents)
• Demonstrated ability to perform a forward trace: given a sterilization batch number, identify all production lots and their distribution

• Sterilization load record lists the product name and quantity but does not record the production batch numbers, making it impossible to trace specific device lots to a sterilization cycle
• Multiple production batches are combined into a single sterilization load but the lot numbering system does not allow identification of which specific production batches were in which sterilization cycle
• Traceability is maintained from production to sterilization but is lost at distribution -- shipping records reference only the production lot number, not the sterilization batch, preventing recall identification based on sterilization failures
• A sterilization reprocessing event occurred (failed cycle followed by a re-sterilization) but the original sterilization batch assignment was overwritten rather than maintaining the complete traceability history

Perform one forward trace (sterilization batch to production lots to distribution) and one backward trace (finished device lot to sterilization batch to sterilization parameters). Verify the chain is complete.

• If you discovered a sterilization cycle failure, how quickly could you identify all affected product lots and their distribution?
• How do you maintain traceability when multiple production batches are combined in a single sterilization load?
• What happens to traceability records when product is reprocessed through a second sterilization cycle?

• Environmental monitoring records for cleanroom or controlled areas where sterile devices are manufactured and packaged (particulate counts, microbial monitoring, temperature, humidity, differential pressure)
• Component and material lot traceability records linking specific material lots to production batches of sterile devices
• Packaging material records including lot numbers, sterilization compatibility data, and shelf-life information
• Pre-sterilization handling and storage records documenting conditions between manufacturing/packaging and sterilization
• Cleanroom certification or requalification records demonstrating the manufacturing environment meets classification requirements

• Environmental monitoring for the sterile packaging area shows a particulate count excursion 6 weeks ago, but the investigation record does not assess the impact on product sterility for batches manufactured during the excursion period
• Packaging material lot numbers are not recorded in the device history record, preventing traceability of specific packaging material lots to finished device lots in the event of a packaging material defect
• Cleanroom certification has expired and has not been renewed; the facility is still operating under the assumption that the environment meets classification requirements
• No records are maintained of the duration and conditions of pre-sterilization storage, despite the sterilization validation being based on a maximum time-to-sterilize assumption

Review 6 months of environmental monitoring data for the sterile manufacturing area. Check for any excursions and verify that product impact assessments were performed for each.

• What is the maximum allowable time between product manufacture and sterilization, and how do you monitor it?
• How do you assess the impact on product sterility when environmental monitoring shows an excursion?
• Are your packaging materials tested for sterilization compatibility, and how are lot changes managed?

• Validation master plan or register identifying all special processes (processes whose output cannot be fully verified by subsequent inspection or testing), their validation status, and revalidation schedule
• Complete validation package (IQ/OQ/PQ protocols, execution records, and summary reports) for at least one special process
• List of special processes with justification for why each is classified as a special process (i.e., why output cannot be fully verified by inspection)
• Revalidation criteria and schedule for each validated process, with evidence of adherence
• Change control records showing that changes to validated processes trigger revalidation assessment
• Process validation records for: sterilization, welding, sealing, molding, soldering, coating, heat treatment, or other applicable special processes

• Ultrasonic welding process for assembling a fluid pathway device is not identified as a special process and has no validation, despite the weld integrity being unverifiable by non-destructive inspection and critical to device safety
• Injection molding process validation (IQ/OQ/PQ) was completed on the original molding machine; the machine was replaced with a newer model and production continued without revalidation
• Sterilization validation exists but the pouching/sealing process was never validated as a separate special process, despite the seal being the sterile barrier and not 100% destructively testable
• Process validation reports show acceptance criteria were met but the criteria were set after reviewing the data (retrospective criteria setting) rather than being predefined in the protocol
• No validation master plan exists; special processes requiring validation are not centrally tracked, and the organization cannot identify all processes that require validation

Review the validation master plan for completeness. Select 2 validated special processes and review their full validation packages (IQ/OQ/PQ). Verify acceptance criteria were predefined, validation is current, and no unassessed changes have occurred.

• How do you determine whether a process is a 'special process' requiring validation vs. a standard process verified by inspection?
• What triggers revalidation of a special process?
• Can you show me a process change that triggered revalidation and the resulting revalidation records?

• Process validation protocol defining predefined acceptance criteria for IQ, OQ, and PQ phases, including measurable pass/fail criteria for each test
• Validation review and approval records showing that results were formally reviewed against the predefined criteria and approved by authorized personnel
• Deviation records from validation activities showing how deviations from acceptance criteria were assessed and resolved
• Approval authority matrix defining who can approve validation protocols and reports

• Validation protocol acceptance criteria are vague ('process shall produce acceptable product') without specific measurable parameters, limits, or statistical criteria
• PQ acceptance criteria require 'zero defects' in the validation run, but this criteria provides no statistical confidence for the production lot sizes actually manufactured
• Validation report was approved by the process engineer who performed the validation with no independent quality review or approval
• Acceptance criteria in the validation report differ from those in the protocol, with no documented justification or change control for the modification

Review one complete PQ report. Verify acceptance criteria were predefined in the protocol, results are compared against those specific criteria, and the approval was performed by authorized personnel with independent review.

• How do you establish appropriate statistical sample sizes and confidence levels for process validation?
• What happens if validation results meet some criteria but fail others?
• Who has the authority to approve validation protocols and reports, and are these the same person?

• Installation Qualification (IQ) records for production equipment demonstrating that the equipment was installed correctly per manufacturer specifications, utilities meet requirements, and all components are present
• Operational Qualification (OQ) records demonstrating the equipment operates within specified parameters across the defined operating range, including worst-case conditions
• Personnel qualification records for operators of special processes (e.g., welder qualification per applicable standard, sterilizer operator certification, injection molding technician competency assessment)
• Requalification records for equipment after maintenance, repair, or relocation
• Operator training records specific to the validated process including demonstration of competence

• New injection molding machine was installed and placed into production with only an IQ; no OQ was performed to verify the machine operates within the required parameter ranges
• Sterilizer underwent major maintenance (control system replacement) but no requalification (IQ/OQ) was performed before returning to production use
• Special process operators (ultrasonic welders) have general training records but no process-specific qualification demonstrating they can consistently operate the process within validated parameters
• Equipment OQ was performed using test fixtures rather than actual production tooling, meaning the OQ results may not be representative of production conditions

Select one validated special process. Review the equipment IQ/OQ records for completeness and verify that operator qualification records exist for all personnel currently performing the process.

• What triggers equipment requalification (IQ/OQ) for production equipment?
• How do you qualify operators when they first begin working on a validated special process?
• What happens when a qualified operator returns to a special process after an extended absence?

• Work instructions or SOPs for validated processes specifying the exact validated parameters (setpoints, ranges, sequences) that must be used during production
• Acceptance criteria for in-process monitoring during validated process operation (e.g., seal strength, weld tension, cycle parameters)
• Production batch records showing validated parameters were maintained during recent production runs
• Evidence of process monitoring or control systems (SPC, automated parameter monitoring, lockouts) that prevent operation outside validated ranges

• Validated sealing process has specified parameters of 180°C ± 5°C and 2.0 seconds ± 0.2 seconds, but the production work instruction says only 'set temperature to 180 and time to 2 seconds' without specifying the validated ranges or requiring monitoring
• Injection molding machine allows operators to adjust parameters freely; there are no password protections or lockouts to prevent operation outside the validated parameter window
• Production batch records do not capture the actual process parameters used, only whether the product 'passed' visual inspection -- there is no evidence that validated parameters were maintained
• Methods specified in the validation protocol differ from those in the current production work instruction, with no change control documentation to explain the discrepancy

For 2 validated processes, compare the work instruction parameters against the validated parameters. On the floor, verify actual equipment setpoints match both. Review 2 batch records for evidence that validated parameters were maintained.

• Can operators adjust process parameters beyond validated ranges? What controls prevent this?
• How do you verify that validated parameters are actually maintained during each production run?
• What happens when a process parameter drifts outside the validated range during production?

• Statistical rationale document or section within validation protocols justifying sample sizes based on defined confidence level, reliability level, and acceptable defect rate
• Process capability analysis (Cpk/Ppk calculations) performed during PQ with appropriate sample sizes
• Reference to applicable standards or guidance documents used for statistical methodology (e.g., ANSI/ASQ Z1.4, GHTF HTAH 2004, ASTM E2709)
• Comparison of sample sizes to device risk classification requirements (higher-risk devices typically require higher confidence/reliability levels)

• PQ protocol specifies a sample size with zero defects as the acceptance criterion, but no statistical rationale documents the confidence/reliability level this provides or why it is appropriate for the risk level of the process
• Process validation for a Class III implant uses the same sample size (n=30) as a Class I device, with no risk-based justification for why the same confidence level is appropriate
• Cpk calculation in the validation report is based on only 10 measurements, which is insufficient for a meaningful process capability assessment
• Statistical rationale references 'industry standard' or 'commonly accepted practice' without citing a specific standard, guidance document, or calculation

Review PQ protocols for 2 validated processes. Verify the statistical rationale for sample sizes is documented, calculations are correct, and the chosen confidence/reliability level is appropriate for the device risk class.

• What confidence and reliability level does your standard PQ sample size provide?
• Do you adjust validation sample sizes based on device risk classification?
• How do you handle validation when one or more defects are found in the PQ sample?

• Complete validation record packages for at least 2 special processes including: approved protocols, raw data, executed records, deviation reports, summary reports with conclusions, and approval signatures
• Record retention schedule demonstrating validation records are retained for the required period (device lifetime + regulatory requirements)
• Evidence that validation records are stored in a controlled, retrievable system (not on individual engineers' hard drives or in unsecured locations)
• Periodic review records confirming validation status remains current (no changes that would require revalidation)

• Validation report references raw data collected during OQ and PQ execution, but the raw data cannot be located -- only the summary report with calculated results exists
• Validation records for a sealing process are stored on the former validation engineer's personal network drive, which is no longer accessible; no controlled copy exists in the QMS
• Process validation for sterilization was performed by an outside contractor who retained the original records; the organization has only a summary letter, not the complete validation package
• Validation record retention policy specifies 5 years, which is less than the expected device lifetime, creating a regulatory risk for devices still on the market when records are destroyed

For one validated process, request the complete validation record package from protocol through final report. Verify raw data is available, records are stored in a controlled system, and retention meets requirements.

• Where are your validation records stored, and who has access?
• Can you produce the raw data behind this validation report?
• What is your record retention period for validation records, and how does this relate to device lifetime?

• Revalidation criteria document or procedure defining what triggers revalidation: time-based periodic revalidation, equipment changes, material changes, process parameter changes, product changes, adverse trend in process output
• Revalidation schedule showing planned revalidation dates for each validated process and adherence to the schedule
• Recent revalidation records showing the trigger, scope, protocol, results, and conclusions
• Change control records where process changes were evaluated for revalidation impact, with documented decisions (revalidation required vs. not required with rationale)

• No revalidation criteria are defined -- processes validated years ago have never been assessed for revalidation despite equipment wear, personnel changes, and minor process adjustments over time
• Revalidation criteria include 'significant process changes' but do not define what constitutes a 'significant' change, leaving the assessment subjective and inconsistent
• Revalidation was due per the periodic revalidation schedule but has not been performed; the delay is not documented and no risk assessment was conducted
• Process parameters for a validated sealing process were adjusted twice in the last year via change orders, but neither change was evaluated against the revalidation criteria

Review the revalidation schedule for adherence. Select 2 process changes from the last year and verify they were evaluated against revalidation criteria with documented decisions.

• What is the periodic revalidation interval for each special process, and how was it determined?
• Can you show me a process change that was evaluated against revalidation criteria? What was the decision?
• How do you handle a situation where revalidation reveals the process is no longer capable?

• Change control procedure defining how changes to validated processes are proposed, assessed for impact on validation status, approved, implemented, and verified
• Change control records for at least 2 recent changes to validated processes showing the change description, impact assessment on validation status, approval, and any required revalidation
• Evidence that unauthorized changes to validated processes are prevented through physical controls (lockouts, password protection) or procedural controls (access restrictions)
• Records of post-change verification or revalidation activities demonstrating the process remains in a validated state after the change

• Production operator adjusted the sealing temperature on a validated sealing machine by 10°C to address a quality issue, without going through the change control process; the adjustment has been in use for several months
• Change control record approves a material change for a validated process but the revalidation assessment states 'no revalidation needed' with no documented rationale or risk assessment
• Emergency process changes are made verbally by the production supervisor and documented retroactively days or weeks later, bypassing the normal change approval process
• Change control system does not include validated processes as a specific category, resulting in process changes being managed through the general change system without triggering validation impact assessment

Review 2 recent change control records for validated processes. Verify each includes a validation impact assessment with documented rationale, and that any required revalidation was completed before production resumed.

• How do you prevent unauthorized changes to validated process parameters on the production floor?
• How do you handle emergency changes to a validated process when there is no time for formal change control?
• What constitutes a 'minor' vs. 'major' change to a validated process, and how does this affect the revalidation decision?

• Product identification procedure defining the identification methods used at each stage of production (labels, travelers, barcodes, RFID, part markings, color coding)
• Demonstrated product identification at multiple production stages: incoming material, work-in-process, finished goods, quarantine, rejected material
• Part numbering system or nomenclature defining the naming convention for products, assemblies, and components
• Evidence of unique lot/batch identification for each production batch
• Identification of product status at each stage (raw material, in-process, inspected, approved, rejected, on-hold)

• Work-in-process containers at the assembly workstation have no labels identifying the product, lot number, or production status -- operators identify products by visual recognition only
• Raw material containers in the warehouse have supplier labels but no internal identification connecting them to the organization's material specifications or approved supplier lot
• Rejected material quarantine area contains products with no identification labels, making it impossible to determine what the products are, which batch they belong to, or why they were rejected
• Two similar-looking products (different catalog numbers) are processed on the same production line but the identification labels are applied at final packaging only, creating a mix-up risk during in-process stages
• Product identification is lost during a rework or reprocessing step because the original identification labels are removed and new labels are not applied until the rework is complete

During the floor tour, verify product identification at 5 different production stages (incoming, WIP, inspection, finished goods, and quarantine). At each stage, confirm you can determine what the product is and its current status.

• How do you maintain product identification during rework or reprocessing?
• What happens if a product identification label is damaged or lost during production?
• How do you prevent mix-ups between similar products processed on the same line?

• Status identification system (labels, stamps, electronic status, physical segregation, color coding) showing inspection/test status at each production stage
• Physical or system-based controls preventing non-inspected product from moving to the next stage or being shipped
• Clear identification of quarantined, rejected, or on-hold product that distinguishes it from approved product
• Batch record or production traveler showing sequential sign-off at each inspection point
• Evidence that status identification is maintained throughout all production stages including during storage and material handling

• Products awaiting final inspection are stored in the same area as released products with no physical segregation or status identification to distinguish them -- 3 boxes of uninspected product were found mixed with released product
• Inspection stamps are used to indicate pass/fail status but the stamp colors have faded and are no longer distinguishable, and operators report being unable to tell a 'pass' stamp from a 'fail' stamp
• Electronic production system shows batch status as 'complete' after the last manufacturing step but before final inspection, creating ambiguity about whether the product has been inspected and released
• Reworked product is returned to the production line without a clear status indication of whether it needs re-inspection, leading to some reworked units bypassing the required re-inspection step

During the floor tour, identify 5 units of product at different stages. For each, verify you can determine its inspection/test status. Check the quarantine area for proper identification of rejected or held product.

• What physical or system controls prevent shipment of product that has not passed final inspection?
• How do you identify partially inspected product (passed some but not all inspection stages)?
• What happens to the status identification when product is moved between locations or stored long-term?

• Traceability procedure defining the extent of traceability, methods, and records required at each stage of the product lifecycle
• Demonstrated backward traceability from a finished device lot/serial number to: production batch record, component lot numbers, raw material lot numbers, sterilization batch (if applicable), and distribution records
• Demonstrated forward traceability from a component or raw material lot to all finished device lots that used it (recall simulation)
• UDI (Unique Device Identification) implementation records demonstrating compliance with applicable UDI requirements (FDA, EU MDR)
• Traceability system test or mock recall records showing the system was tested for effectiveness

• Traceability from finished devices to component lots breaks at the assembly stage -- the batch record records the component part number but not the specific lot number of the component used in each batch
• UDI is assigned to the device but the production information (manufacturing date, lot number) is not encoded in the UDI carrier (barcode/RFID) as required by the applicable regulation
• Forward traceability test (mock recall) was attempted but it took 3 days to identify all affected product, far exceeding the 24-hour timeframe expected by regulatory authorities
• Traceability records for an implantable device do not extend to the patient level, despite the regulatory requirement for implant traceability in the applicable market
• Component substitution during a production shortage was not recorded in the batch record, breaking traceability for the substitute component lot

Perform one backward trace (finished device to raw material lots) and one forward trace (raw material lot to all finished devices). Time both exercises. Verify the traceability chain is complete at every link.

• When was the last time you performed a mock recall, and how long did it take to identify all affected product?
• How do you handle traceability when components are pooled or mixed between lots during production?
• Is your UDI implementation compliant with both FDA and EU MDR requirements?

• Documented traceability procedure defining the extent of traceability for each product family based on regulatory requirements and risk
• Regulatory requirement matrix showing traceability requirements for each market where products are sold (FDA, EU MDR, Health Canada, TGA, etc.)
• Traceability extent determination records showing how the required level was established (e.g., lot-level vs. unit-level traceability based on device classification)
• Records demonstrating the defined traceability is actually maintained in practice

• No documented procedure defines the extent of traceability -- traceability practices vary between product lines based on individual quality engineers' interpretations of requirements
• Traceability extent was determined based on ISO 13485 alone without considering market-specific regulatory requirements (e.g., EU MDR Article 27 UDI requirements, FDA 21 CFR 820.65 for critical devices)
• Procedure defines lot-level traceability but actual records only support product-family-level traceability because multiple lots are pooled during processing stages

Review the traceability procedure and verify the extent of traceability is defined, regulatory requirements for each market are addressed, and the defined extent is achievable based on actual record-keeping practices.

• How does the extent of traceability differ between your Class I and Class III products?
• Have you assessed traceability requirements for all markets where your products are sold?
• What is the minimum lot size in your traceability system, and is it appropriate for recall scope management?

• Distributor agreements or quality agreements requiring distributors and importers to maintain distribution records including consignee names and addresses, device lot/serial numbers, and quantities
• Importer traceability requirements defined in agreements or contracts
• Evidence of distributor compliance: samples of distributor-maintained distribution records, audit records verifying distributor traceability practices, or compliance certifications
• Patient implant records or registry participation for implantable devices where required

• Distributor agreements for implantable devices do not include requirements for maintaining device-level distribution records that enable patient traceability
• Organization has never verified that distributors are actually maintaining the required distribution records -- agreements exist but compliance has never been audited
• Distribution chain for one market involves 3 intermediaries (distributor, sub-distributor, hospital purchasing group), and traceability is lost at the sub-distributor level because no traceability requirements flow down beyond the first-tier distributor

For implantable devices, review 2 distributor agreements for traceability requirements. Request evidence that at least one distributor's compliance with these requirements has been verified (audit record or sample records).

• If you needed to identify all patients who received a specific lot of an implantable device, could you do it? How long would it take?
• How do you verify that your distributors actually maintain the distribution records required by your agreement?
• Do your traceability requirements flow down to sub-distributors and hospital purchasing groups?

• Samples of distribution records maintained by distributors showing device lot/serial numbers, consignee details, and shipping dates
• Distributor audit reports where distribution record-keeping was specifically assessed
• Distributor compliance certifications or self-assessment questionnaires addressing traceability record maintenance
• Evidence of a recent forward-trace exercise through the distribution chain to a specific end-user

• Organization has 12 authorized distributors for implantable devices but has never requested or reviewed sample distribution records from any of them to verify traceability capability
• Distributor audit was conducted but the audit report shows traceability record-keeping was not included in the audit scope
• Sample distribution records obtained from one distributor show device quantities but not lot or serial numbers, making device-level traceability impossible

Request the most recent distributor audit report for a distributor of implantable devices and verify that distribution record-keeping was assessed. If available, review sample distribution records from the distributor.

• When was the last time you requested sample distribution records from a distributor to verify their traceability capability?
• Is traceability record-keeping a standard item in your distributor audit checklist?
• How do you handle a distributor who cannot provide adequate traceability records?

• Distributor agreements containing clauses granting regulatory authority access to distribution records maintained by the distributor
• Record retention requirements in distributor agreements specifying minimum retention periods consistent with regulatory requirements
• Evidence of record accessibility: defined process for requesting and obtaining distributor records within a specified timeframe
• Contractual language granting the manufacturer and regulatory authorities right of access and audit to distribution records

• Distributor agreements do not include provisions for regulatory authority access to distribution records, potentially leaving the manufacturer unable to satisfy regulatory requests for traceability information
• Record retention period in distributor agreement is 3 years, while regulatory requirements require retention for the expected lifetime of the implantable device (typically 10+ years)
• No defined process or timeframe exists for obtaining distribution records from distributors; previous attempts to obtain records from one distributor took over 6 weeks

Review distributor agreements for 2 implantable device distributors. Verify they include regulatory inspection access provisions and record retention requirements consistent with the expected device lifetime.

• How quickly could you obtain distribution records from your distributors if a regulatory authority requested them?
• Do your agreements require distributors to retain records for a period consistent with your regulatory requirements?
• What happens to distribution records if a distributor ceases business or terminates the agreement?

• Device History Records (DHRs) for implantable devices showing component lot traceability, material certificates, and manufacturing conditions for at least 2 recent batches
• Environmental monitoring records for manufacturing areas producing implantable devices (cleanroom conditions, temperature, humidity)
• Material certificates of conformity or analysis for critical materials used in implantable device production, linked to specific production batches
• Manufacturing condition records that could affect device safety: environmental excursions, process deviations, equipment anomalies during implant production

• DHR for an orthopedic implant batch records the component part numbers but not the specific lot numbers of the titanium raw material, preventing traceability of material composition to finished implants
• Environmental monitoring records show a particulate excursion during the manufacturing of a hip implant batch, but the DHR does not reference this excursion and no impact assessment was documented
• Material certificates are maintained in a general supplier file but are not linked to specific production batches, making it impossible to determine which material lot was used in which implant batch

For one recent implant batch, request the DHR and verify: all critical material lots are recorded with certificates, environmental conditions during production are documented, and any excursions are linked to the batch.

• If an implant failed in a patient and you needed to investigate, what records would you use?
• How do you link environmental monitoring excursions to specific implant production batches?
• Are material certificates linked to specific production batches, or maintained only at the supplier file level?

• Distribution records for implantable device shipments showing consignee name, address, device lot/serial numbers, quantity shipped, and ship date for at least 3 recent shipments
• Shipping documentation (packing lists, bills of lading, commercial invoices) including consignee identification for implantable devices
• Distribution database or log that enables identification of all consignees who received a specific device lot/serial number
• Chain of custody documentation for high-risk implantable devices

• Distribution records for implantable devices show shipment to a distribution center address, not the final consignee (hospital or clinic), meaning the organization cannot identify the final destination of specific device lots
• Shipping records contain consignee name but not address, or address but not device lot/serial numbers, rendering the records insufficient for recall identification
• Distribution database for implantable devices has data entry errors in consignee addresses for approximately a significant percentage of records, based on a sample audit

Select one implant lot and request the complete distribution records. Verify every unit is accounted for with consignee name and address. Confirm the records support a recall notification to all recipients.

• Can you identify all consignees who received a specific lot of an implantable device?
• How do you maintain consignee records when product is shipped through intermediaries?
• Have you tested your recall effectiveness by performing a mock recall using your distribution records?

• Customer property procedure defining identification, verification, protection, and safeguarding requirements for customer-provided items
• Customer property register or inventory listing all customer-owned items currently held by the organization, their location, condition, and custodian
• Identification methods for customer property (labels, tags, dedicated storage) that distinguish it from organization-owned items
• Records of customer property condition verification at receipt and any damage, loss, or deterioration reporting to the customer
• Protection and storage conditions for customer property, especially for sensitive items (IP, tooling, biological samples)

• Customer-supplied tooling used in production is not identified as customer property; if the customer relationship ended, the organization would not know which tools belong to the customer
• Customer-owned test fixtures are stored in the general tool crib with no special identification or protection, and two fixtures show visible damage that has not been reported to the customer
• Organization receives patient data from hospital customers for post-market analysis but has no documented procedure for handling, protecting, and securing this personal data as customer property

Review the customer property register. Physically inspect 2-3 items of customer property to verify identification, condition, and protection. Check for any unreported damage or deterioration.

• What types of customer property do you hold, and where is it located?
• Have you ever had to report loss or damage of customer property? What was the process?
• How do you handle customer intellectual property and confidential information?

• Care instructions or handling procedures specific to different types of customer property (tooling, samples, data, IP)
• Storage conditions for customer property demonstrating appropriate environmental controls
• Insurance or liability coverage for high-value customer property
• Training records for personnel who handle customer property

• Customer-supplied biological samples requiring cold storage are stored in a general-purpose refrigerator with no temperature monitoring, creating a risk of sample degradation
• No specific handling procedures exist for customer-provided precision tooling worth over $100,000; tooling is handled the same as general production equipment
• Customer data is stored on a shared network drive with broad access permissions rather than a restricted, encrypted repository

Identify the highest-value or most sensitive customer property held by the organization. Verify that specific care measures are defined, implemented, and documented.

• How do you determine the appropriate level of care for different types of customer property?
• What insurance or liability coverage do you have for customer property?
• How do you train personnel who handle sensitive customer property?

• Incoming verification records for customer-supplied components or materials (inspection, test, or verification that they meet specifications before incorporation into product)
• Identification system distinguishing customer-supplied items from purchased items in inventory and production
• Protection measures for customer-supplied items during storage and handling
• Traceability records linking customer-supplied items to specific production batches

• Customer-supplied components are not verified upon receipt before incorporation into the product; the assumption is that the customer's incoming inspection is sufficient, but no agreement documents this arrangement
• Customer-supplied materials are stored in the same locations as purchased materials with no differentiated identification, creating a risk of incorrect handling or disposition
• Customer-supplied samples used for comparison testing are not traceable to specific test reports, compromising the validity of the comparison results

If customer-supplied items are used in production, review incoming verification records and trace 2 items through production to verify identification and traceability are maintained.

• How do you verify that customer-supplied components meet your specifications before use?
• What happens if a customer-supplied item is found to be nonconforming?
• How do you trace customer-supplied items through your production process?

• Product preservation procedure covering identification, handling, packaging, storage, and protection during internal processing and delivery
• Storage area inspection records showing compliance with defined conditions (temperature, humidity, cleanliness, organization, FIFO/FEFO)
• Shelf-life management records demonstrating product is shipped within its defined shelf life and expired product is identified and quarantined
• Handling instructions for fragile, sterile, or environmentally sensitive products
• Shipping qualification records demonstrating packaging and shipping methods preserve product integrity during transport

• Finished goods storage area is not climate-controlled despite product specifications requiring storage at 15-30°C; summer temperatures in the warehouse exceed 35°C with no monitoring or mitigation
• No shelf-life management system exists for products with defined expiration dates; FIFO is practiced informally but 3 lots were found in stock past their expiration date
• Sterile products are stored without special handling precautions; multiple cases of damaged sterile barrier packaging were found in the warehouse, some with repaired (taped) packaging returned to stock
• Products requiring protection from light are stored under fluorescent lighting with no UV protection

Walk the warehouse and finished goods storage. Check 5 random products for storage condition compliance, shelf-life status, packaging integrity, and identification. Look for expired or damaged product.

• How do you manage product shelf-life and ensure FIFO/FEFO?
• What happens when a warehouse environmental excursion is detected?
• How do you handle sterile product with damaged packaging found in storage?

• Packaging design records including material specifications, design drawings, and rationale for packaging configuration
• Packaging validation records including seal strength testing, whole package integrity testing, and distribution simulation testing per applicable standards (ASTM D4169, ISTA protocols)
• Sterile barrier system validation per ISO 11607 (if applicable) including aging studies (accelerated and real-time)
• Packaging material specifications and incoming inspection records for packaging materials
• Distribution simulation or transit testing records demonstrating packaging protects product during worst-case distribution conditions

• Sterile barrier system packaging was validated using accelerated aging only; the accelerated aging study has expired (beyond the claimed shelf life) and real-time aging data is not available to support the continued shelf-life claim
• Distribution simulation testing was performed on the product but the packaging configuration, materials, and distribution routes have changed since the original testing with no revalidation
• Packaging material specifications do not include critical properties (burst strength, peel strength, porosity) for the sterile barrier material, relying only on the supplier's general data sheet
• No packaging validation exists for an accessory kit that contains sharp components; multiple customer complaints of damaged packaging and loose sharp items have been received

Review the sterile barrier system validation package for one product, including seal strength data, whole package integrity, accelerated aging, and distribution simulation. Verify the validation supports the current packaging configuration and claimed shelf life.

• What is the status of your real-time aging study for sterile barrier packaging?
• When was your distribution simulation testing last performed, and does it represent current distribution conditions?
• How do you evaluate packaging changes for impact on the validated state?

• Documented special condition requirements for products requiring conditions beyond standard packaging (temperature control, humidity control, light protection, orientation, vibration limits)
• Shipping labels, indicators, or monitors for special condition products (temperature indicators, tilt indicators, shock indicators)
• Environmental monitoring records during transport for temperature-sensitive or other condition-sensitive products
• Documented agreements with logistics providers specifying special condition requirements and evidence of compliance

• Temperature-sensitive product requires cold-chain shipping (2-8°C) but shipping records show no temperature monitoring data for transit, and the logistics provider agreement does not specify temperature requirements
• Product labeling shows 'Do Not Stack' and 'This Side Up' symbols but no special handling instructions are communicated to the logistics provider in shipping documentation
• Humidity-sensitive product is shipped with a desiccant inside the packaging but no humidity indicator is included to verify the desiccant was effective during transit, and no outgoing humidity level is recorded

Identify products with documented special preservation requirements. Review 2 recent shipments for evidence that special conditions were specified, monitored, and maintained during transit.

• How do you qualify your logistics providers for handling condition-sensitive products?
• What happens when a temperature indicator shows an excursion during transit?
• How do you communicate special condition requirements to each party in the distribution chain?

• Measurement equipment master list or inventory showing all controlled instruments with unique ID, description, location, calibration status, calibration interval, and responsible person
• Measurement requirements analysis or inspection and test plans linking product specifications to the specific measurements and equipment needed to verify conformity
• Equipment selection records demonstrating that measurement equipment was selected with appropriate range, resolution, and accuracy for the intended measurement
• Calibration procedure defining the calibration program scope, responsibilities, methods, intervals, traceability requirements, and out-of-tolerance handling
• Evidence that all equipment used to accept or reject product is included in the calibration program (no uncontrolled instruments in use for acceptance decisions)

• Measurement equipment master list is incomplete -- 3 instruments found in use at production workstations for acceptance decisions are not included in the calibration program and have no calibration records
• No measurement requirements analysis exists; equipment was selected based on availability rather than suitability for the specific measurement (e.g., a caliper with 0.02mm resolution used to accept a dimension with ±0.01mm tolerance)
• Environmental monitoring equipment (thermometers, hygrometers) used to verify controlled conditions in clean rooms and storage areas is not included in the calibration program
• Test equipment used by outsourced testing laboratories is not included in the organization's equipment oversight despite being used for product acceptance decisions
• Master list has not been updated in 2 years; several instruments on the list have been replaced or retired but still appear as active

Walk the production floor and inspection areas. Identify 5 instruments in use for acceptance decisions and verify each is on the master list with current calibration status.

• How do you ensure every new instrument is added to the calibration program before it is used for acceptance decisions?
• Are instruments at outsourced testing labs included in your equipment oversight?
• How do you determine when an instrument should be retired from service?

• Equipment capability studies (Gage R&R, measurement system analysis) for instruments used to accept/reject product on critical dimensions or parameters
• Equipment selection criteria linking measurement requirements (tolerance, resolution needed) to instrument specifications (range, resolution, accuracy, repeatability)
• Measurement uncertainty budgets or estimates for critical measurements, demonstrating that uncertainty is small relative to the product tolerance
• Performance verification records for new instruments before they enter the calibration program
• Evidence that instruments at or near the end of their useful life are assessed for continued capability

• No Gage R&R or measurement system analysis has been performed for any instruments used for critical acceptance decisions, despite the facility performing hundreds of dimensional inspections per day
• An instrument with a specified accuracy equal to the tolerance being measured is used for acceptance decisions, meaning the measurement uncertainty consumes the entire tolerance and the measurement is unreliable for accept/reject decisions
• Measurement uncertainty is not considered in any acceptance decision; products measured at exactly the specification limit are accepted without accounting for measurement uncertainty
• Visual inspection 'instruments' (magnifying lamps, microscopes) are not included in any capability assessment despite being used for critical cosmetic and visual acceptance decisions

Identify the 3 most critical product measurements (tightest tolerances or highest safety impact). Verify that the instruments used for these measurements have documented capability studies (Gage R&R or equivalent) and that measurement uncertainty is small relative to the tolerance.

• How do you determine whether an instrument is capable of performing a specific measurement?
• Is measurement uncertainty considered when products are measured near specification limits?
• What Gage R&R or measurement system analysis studies have been performed for critical measurements?

• Calibration SOP defining the calibration process: scheduling, performance, recording, labeling, out-of-tolerance handling, and storage of instruments
• Calibration work instructions for specific instrument types detailing the calibration points, methods, acceptance criteria, reference standards, and environmental conditions required
• Calibration schedule or calendar showing planned calibration dates and compliance rate
• Calibration records for at least 3 recently calibrated instruments showing: instrument ID, calibration date, calibration standard used (with traceability), as-found data, adjustments made, as-left data, pass/fail determination, and calibration technician
• Out-of-tolerance investigation procedure and records for instruments found out of specification during calibration

• Calibration procedure exists but lacks specific calibration methods or work instructions for individual instrument types, leaving the calibration points, methods, and acceptance criteria to the technician's discretion
• Calibration records show only 'PASS' or 'FAIL' without recording the actual as-found and as-left measurement data, making it impossible to assess measurement uncertainty or drift trends
• Calibration schedule shows 8 instruments overdue for calibration, including 2 instruments actively used in production for in-process acceptance decisions
• No procedure exists for handling instruments found out of tolerance during calibration, despite this being one of the most critical aspects of the calibration program
• Calibration is performed in the production area without controlling environmental conditions (temperature, humidity), which can affect calibration accuracy for precision instruments

Review the calibration schedule for overdue instruments. Select 3 recently calibrated instruments and review their calibration records for completeness (as-found/as-left data, standards used, technician identification, pass/fail determination).

• How do you determine calibration intervals for different instrument types?
• Do your calibration records capture as-found and as-left data?
• What environmental conditions are controlled during calibration, and how are they verified?

• Complete calibration records for at least 3 instruments showing: instrument ID, date, calibration standard(s) used with traceability reference, environmental conditions, as-found readings, adjustments performed, as-left readings, pass/fail determination, and technician identification
• Historical calibration data for at least 2 instruments over multiple calibration cycles, demonstrating data retention and availability for trending
• Calibration data trending analysis showing drift patterns used to optimize calibration intervals
• Calibration database or record management system demonstrating controlled access, backup procedures, and data integrity
• Record retention policy for calibration records aligned with product lifetime and regulatory requirements

• Calibration records consist only of calibration certificates from the external lab; no as-found data is recorded, preventing drift analysis and making OOT impact assessment impossible if as-left data is within tolerance
• Historical calibration data for instruments calibrated in-house is stored in individual Excel spreadsheets on the calibration technician's personal computer with no backup, version control, or access control
• Calibration records for several sampled instruments are missing for one or more calibration cycles, creating gaps in the calibration history that prevent continuous traceability
• No calibration data trending is performed; all instruments are calibrated at fixed intervals regardless of their historical stability, wasting resources on stable instruments and potentially under-calibrating unstable ones

Request complete calibration records (with as-found/as-left data) for 3 instruments over at least 3 calibration cycles. Verify records are complete, data integrity is maintained, and trending is performed for at least critical instruments.

• How long do you retain calibration records, and does this meet your regulatory requirements?
• Do you use calibration trending data to optimize calibration intervals?
• Where are your calibration records stored, and how is data integrity protected?

• Inventory of all computer software used for monitoring and measurement (automated test systems, measurement data collection software, SPC software, inspection software, Excel spreadsheets with calculations used for acceptance decisions)
• Software validation protocol and report for each software tool demonstrating it satisfies its intended application, including: requirements specification, test protocol, test results, conclusion, and approval
• Software change control records showing how software changes (updates, patches, configuration changes) are managed, with revalidation assessment for each change
• Validation records for Excel spreadsheets or other general-purpose software tools used for measurement calculations or data reduction in product acceptance decisions
• Periodic reconfirmation records demonstrating software continues to function correctly (especially after system updates, hardware changes, or migrations)

• Automated optical inspection system running proprietary software for dimensional measurement of components has no validation records; the software was installed by the equipment vendor and accepted 'as is' without independent validation by the organization
• Excel spreadsheets used to calculate critical measurements (statistical analysis of incoming inspection data, calibration uncertainty calculations) have no validation and no protection against formula modification -- any user can change the formulas
• SPC software was validated against the original version; the software has been updated multiple times since then with no revalidation assessment for any update
• Measurement data collection software used in the production line was migrated from one server to another during an IT upgrade, but no verification was performed to confirm it still functions correctly after migration
• Test automation software for functional testing of finished devices uses measurement algorithms that have never been verified against known reference values

Request the inventory of software used for monitoring and measurement. Select 2 tools (preferably one dedicated measurement software and one general-purpose tool like Excel) and verify validation records exist, changes are controlled, and periodic reconfirmation is performed.

• How do you manage Excel spreadsheets used for measurement calculations or acceptance decisions?
• What is your approach to revalidating software after updates or system changes?
• How do you validate software that is part of purchased automated test equipment?

• Out-of-tolerance impact assessment procedure defining the steps for evaluating the effect of an out-of-calibration instrument on previous measurements and products
• Completed impact assessment records for at least 2 recent OOT events showing: which instrument was affected, the magnitude and direction of the error, the period during which measurements could have been affected (from last known good calibration), the products measured during that period, evaluation of whether the error could have caused nonconforming product to be accepted, and the disposition decision
• Product disposition records for any products identified as potentially affected by OOT measurements (reinspection, recall evaluation, concession, scrap)
• Corrective actions taken on the instrument (repair, adjustment, replacement, interval change) and any systemic actions

• Instrument found 0.08mm out of tolerance during annual calibration; impact assessment states 'minimal impact' without identifying which products were measured, calculating the measurement uncertainty including the drift, or evaluating specific dimensions against tolerance
• Out-of-tolerance investigation identifies 15 production lots potentially measured with the affected instrument, but no reinspection or product evaluation was performed because 'all lots had passed visual inspection'
• Impact assessment is performed for instruments found out of tolerance but not for instruments found to have been in use with expired calibration, despite the same risk of invalid measurements
• Assessment concludes 'no product impact' for every OOT event in the past 2 years, suggesting the assessments may lack rigor or the organization is not performing genuine risk evaluations
• No records exist of impact assessment for an instrument that was dropped and returned to use without recalibration, which was later found to be significantly out of tolerance

Review all OOT events from the last 12 months. For at least 2 events, verify the impact assessment identifies affected products, evaluates the magnitude of the error against product tolerances, and documents a risk-based disposition decision.

• How do you identify all products measured with an out-of-tolerance instrument since its last calibration?
• Have you ever recalled or reinspected product based on an OOT impact assessment? What was the situation?
• If the same instrument is found out of tolerance twice in a row, what systemic action is taken?

• Calibration certificates for at least 3 randomly selected instruments currently in use -- verify: calibration date is within the defined interval, next due date is in the future, reference standards used are identified with their own traceability certificates
• Traceability chain documentation showing the reference standards used for calibration are traceable to national/international standards (e.g., NIST, PTB, NPL) through an unbroken chain of comparisons
• Calibration interval justification records showing how intervals were determined and whether they are adjusted based on historical calibration data
• For instruments where no traceable standards exist, documented rationale for the basis of calibration used

• Calibration certificate for a digital micrometer used in production shows the reference standard serial number but no traceability certificate or evidence of the standard's own calibration, breaking the traceability chain
• Calibration interval for all instruments is set at 12 months regardless of instrument type, stability, usage frequency, or historical performance data -- no justification for uniform intervals exists
• 3 instruments found on the production floor have calibration stickers showing they are 2-5 months overdue, with no documentation that they were assessed for continued use or removed from service
• Calibration of temperature sensors is performed by comparing against a reference thermometer, but the reference thermometer's own calibration certificate has expired
• External calibration lab used for high-precision instruments is not ISO/IEC 17025 accredited, and no alternative traceability evidence is available

Randomly select 5 instruments from the production floor and inspection areas. For each, verify current calibration, traceability of reference standards, and justification for the calibration interval.

• How do you verify the accreditation scope of your calibration service provider covers the instruments they calibrate?
• How do you adjust calibration intervals based on historical performance data?
• What do you do when you discover an instrument is overdue for calibration and still in use?

• Out-of-tolerance (OOT) procedure defining the process when an instrument is found out of specification during calibration: notification, impact assessment, product evaluation, adjustment/repair, and re-calibration
• OOT investigation records for instruments found out of tolerance, including: as-found data showing the deviation, impact assessment on measurements made since the last calibration, product disposition decisions, and corrective actions
• Adjustment records showing pre-adjustment (as-found) and post-adjustment (as-left) data for instruments that were adjusted during calibration
• Impact assessment records for at least 2 recent OOT events showing evaluation of affected products and measurements

• Instrument was found 0.03mm out of tolerance during calibration, adjusted back to specification, and returned to service with no impact assessment of the products measured during the period it was out of tolerance
• OOT procedure requires impact assessment but the assessment for a recent event states 'no impact expected' without documenting what products were measured, what the measurement uncertainty was, or how the conclusion was reached
• Multiple instruments have been adjusted during 3 or more consecutive calibrations (showing consistent drift), but no investigation has been performed to determine the root cause of the recurring drift or adjust the calibration interval
• As-found data is not recorded for instruments that pass calibration within specification, making it impossible to analyze drift trends and optimize calibration intervals

Request OOT records for the last 12 months. Review at least 2 OOT events for completeness of impact assessment, product evaluation, and corrective action. Check whether any instruments have recurring OOT issues.

• How do you determine which products are potentially affected when an instrument is found out of tolerance?
• What criteria do you use to decide whether a product impact assessment requires product recall, reinspection, or no action?
• How do you track instruments with recurring OOT events, and at what point do you shorten the interval or retire the instrument?

• Calibration status identification system: labels, stickers, color-coded tags, or electronic status visible on the instrument showing calibration date and next due date
• Evidence that status identification is consistently applied across all controlled instruments (walk the floor and check)
• Procedure for handling instruments with missing, damaged, or illegible calibration labels
• Database or system that can provide real-time calibration status for any instrument by its unique ID

• Calibration label on a production floor micrometer has faded to the point where the calibration date and next due date are illegible, and the operator is unaware of the instrument's calibration status
• Several instruments checked on the production floor have no calibration label or sticker, though the calibration database shows them as current -- operators have no way to verify calibration status at the point of use
• Calibration labels show only the calibration date but not the next due date, requiring users to look up the calibration interval separately to determine if calibration is current
• For instruments too small for labels (e.g., pin gauges), no alternative identification system (engraved ID, color coding, dedicated storage with status) is used

Check calibration labels on 10 instruments across different areas (production, inspection, warehouse, lab). Verify each has a legible label showing calibration date and next due date, or an equivalent identification system.

• What do you do if an operator notices a missing or illegible calibration label on an instrument they need to use?
• How do you identify instruments that are not to be used for acceptance decisions (reference only, limited use)?
• Do you have instruments that are too small for labels? How is their calibration status identified?

• Physical safeguards on measurement equipment: tamper-evident seals on adjustment points, locked access panels, physical locks on sensitive controls
• Software/electronic safeguards: password protection on equipment settings, access control to calibration menus, audit trails for parameter changes
• Procedures defining who is authorized to make adjustments and the process for documenting authorized adjustments
• Evidence of tamper-evident seal integrity checks during calibration
• Records of any seal breakage or unauthorized adjustment incidents and their investigation

• Hardness tester used for incoming steel inspection has no tamper seal on the adjustment mechanism, and any operator can adjust the calibration without authorization or documentation
• Digital scale used for weigh-checking final product has operator-accessible calibration buttons with no password protection; the last calibration record shows the scale was found significantly out of tolerance, potentially due to accidental adjustment
• Tamper-evident seals are applied to instruments during calibration but are never checked between calibrations; several instruments have broken seals with no investigation or recalibration performed
• Automated test equipment has software settings that affect measurement results, but there are no access controls or audit trails for changes to these settings

Check 5 critical measurement instruments for safeguards against unauthorized adjustment. Verify tamper seals are intact (if used), electronic access controls are active (if applicable), and the organization has a process for investigating evidence of unauthorized adjustment.

• Are tamper seals checked between calibrations? How often?
• What happens when a broken tamper seal is discovered?
• Do your automated test systems have audit trails for measurement parameter changes?

• Storage procedures or requirements for measurement equipment when not in active use (protective cases, controlled environments, designated storage locations)
• Handling procedures for sensitive instruments during transport between workstations, calibration lab, and storage
• Maintenance schedule and records for instruments requiring periodic maintenance (cleaning, battery replacement, lens care)
• Environmental conditions in instrument storage areas (temperature, humidity control for precision instruments)
• Evidence that instruments are inspected for damage before use (pre-use checks)

• Precision micrometers and gauge blocks are stored in a general toolbox alongside production tools, with no protective cases or controlled conditions, and visible signs of surface corrosion on gauge blocks
• No handling procedures exist for a coordinate measuring machine (CMM) probe; the probe tip shows visible wear and contamination but there is no maintenance or replacement schedule
• Instruments are transported between the calibration lab and the production floor without protective packaging; calibration technician carries instruments loose in a plastic tote
• Digital instruments are stored without battery removal during extended non-use periods; several instruments have corroded battery compartments causing malfunction

Inspect instrument storage in the calibration lab, production floor, and inspection areas. Check 5 instruments for signs of damage, corrosion, or deterioration. Verify storage conditions are appropriate for the instrument type.

• What are the storage requirements for your precision gauge blocks and reference standards?
• How do you verify instrument condition before use, especially for instruments shared between workstations?
• What maintenance is performed on instruments between calibrations?