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.

Strict Constraint

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.

Best Practice

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.

---

Recap: Process Documentation and Retention Requirements

Process/Record Type	In-Scope Condition	Mandatory Document(s)	Retention Requirement	Critical Action/Rule
Product Realization Process	Alters form, fit, function, or generates validation/release data.	DHF, DMR, DHR	Product lifecycle + 2 years minimum	Control process; outsourced processes must be in-scope.
Safety-Critical Process/Component	Always.	All associated records (DHF, DMR, DHR)	Indefinitely (best practice)	Include and control.
Design Transfer to Production	Production start conditional on complete design transfer.	DMR (approved BOM, manufacturing files, SOPs)	Product lifecycle + 2 years minimum	Pause production if documentation (e.g., assembly instructions) is missing.
Device History Record (DHR)	For every manufactured unit/batch.	DHR (serial numbers, test logs, rework notes)	Product lifecycle + 2 years minimum	Create at time of build; digitally sign at creation (no backdating).