Skip to content

1.1 QMS scope, process map & mandatory records

A Quality Management System (QMS) functions best when it has clearly defined boundaries. Without a well-understood scope, the QMS can easily expand into an administrative burden that slows down the team. We define these boundaries not just to satisfy external auditors, but to focus our engineering and quality resources on areas that actually prevent failures. Generally, if a process affects product safety, reliability, or regulatory compliance, it should be controlled within the QMS. Conversely, if a process does not impact the physical product or user risk, it is often best left outside the formal system to preserve operational agility.

When determining the scope of your QMS, it is helpful to base the boundary on risk and direct product impact. There is generally no need to encompass the entire organization if certain departments have no bearing on production quality.

In-Scope vs. Out-of-Scope Considerations:

  • When a process alters the form, fit, or function of the device—such as PCB layout, firmware commits, or supplier selection—that process needs to be controlled and is considered In-Scope.
  • Whenever a process generates data that is used for product validation or final release, like QA testing or metrology, it should be treated as In-Scope.
  • Purely administrative functions, such as payroll, finance, or general office management, do not impact product quality and are therefore Out-of-Scope.

Pro-Tip: Be careful not to exclude outsourced processes from your scope. Even if a Contract Manufacturer builds the PCBA on your behalf, your management and oversight of those outsourced processes must remain a controlled part of your QMS.

The process map (interaction of processes)

Section titled “The process map (interaction of processes)”

The QMS is essentially a system of linked processes. Think of it as a continuous chain where the outputs of one step must directly meet the input requirements of the next step.

  1. Input (Requirements): The process begins when market needs and user requirements are converted into System Requirements Specifications (SRS).
  2. Transformation (Realization):
    • Design Control: This phase converts the SRS into actionable Technical Specifications, such as Gerbers, schematics, and the Bill of Materials (BOM).
    • Production: The manufacturing team then converts those technical specifications into the physical goods.
  3. Output (Delivery): The verified, finished product is delivered to the customer.
  4. Feedback (Loop): Finally, field data from RMAs and customer complaints feeds back into the design inputs to inform the next product revision.
  • A crucial rule of process linkage is that production should only begin when the design transfer is complete. For example, if assembly instructions are missing, production should pause until the documentation is ready, rather than relying on unwritten assumptions.
  • Similarly, a well-linked QMS ensures that if the non-conformance rate climbs above a defined threshold, the Corrective and Preventive Action (CAPA) process is initiated to investigate and resolve the issue.

Records are the documented evidence that our processes are working as intended. They are essential for enabling effective Root Cause Analysis (RCA) months or even years after production. Proper documentation ensures traceability and protects the integrity of the product batch.

  • DHF (Design History File): This answers why we built it. It contains the SRS, risk analyses, and documented design reviews.
  • DMR (Device Master Record): This defines what we build. It contains the approved BOM, manufacturing files like Gerbers, and standard operating procedures (SOPs).
  • DHR (Device History Record): This proves how we built a specific unit or batch. It contains the actual serial numbers, test logs, any rework notes, and relevant date codes.
  • As a standard practice, records should be retained based on the product’s expected lifecycle. For example, if the product lifecycle is 5 years, plan to retain the records for at least 7 years, or as required by local regulations.
  • For records pertaining to safety-critical components, it is often best practice to retain them indefinitely to ensure historical traceability.

Pro-Tip: Always digitally sign records at the moment of creation. Retroactive signing, or backdating, compromises the integrity of the data and can invalidate the record during an audit.

Final Checkout: QMS scope, process map & mandatory records

Section titled “Final Checkout: QMS scope, process map & mandatory records”
Control PointCritical RequirementGuiding Principle
Scope BoundaryExclusions must be justified (e.g. “We do not offer servicing”).Do not claim a “Design” exclusion if you modify firmware.
Process InteractionOutputs of Step A must fulfill the Inputs of Step B.Ensure clear, structured handoffs between departments.
DHR IntegrityFull traceability down to the component lot level.A unit missing a serial number cannot be verified.
Record RetentionRecords should be retrievable within a reasonable timeframe.Verify the integrity of digital backups periodically.
Change ControlMaintain revision history on all DMR documents.Avoid uncontrolled informal changes on the floor.