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. These boundaries are defined not just to satisfy external auditors, but to focus 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.

Determining QMS scope

When determining the scope of the QMS, the boundary must be based 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: Outsourced processes must not be excluded from the scope. Even if a Contract Manufacturer builds the PCBA, the management and oversight of those outsourced processes must remain a controlled part of the QMS.

The process map (interaction of processes)

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

Core architecture

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.

Linkage rules

• 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.

Mandatory records (evidence of control)

Records are the documented evidence that the 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.

Traceability hierarchy

• DHF (Design History File): This answers why the product was built. It contains the SRS, risk analyses, and documented design reviews.
• DMR (Device Master Record): This defines what is built. It contains the approved BOM, manufacturing files like Gerbers, and standard operating procedures (SOPs).
• DHR (Device History Record): This proves how a specific unit or batch was built. It contains the actual serial numbers, test logs, any rework notes, and relevant date codes.

Retention policy

• As a standard practice, records should be retained based on the product’s expected lifecycle. For example, if the product lifecycle is 5 years, records must be retained 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: Records must always be digitally signed 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

Control Point	Critical Requirement	Guiding Principle
Scope Boundary	Exclusions must be justified (e.g. “Servicing is not offered”).	A “Design” exclusion must not be claimed if firmware is modified.
Process Interaction	Outputs of Step A must fulfill the Inputs of Step B.	Clear, structured handoffs must be ensured between departments.
DHR Integrity	Full traceability down to the component lot level.	A unit missing a serial number cannot be verified.
Record Retention	Records should be retrievable within a reasonable timeframe.	The integrity of digital backups must be verified periodically.
Change Control	Revision history must be maintained on all DMR documents.	Uncontrolled informal changes on the production floor must be avoided.