Essential Requirements in Practice: Turning Legal Text into Product Work

Essential requirements are the legal requirements your product must meet. But they do not tell you what to build. Turning them into engineering decisions, risk controls, validation criteria, and documentation is product work - and most teams do it without a system.

Most hardware teams working toward EU market access understand that their product must meet essential requirements. Fewer understand what it takes to actually satisfy them inside a product project - which requirements apply, what each one demands in terms of design, testing, and documentation, and how much engineering effort the hard ones can consume.

Every EU product directive and regulation defines its own set of essential requirements - protection goals that must be met before a product can be placed on the market. The Machinery Directive calls them essential health and safety requirements (EHSRs). The Low Voltage Directive (LVD) defines safety objectives. The Radio Equipment Directive (RED) sets essential requirements covering safety, electromagnetic compatibility, and radio spectrum use. The terminology differs. The underlying problem is the same: these requirements must be translated into design decisions, risk reduction measures, validation activities, and documentation entries throughout the project. The risk assessment identifies which are relevant. The engineering work that follows determines whether each one is actually met. And the technical file must demonstrate, for each applicable requirement, what was done and why.

This article explains what that translation work looks like in practice - how essential requirements become concrete project work, why some demand far more engineering effort than others, and what happens when this work is not managed as part of the development process. It uses machinery EHSRs as the primary worked example - because the Machinery Directive makes the relationship between risk assessment and essential requirements unusually explicit - but the same operating logic applies across EU product legislation. The article includes specific examples from the Radio Equipment Directive and Low Voltage Directive to show how the pattern translates.

Note: This article is educational. It reflects the principles described in EU product legislation, the EU Blue Guide on implementation of product rules (2022), and established machinery safety literature. It is not legal advice. The binding interpretation of EU legislation is the exclusive competence of the Court of Justice of the European Union.

If you are looking for the broader conformity assessment workflow - from identifying applicable rules through to CE marking - see EU Conformity Assessment for Machinery and Hardware Products. For the risk assessment methodology that determines which EHSRs apply, see Risk Assessment under ISO 12100.

What essential requirements are and what they are not

Every EU product directive defines essential requirements - the legal objectives a product must meet before it can be placed on the market. The EU Blue Guide states the principle clearly: essential requirements "define the results to be attained, or the hazards to be dealt with, but do not specify the technical solutions for doing so." They are protection goals, not specifications. The manufacturer decides how to meet them.

The specific requirements differ by directive, but the regulatory logic is consistent:

Machinery Directive (2006/42/EC)

The essential health and safety requirements (EHSRs) are set out in Annex I, structured in layers: General Principles (including the obligation to carry out a risk assessment and the three-step risk reduction hierarchy), Section 1 (EHSRs applicable to all machinery), and Sections 2-6 (supplementary EHSRs for specific categories such as lifting machinery or mobile machinery).

The general EHSRs in Section 1 cover the full spectrum of hazards: mechanical, electrical, thermal, noise, vibration, radiation, hazardous substances, ergonomic risks, and more. A critical principle: EHSRs are only applicable when the corresponding hazard exists for the machinery in question. Which EHSRs apply is determined by the risk assessment - not assumed in advance. Three are always obligatory regardless: EHSR 1.1.2 (principles of safety integration), 1.7.3 (marking), and 1.7.4 (instructions). The risk assessment itself is effectively a fourth indispensable obligation.

Low Voltage Directive - LVD (2014/35/EU)

The LVD defines safety objectives in Annex I. These cover protection against hazards arising from the electrical equipment itself - electrical hazards (shock, arc, fire from electrical causes), hazards generated by external influences on the equipment (mechanical, chemical, temperature), and hazards from overloads and faults. The safety objectives are less granular than machinery EHSRs, but they generate the same translation problem: the manufacturer must determine which hazards are relevant, apply appropriate standards or alternative solutions, and document how each applicable safety objective is met.

The LVD is significant because it covers a wide range of electrical equipment operating between 50 and 1,000 V AC (or 75 and 1,500 V DC) - and because the Radio Equipment Directive directly references LVD safety objectives for its own safety requirements.

Radio Equipment Directive - RED (2014/53/EU)

The RED defines essential requirements in Article 3, organised in three tiers:

• Article 3.1(a) - Safety and health protection, including protection of users and any other person. This requirement references the LVD safety objectives, meaning radio equipment must meet the same safety goals as equipment under the LVD - regardless of voltage.
• Article 3.1(b) - Electromagnetic compatibility (EMC). The equipment must achieve an adequate level of EMC - it must not cause harmful interference and must have adequate immunity to disturbance.
• Article 3.2 - Effective and efficient use of the radio spectrum to avoid harmful interference.
• Article 3.3 - Additional requirements that the Commission may activate through delegated acts - including network interoperability, privacy, fraud protection, emergency access, accessibility, and, increasingly, cybersecurity.

For product teams building connected hardware - IoT devices, wireless sensors, radio-equipped industrial equipment - RED essential requirements are where safety, EMC, and radio performance converge. A single product may need to satisfy requirements from Article 3.1(a), 3.1(b), 3.2, and one or more Article 3.3 delegated acts simultaneously.

The common pattern

Across all three directives - and across EU product legislation more broadly - the logic is the same:

1. Essential requirements are defined as protection goals, not technical specifications
2. The manufacturer must determine which requirements are relevant to their specific product - through risk analysis
3. Harmonised standards provide a recognised path to meeting specific requirements (presumption of conformity)
4. The manufacturer must document how each applicable requirement is addressed
5. The technical file captures the evidence; the declaration of conformity is the legal statement

This is fundamentally different from a specification checklist. You cannot open the directive, work through the requirements in order, and tick them off. The risk assessment defines the scope. The state of the art defines the extent. The manufacturer determines - and must defend - how each applicable requirement is met.

Why essential requirements create a translation problem

Essential requirements read like legal text because they are legal text. They are protection goals phrased as obligations - precise enough to be legally binding, but deliberately open on how to achieve them.

Consider a machinery example: EHSR 1.5.8 on noise. The requirement states that machinery must be designed and constructed so that risks from airborne noise emissions are reduced to the lowest level, taking account of technical progress and the availability of means of reducing noise. What does that mean for a product team?

It means: identifying every significant noise source in the machine, estimating or measuring noise levels at operator positions, applying the risk reduction hierarchy (reduce by design → protective measures → inform users), documenting specific measured noise values in the instructions using precise thresholds defined in the directive, and validating noise levels against the applicable measurement standard.

Or consider a RED example: Article 3.1(b) requires that radio equipment achieve an adequate level of electromagnetic compatibility. What does that mean? It means: identifying all emission sources and susceptibility paths in the product, selecting the applicable harmonised EMC standards (EN 301 489 series for radio equipment, with product-specific parts), designing the product to meet the emission limits and immunity levels defined in those standards, performing the full suite of EMC tests, and documenting the results. If the product fails a conducted emissions test at the pre-compliance stage, the team must redesign the power supply filtering or PCB layout - design changes that become increasingly expensive the later they are discovered.

A single essential requirement generates design work, measurement work, documentation requirements, and validation activities. And the documentation requirements are precise - not "mention that the machine is noisy" or "state that EMC was considered" but specific measured values, specific test configurations, and specific pass/fail criteria.

This translation chain runs for every relevant essential requirement:

Essential requirement →identify the corresponding hazard or risk → assess → determine adequate solution → select the technical approach (often guided by a harmonised standard) → create a design requirement → validate → document in the technical file

For a typical product, dozens of essential requirements may be applicable - often from multiple directives simultaneously. Each one generates its own chain of engineering decisions and evidence. Without a system for managing these chains, the translation lives in someone's head - or scattered across meeting notes, email threads, and informal conversations that are not captured in any form that would survive scrutiny.

Harmonised standards help. They translate the protection goals of essential requirements into concrete technical specifications and test methods. A team working to EN ISO 14120 for guard design, EN 62368-1 for product safety, or ETSI EN 301 489 for radio equipment EMC is following a recognised path to meeting specific essential requirements. But standards do not eliminate the translation problem. The EU Blue Guide is explicit: even when using a harmonised standard, the manufacturer must carry out the risk assessment and verify that the standard actually covers all the risks of the specific product. A standard may cover certain essential requirements fully, others partially, and some not at all. The manufacturer remains responsible for identifying and documenting those gaps.

Not all essential requirements demand the same effort

One of the most practical insights for product teams is that essential requirements are not equally difficult. The engineering effort, expertise, and documentation depth required varies dramatically across the different requirements. Treating them all the same - or tackling them in the order they appear in the directive - leads to misallocated effort: too much time on the straightforward ones, not enough on the ones that can consume months of engineering work.

The Machinery Directive makes this most visible because of the sheer number and granularity of EHSRs in Annex I. But the same principle applies under RED and LVD: an Article 3.1(a) safety assessment for a low-power IoT sensor is a different scale of work from an Article 3.2 radio spectrum assessment for a multi-band device, or a cybersecurity assessment under an Article 3.3 delegated act.

For machinery EHSRs specifically, a useful way to approach them is in four classes, based on the complexity of the engineering work and the level of risk assessment needed:

Class I - Standard solutions

These EHSRs address hazards where well-established engineering solutions exist and are widely applied. The risk assessment is straightforward, the solutions are known, and residual risks are typically negligible.

Examples include requirements on materials and products (EHSR 1.1.3), lighting (1.1.4), surfaces, edges, and corners (1.3.4), electrical supply (1.5.1), static electricity (1.5.2), and radiation emissions (1.5.9-1.5.12). For most machinery, these are handled through standard engineering practice and documented briefly.

These are not trivial - they must still be identified, addressed, and recorded. But the engineering decisions are well-understood and the documentation is concise.

Class II - Diligent assessment needed

These EHSRs address hazards where standards and established solutions exist, but the risk assessment requires genuine engineering judgement. Residual risks are common and must be communicated to users through the instructions.

Key examples: mechanical hazards from moving parts (EHSR 1.3.1-1.3.3), the combined set of moving parts, guard choice, and guard requirements (1.3.7 + 1.3.8 + 1.4 - which must be assessed together), extreme temperatures (1.5.5), noise (1.5.8), and vibration (1.5.9).

These are the workhorses of most machinery risk assessments. They require systematic hazard identification, proper risk estimation, considered selection of protective measures, and careful documentation of residual risks. The engineering effort is significant but bounded - and the applicable harmonised standards provide clear guidance.

Class III - Serious consequences possible

These EHSRs address hazards that can have severe consequences - both for people and for the environment. They may require advanced hazard identification methods such as HAZOP or FMEA, and the risk assessment must rest on a qualified technical basis.

The key examples are fire (EHSR 1.5.6), explosion (1.5.7), and emission of hazardous substances (1.5.13). For machinery that processes flammable materials, generates combustible dust, or handles toxic substances, these requirements can drive substantial engineering analysis and may interface with other EU directives - notably the ATEX Equipment Directive for explosive atmospheres.

The engineering work here extends beyond the machine itself. It may involve zone classification, ignition source assessment, ventilation design, containment engineering, and detailed substance hazard analysis linked to safety data sheets.

Class IV - Key importance, potentially quantitative

These EHSRs cover areas of central importance to machine safety - particularly control systems and maintenance - and may require quantitative risk estimation and functional safety assessment.

The critical examples are control system safety and reliability (EHSR 1.2.1), starting and stopping functions (1.2.3-1.2.4), and maintenance requirements (1.6). For control systems, the risk assessment determines the required Performance Level (PL) per EN ISO 13849-1 or Safety Integrity Level (SIL) per EN 62061. Designing, implementing, and validating safety-related control systems to the required level can represent months of specialised engineering work.

Why this classification matters for product teams: If you do not distinguish between a Class I EHSR that takes an afternoon and a Class IV EHSR that takes months, your project plan will not reflect reality. The Class III and IV requirements need to be identified and scoped early - during risk assessment, not during validation - because they carry the longest lead times and the highest potential for late-stage surprises. The same principle applies beyond machinery: under RED, an Article 3.3 cybersecurity requirement that is discovered after the firmware architecture is finalised creates the same kind of late-stage compression.

From essential requirement to engineering work: concrete examples

The translation from essential requirement to product work is easier to understand through specific examples. The following examples show how requirements from different directives generate chains of engineering decisions - from hazard identification through to documentation in the technical file.

Example 1: Moving parts and guards - EHSR 1.3.7, 1.3.8, and 1.4

These three EHSRs are assessed together because they address the same problem from different angles: moving parts create mechanical hazards, guards are the primary protective measure, and the guard requirements define what the guards must achieve.

Consider a machine with a belt-driven transmission and a rotary processing section where operators feed material.

Hazard identification. The risk assessment identifies two distinct hazards: entanglement risk at the belt-driven transmission (moving transmission parts, EHSR 1.3.7), and crushing and entanglement risk at the rotary section during manual feeding (moving parts involved in the process, EHSR 1.3.8).

Risk estimation and hierarchy. For the transmission, the severity is high (potential loss of fingers) and the probability is moderate (operators pass near it but do not normally interact with it). The three-step hierarchy is applied: can the entanglement point be eliminated by design? In this case, no - the belt drive is functionally necessary. So protective measures are required.

Guard type selection. This is where the EHSR drives a specific design decision. EHSR 1.3.7 specifies that moving transmission parts must be guarded by fixed guards or interlocking movable guards. The choice between them depends on access frequency: if the transmission requires frequent access for adjustment or maintenance, an interlocking guard is appropriate. If access is only needed during scheduled maintenance, a fixed guard - removable only with tools - is the more practical and reliable choice. The risk assessment and the operational context determine the guard type, not preference.

Standard selection. The team applies EN ISO 14120 (guards - general requirements for design and construction) and, for the interlocking guard, EN ISO 14119 (interlocking devices associated with guards). These standards translate the EHSR requirements into concrete design specifications: minimum distances from the danger zone, material strength, fixing methods, and interlock performance requirements.

Validation. The guard design is verified against the standard requirements. For the interlocking guard, the interlock mechanism is tested to confirm that the machine cannot start with the guard open and that opening the guard stops the hazardous movement.

Documentation. The technical file records: the identified hazard, the risk estimation before and after protective measures, the guard type selected and the rationale, the standards applied, and the residual risk. The instructions for use describe the guards, their function, and the procedures for safe access during maintenance.

The guard type is not a procurement decision. It is an engineering decision driven by the EHSR through the risk assessment. A team that selects guards without this chain - choosing fixed guards everywhere for simplicity, or interlocking guards everywhere for perceived safety - may end up with guards that do not match the risk profile, guards that operators bypass because they interfere with necessary access, or a technical file that cannot demonstrate why the chosen solution is adequate.

Example 2: Noise - EHSR 1.5.8

Noise is an EHSR that creates both design work and precise documentation obligations. The requirement is clear in principle - reduce noise to the lowest practicable level - but the implementation touches several engineering disciplines.

Hazard identification. The risk assessment identifies noise sources: electric motors, gear drives, pneumatic actuators, material impact points, and cooling fans. Each source contributes to the overall noise exposure at operator positions.

Risk reduction hierarchy. The three-step approach applies:

1. Design measures. Select lower-noise motor types, use helical gears instead of spur gears, isolate vibrating components from the machine frame, optimise airflow paths for cooling. These choices must be made during design - they are not available after the machine is built.
2. Protective measures. Where design measures are insufficient, apply acoustic enclosures, sound-absorbing lining, or vibration damping treatments.
3. Information. Communicate residual noise levels in the instructions, including any requirements for hearing protection.

Documentation requirements. The Machinery Directive specifies what noise information must appear in the instructions - and the thresholds are precise:

• A-weighted emission sound pressure level at workstations, where it exceeds 70 dB(A). If it does not exceed 70 dB(A), this must be stated.
• Peak C-weighted instantaneous emission sound pressure value at workstations, where it exceeds 63 Pa (130 dB relative to 20 µPa).
• A-weighted sound power level emitted by the machinery, where the A-weighted emission sound pressure level at workstations exceeds 80 dB(A).

These are not optional. They are specific measured values that must be determined by measurement according to the applicable noise measurement standard and reported in the instructions.

Validation. Noise measurement follows the applicable harmonised standards for the specific machine type. The measurements must be performed under defined operating conditions and reported with the measurement uncertainty stated.

A team that treats noise as "we will add a note about hearing protection in the manual" has not met this EHSR. The requirement demands design effort, measurement, and precise documentation - not a warning label.

Example 3: Control system safety - EHSR 1.2.1

This EHSR sits in Class IV because it can generate months of specialised engineering work - and because its scope is often underestimated.

EHSR 1.2.1 requires that control systems be designed and constructed so that they do not lead to hazardous situations. Specifically: faults in the hardware or logic of the control system must not lead to hazardous situations, and reasonably foreseeable human error during operation must not lead to hazardous situations.

For any machine with safety-related control functions - emergency stops, guard interlocking, speed monitoring, presence detection - this EHSR triggers a functional safety workflow:

Identify safety functions. Determine which control system functions perform a safety role. An interlocking guard that stops the machine when opened relies on a safety function in the control system. A speed-monitoring function that triggers a stop when the spindle exceeds a safe speed is a safety function. Each safety function must be identified and specified.

Determine the required safety level. The risk assessment determines the required Performance Level (PL) per EN ISO 13849-1 or the required Safety Integrity Level (SIL) per EN 62061 for each safety function. The required level depends on the severity of the potential harm, the frequency of exposure, and the possibility of avoiding the hazard. A safety function protecting against a fatal hazard with frequent exposure will require a higher PL or SIL than one protecting against a minor injury with infrequent exposure.

Design the safety-related control system. The safety-related parts of the control system (SRP/CS) must be designed to achieve the required PL or SIL. This involves selecting appropriate architectures (single-channel, dual-channel with monitoring, etc.), selecting components with known reliability data, and calculating the achieved safety level based on component failure rates, diagnostic coverage, and common-cause failure resistance.

Validate. The achieved PL or SIL must be verified against the requirement. This is not a simple test - it involves analysis of the architecture, component data, and failure modes, supplemented by functional testing.

Document. The technical file must contain the safety requirement specification, the design rationale, the reliability calculations, and the validation evidence.

If this EHSR is not identified and scoped during the risk assessment phase, the team discovers during detailed design or validation that safety-critical control functions require formal functional safety engineering. This is the kind of late discovery that adds months to a project - not because the requirement is unreasonable, but because the work was not planned.

Example 4: Radio equipment - RED Article 3.1(a), 3.1(b), and 3.2

This example shows how essential requirements from a different directive generate the same translation pattern - with its own complexity.

Consider a team developing a wireless industrial sensor that communicates over a 2.4 GHz radio link. The product falls under the Radio Equipment Directive. Three sets of essential requirements apply simultaneously.

Article 3.1(a) - Safety. RED references the LVD safety objectives. The team must identify all safety hazards the product can present - electrical shock from the power supply, thermal hazards from the battery or processor under load, mechanical hazards from the enclosure in its intended installation environment. For this sensor, the primary safety risks are electrical (low-voltage power supply and battery) and thermal (processor heat dissipation in an enclosed housing). The team applies EN 62368-1 (audio/video, information and communication technology equipment - safety requirements) as the harmonised standard. Testing covers insulation, temperature rise, abnormal operating conditions, and battery safety.

Article 3.1(b) - EMC. The sensor must not cause harmful interference and must have adequate immunity. The team identifies emission sources (the radio transmitter, the microprocessor clock, the switching power supply) and susceptibility paths (the radio receiver, the sensor analog front-end). They apply the relevant parts of the EN 301 489 series (EMC for radio equipment). Testing covers conducted and radiated emissions, electrostatic discharge (ESD) immunity, radiated immunity, electrical fast transients, and surge. If pre-compliance testing reveals that conducted emissions from the switching power supply exceed the limits, the team must redesign the input filtering - a PCB layout change that propagates through the design, requiring new prototypes and re-testing.

Article 3.2 - Radio spectrum. The radio module must use the spectrum effectively and avoid harmful interference. The team applies ETSI EN 300 328 (wideband transmission systems operating in the 2.4 GHz band). Testing covers transmit power, frequency accuracy, spectrum mask, receiver sensitivity, and adaptive frequency hopping behaviour. Failure to meet the spectrum mask requirement means the radio hardware or firmware must be redesigned - which can affect the antenna design, the RF front-end, and the regulatory certification timeline.

Documentation. The technical file must address all three sets of requirements, with the applicable standards identified for each, test reports demonstrating compliance, and any residual risks documented. The EU declaration of conformity must reference the RED and all the essential requirements the product meets.

The translation problem here is not the complexity of any single requirement - it is managing multiple requirement streams from the same directive, each with its own set of standards, test methods, and failure modes. A team that manages safety testing but forgets to schedule EMC pre-compliance testing discovers the problem when the test slot at the accredited lab is weeks away - and the product ships late.

What happens when essential requirements are not managed as project work

The failure modes follow a predictable pattern - and they share a common root cause: the translation from essential requirement to engineering work was not tracked.

Essential requirements identified too late. If the risk assessment happens after the design is committed, the team discovers applicable requirements when it is too late to apply the most effective risk reduction measures. For machinery, the three-step hierarchy requires that risks be eliminated by design first - but design changes are only possible while the design is open. For radio equipment, EMC performance is determined by PCB layout, component placement, and filtering design - all of which are locked early. A team that identifies an EMC problem after the PCB is in production faces a respin.

Guard selection disconnected from risk assessment. A team selects guard types based on cost or convenience rather than the risk assessment. During Notified Body review or internal audit, the technical file cannot demonstrate why the selected guard type is adequate for the identified risk. The result: redesign of guards, updated risk assessment, new documentation - all under schedule pressure.

Noise documentation missing from instructions. The machine is built and tested, but the instructions do not include the specific measured noise values required by the Machinery Directive. The gap is discovered during technical file review. Noise measurements must be performed, the instructions updated, and the technical file revised. If the instructions have already been translated and printed, the cost multiplies.

Control system safety discovered late. The risk assessment is deferred or performed at a high level that does not identify individual safety functions. During detailed design, an engineer realises that several control functions require formal functional safety assessment. PL or SIL determination, architecture design, component selection, reliability calculation, and validation are added to the project plan - compressing into a timeline that was not built for them.

Multi-directive requirements not coordinated. A product falls under both the Machinery Directive and the EMC Directive, or under RED which covers safety, EMC, and radio spectrum in a single directive. The team manages the machinery conformity work but treats EMC testing as a separate last-mile activity. When EMC testing reveals that the motor drive creates conducted emissions that exceed the limits, the redesign affects the electrical design that was already validated for safety. Requirements from different directives interact - and when they are managed in separate silos, the interactions surface late.

Residual risks not documented. The risk assessment identifies residual risks but they are not communicated through the instructions. The instructions are incomplete, the technical file is incomplete, and the declaration of conformity is issued on a weak evidence base.

No traceability. The technical file cannot demonstrate, for a given essential requirement, the chain from hazard identification through risk assessment, design decision, standard applied, protective measure, validation evidence, and residual risk documentation. Under regulatory scrutiny - from a market surveillance authority or a Notified Body - a file without traceability looks like a file assembled after the fact.

The common thread: every essential requirement that is not translated into tracked project work is a potential late-stage surprise. And the cost of each surprise increases the later it is discovered - from a design change during development, to a redesign after testing, to a product recall after market placement.

What good looks like

A well-managed essential requirements workflow has specific, observable characteristics - regardless of the tools used to manage it:

Every applicable essential requirement is identified early. The risk assessment drives this. As hazards are identified and risks are assessed, the corresponding requirements - from every applicable directive - become part of the project scope. Requirements that demand the most effort are flagged early for the additional expertise and timeline they need.

Each essential requirement is translated into trackable requirements. The protection goal becomes one or more engineering requirements - a design specification, a test criterion, a documentation obligation. These requirements are assigned, tracked, and closed out like any other product requirement.

Each requirement traces to evidence. From essential requirement to hazard, from hazard to risk assessment, from risk assessment to design decision, from design decision to standard applied, from standard to validation activity, from validation to test evidence, from residual risk to instructions for use. The chain exists and can be followed.

Multi-directive requirements are coordinated. When a product falls under multiple directives, the requirements from each are managed in a single view. Interactions between requirements - an electrical design change for safety that affects EMC performance, a radio hardware change for spectrum compliance that affects thermal safety - are visible before they cause rework.

Changes propagate. When the risk assessment is updated - a new hazard identified, a risk estimate revised, a design change that affects an existing hazard - the downstream requirements, validation plans, and documentation are updated accordingly. Nothing is orphaned.

The technical file demonstrates compliance. For each applicable essential requirement, the file shows what the hazard is, how the risk was assessed, what measures were taken, which standards were applied, how the measures were validated, and what residual risks remain. This is not a narrative assembled from memory. It is structured evidence that was built during the project.

This is structured project work. It demands the same discipline that teams already apply to product requirements, test planning, and release management. The difference is that the requirements come from legislation rather than from customers - and the consequences of gaps are legal, not just commercial. Whether you manage this work in a purpose-built conformity workflow tool or in a well-maintained set of documents, the structure must exist. The question is whether you build it deliberately or discover its absence when you need it most.

The takeaway

Essential requirements are only useful if they become tracked work inside the project. They define what your product must achieve, but they do not tell you how. The translation from legal requirement to engineering decision to validated evidence is the core of conformity work - and it must be managed, not assumed.

Not all essential requirements are equal. Some are handled in an afternoon with standard solutions. Others - control system safety, fire and explosion risks, radio spectrum compliance, cybersecurity under delegated acts - can drive months of specialised engineering and require early scoping to avoid compressing into the final weeks of the project.

The risk assessment identifies which requirements apply. The engineering team translates each one into design decisions, protective measures, and documentation. The technical file captures the evidence. And the declaration of conformity stands on that evidence. If the translation is not tracked, the evidence is not there - and the product is not ready to ship, regardless of what the project schedule says.

Read the full workflow guide: EU Conformity Assessment for Machinery and Hardware Products

Where to go deeper

• EU Conformity Assessment for Machinery and Hardware Products - The full workflow from identifying applicable rules through to CE marking
• Risk Assessment under ISO 12100 - The methodology that determines which EHSRs apply and how far they need to be addressed
• What EU Conformity Assessment Means in a Real Product Project - How conformity work maps onto your development phases