A Minimum Conformity Assessment Workflow for a Small Product Team

Imagine a six-person hardware team. The mechanical engineer keeps the risk assessment. The product lead has the lab quotation. The controls engineer knows why a safety function changed. The technical file contains whatever someone remembered to copy into it.

Everyone is doing useful work. The difficulty starts when someone asks whether the product is ready.

That question requires information from all four places, plus the relationships between them. Which risk prompted the change? Which requirement did it satisfy? Did the test cover the new version? A small team can spend an afternoon answering a question it thought it had already answered.

This hypothetical team needs a shared way to preserve those connections. The workflow below starts with five records and a short review inside the project meeting the team already holds.

“Minimum” describes the coordination system. It does not reduce the legal requirements, engineering depth, or specialist competence your product needs. For the full process, see the EU conformity assessment guide.

Start with one product and one accountable coordinator

Choose a current product. Define the configuration, intended use, and target markets. If it is an existing programme, begin with the latest controlled design and record what still needs reconstruction.

Name a coordinator who keeps the work connected and the dependencies visible. That person may be the product lead or an engineer. They do not become qualified to decide every safety question by being appointed. Identify the competence needed for the assessment, design, testing, and review; obtain external help where the team lacks it.

Agree who can authorise engineering decisions and who reviews release readiness on the manufacturer's behalf. Document it in a few lines. A small team benefits from explicit responsibility precisely because several roles may belong to the same person.

Keep five connected records

These are logical records, not a requirement to create five files. They can live in a shared system or controlled documents. What matters is that the team can find the current information and follow the links.

1. Product scope and rules

Record the product boundary, intended use, foreseeable use conditions, relevant legislation, assessment procedure, standards and editions, and open applicability decisions. Include the planned placing-on-the-market or putting-into-service timing where a regulatory transition matters.

Make the uncertainty visible. If a product category or system boundary needs specialist review, give that decision an owner and date. An unresolved applicability question is work to plan.

For machinery, the Directive article explains the scope and assessment route. The Commission's machinery guidance also links to application guidance and the current legislation.

2. Risk assessment

Record the relevant tasks and lifecycle phases, hazardous situations, risk estimates and evaluation, selected reduction measures, remaining risks, and the reasoning behind the conclusions. Identify the design version assessed.

Keep a stable identifier for each scenario. “R-014: access during jam clearing” is useful because a design requirement and a test record can refer to it even when the assessment is revised.

For machinery, follow an appropriate risk assessment methodology rather than inventing one from this article. The ISO 12100 resource explains the established sequence, and ISO's standard page identifies the standard itself.

3. Requirements and engineering actions

Translate applicable requirements and risk measures into engineering work. Each item needs its source, owner, implementation reference, and acceptance criterion.

Separate progress from acceptance. An engineer can complete a guard drawing while the corresponding safety requirement remains open pending validation. Recording that difference prevents “design done” from silently becoming “risk resolved.”

The source may be an essential requirement, a standard clause, or a risk reduction measure. One engineering requirement can address several sources, and one source can require several engineering actions. Preserve those relationships without duplicating conflicting copies of the same requirement.

4. Validation and evidence

For each requirement needing verification or validation, record the method, acceptance criteria, responsible person, sample configuration, results, and report location. Plan the method before the test.

An inspection, calculation, or design review may be appropriate evidence for some requirements. Others need measurement, testing, or a prescribed external assessment. Decide on the method from the actual requirement, risk, and applicable procedure.

When a test fails, connect the finding to the engineering action and affected risk assessment. When it passes, retain the conditions and configuration. A result without those details becomes difficult to reuse responsibly.

5. Technical documentation and release record

Maintain an index of the evidence package as it grows: scope decisions, risk assessment, design information, standards, reports, supplier information, instructions, and the required declarations or assessment outputs.

The index should tell a colleague where the controlled record is, which product version it covers, and who maintains it. Establish access, backup, and retention. A link to a private folder is a fragile archive.

For machinery, the required technical-file contents are specified in Annex VII of the Machinery Directive. For products under the new regulation, technical documentation is addressed in Annex IV of Regulation (EU) 2023/1230. The index helps organise that work; the legislation determines what must be present.

Follow one issue through the whole system

Take an illustrative packaging machine with an access door near moving parts. The risk assessment identifies possible injury during jam clearing. The team assesses the task and determines an appropriate combination of design and protective measures.

The resulting record might look like this:

This is a traceability example, not a safety specification. It does not prescribe the required control-system performance or a stopping-time limit. Those decisions require the actual risk assessment and applicable technical requirements.

Now imagine the team changes the drive. The connection gives them a starting point: review whether the change affects R-014, REQ-028, the implementation, or the existing validation. The team can record why evidence remains applicable or commission additional work. They no longer have to begin by searching for whoever remembers the original decision.

Use a short weekly review to inspect the connections

Reserve a short slot in the existing project review. Its purpose is to make decisions and expose dependencies, not to read every record aloud.

Cover four questions:

1. What changed? Review design, software, supplier, intended-use, and relevant standards changes for their conformity impact.
2. What remains uncertain? Give unresolved applicability, risk, and acceptance decisions an owner and next step.
3. What evidence is now available? Review results before closing the associated requirement or risk measure.
4. What could change the schedule? Identify redesign, test capacity, external assessment, instructions, and documentation dependencies.

The coordinator updates actions and dates. The competent owner makes the technical judgement. Significant changes may require a dedicated review before the next meeting; a weekly rhythm is not a reason to postpone urgent safety work.

Put evidence at the existing project gates

Use the team's normal development gates to check whether conformity work is keeping pace:

These are suggested management gates, not new legal approval stages. Their value is that they force expensive dependencies into view while the team can still respond.

A design gate can proceed with defined open engineering work if that is appropriate to the project. A release decision has to satisfy the applicable obligations. Do not confuse permission to continue developing with permission to place a product on the market.

Set up the first version this week

Start with the scope record and the latest risk assessment. Establish identifiers and connect the highest-consequence open issues to engineering owners and planned evidence. Create the documentation index using records you already have.

Then trace one issue from beginning to end with a colleague. If they cannot follow the path, improve the connections before expanding the system. Repeat for the remaining applicable requirements and risks.

A controlled spreadsheet can support a simple product if the team maintains versions, ownership, and links reliably. As contributors, variants, and changes multiply, the maintenance burden grows. That is a practical reason to consider a dedicated workflow system: the need to keep decisions and evidence connected across the product's life.

To check your starting point, use the late-stage compliance risk checklist. It will show which records you can already demonstrate and which need work.

Sources and scope

This workflow was reviewed on 8 October 2026. The five-record structure and meeting rhythm are Normio's practical recommendations; they are not a prescribed conformity assessment procedure. Product-specific requirements and competent assessment still determine the work.

• Machinery Directive 2006/42/EC, consolidated text — Article 5 and Annex VII.
• Machinery Regulation (EU) 2023/1230, consolidated text — manufacturer obligations and technical documentation.
• ISO 12100:2010 — machinery risk assessment and risk reduction methodology.