A GPSR risk analysis should not start with a ready-made template containing a list of random hazards. First, the product, its users and foreseeable conditions of use must be described properly. Only then can hazards, evidence and measures to reduce risk be assessed.
Why risk analysis is needed
GPSR requires that, before placing a product on the market, the manufacturer carries out an internal risk analysis and prepares technical documentation. The analysis is not an add-on prepared only at the request of an authority. It should form the basis for design decisions, instructions, warnings and other safety measures.
The importer should verify that the manufacturer has performed the relevant obligations and ensure that the documentation is available. The distributor, in turn, carries out the verifications provided for it before making the product available. The outcome of the analysis therefore affects the work of the entire supply chain, even where the manufacturer is the formal author of the document.
Step 1. Define the product being assessed
The analysis must concern an identifiable product. Start by collecting:
- name, model, type, batch or series,
- description of construction, materials and parameters,
- intended purpose declared by the manufacturer,
- all relevant variants,
- photographs of the product, packaging and markings,
- assembly, use, maintenance and disposal instructions,
- markets on which the product will be offered,
- changes compared with a previously assessed version.
If one analysis is to cover a family of SKUs, it must be demonstrated that the differences between variants do not change the hazards considered or the safety measures adopted. Otherwise, the variant requires a separate scope of assessment.
Step 2. Describe users and conditions of use
Do not limit yourself to the ideal use described in advertising. GPSR also refers to reasonably foreseeable conditions of use.
Record:
- who normally uses the product,
- whether the product may reach children, older people or people with disabilities,
- where and for how long it is used,
- with which other products it may interact,
- how it is installed, cleaned, charged or stored,
- what user mistakes are foreseeable,
- whether its appearance or packaging may encourage use other than intended.
UOKiK draws attention, among other things, to consumer groups particularly vulnerable to hazards and products whose appearance may resemble food or an object attractive to children. These elements are not universal boxes to tick. They must be considered in relation to the specific product.
Step 3. Identify hazards
A hazard is a property or situation that may lead to harm. Depending on the product, the analysis may cover hazards:
- mechanical, such as cutting, entrapment, falling or instability,
- thermal, for example burns or ignition,
- electrical,
- chemical and material,
- biological or hygiene,
- related to suffocation, ingestion or access to small parts,
- ergonomic and those arising from improper handling,
- packaging-related,
- arising from combination with another product,
- digital, where cybersecurity may affect physical safety,
- related to learning or predictive functions, where the nature of the product so requires.
A list of categories helps to begin the work, but it is not an analysis. Each relevant hazard must be linked to a scenario: what may happen, under what conditions, to whom and with what effect.
Step 4. Build risk scenarios
A practical risk record may contain:
- source of the hazard,
- sequence of events leading to harm,
- exposed user group,
- possible type and severity of harm,
- predictability of occurrence,
- existing mitigating measures,
- evidence confirming the effectiveness of those measures,
- residual risk and the decision of the responsible person.
Example: do not record only 'risk of cuts'. Specify which element may injure the user, when it becomes accessible, whether the product may be used by a child, what design solution restricts access and what evidence confirms its effectiveness.
Step 5. Establish a hierarchy of mitigating measures
A warning should not be the first response to every hazard. First, consider whether the risk can be eliminated through the design or construction of the product. Technical protective measures may then be applied, and information and instructions are used to manage risk that could not be eliminated in another way.
For each measure, record:
- what risk it mitigates,
- who is responsible for implementing it,
- where it is applied,
- how its operation was verified,
- whether it creates a new hazard,
- how it will be monitored after a product change.
The wording of a warning should follow from the analysis. An automatically generated formula without knowledge of the product may be inadequate, incomprehensible or distract attention from a more important hazard.
Step 6. Gather and assess evidence
Conclusions may be based on various sources: tests, standards, calculations, experience with similar constructions, complaint data, accident information and supplier documents.
Assess each piece of evidence for:
- match with the model and version of the product,
- scope of the hazard examined,
- date and conditions of the test,
- method used,
- competence of the issuer,
- limitations or reservations,
- whether it remains current after changes to the construction or supplier.
An absence of evidence should be visible as an absence, not hidden in an empty field. Assign an owner, a completion date and a decision on whether the product may proceed to the next stage.
Step 7. Approve the outcome and keep a version
A risk analysis should have an author, date, version number and approving person. Approval means a conscious decision based on the information indicated, not an automatic calculator output.
Do not overwrite the previous file. A new version is needed, among other things, after:
- a change of material, construction or component,
- a change of supplier affecting product characteristics,
- expansion of the user group or manner of use,
- placing the product on a further market,
- a change to instructions or warnings,
- receipt of information about an accident, complaint or new hazard,
- a change in relevant requirements or state of knowledge.
The revision history should show what was changed, why, on the basis of which source, and who accepted the new outcome.
Example working table
In a simple tool or system, fields may be maintained for each risk:
- risk identifier,
- SKU and product version,
- predictable scenario,
- exposed user,
- consequence,
- input evidence,
- mitigating measure,
- evidence of effectiveness,
- status and action owner,
- final decision,
- number of the approved revision.
The value of such a structure lies in preserving dependencies. When an instruction or report changes, it is clear which risks and decisions require review.
What risk analysis does not do automatically
- It does not replace required laboratory tests.
- It does not determine on its own which sector-specific rules apply to the product.
- It does not turn incomplete supplier data into reliable evidence.
- It does not transfer responsibility to the software supplier.
- It is not a certificate or official confirmation of safety.
A tool can organise data, questions, evidence and revisions. The assessment of the adequacy of the material and the decision on the product are made by a person with the appropriate context and competence.
Check before closing the analysis
- Does the scope clearly identify the product and its version?
- Have intended and reasonably foreseeable use been taken into account?
- Have groups particularly vulnerable to hazards been considered?
- Does each relevant risk have a described scenario and mitigating measure?
- Does the evidence relate to the actual product variant?
- Are the instructions and warnings consistent with the outcome of the analysis?
- Are known gaps explicit and assigned to a responsible person?
- Can the approver reconstruct the basis for the decision?
If the answer to any question is negative, the analysis requires further work. It is better to keep a visible 'to be completed' status than to create an appearance of completeness.