Standards • hazards • methodology

Standards Database and ISO 12100 Methodology
one shared language for risk, audits, and decisions

In machinery safety, a form is never enough. The team also has to speak the same language: machine life phase, task, hazard source, hazardous situation, possible event, and harm. Safety Software helps you maintain a standards database plus a catalogue of terms and scenarios built on ISO 12100 methodology, so the team has a clear reference point when assessing risk or comparing machines across the fleet.

Bring order to your methodology See what the standards database gives you
Standards Database and ISO 12100 Methodology

If everyone describes hazards in their own language, the report only looks right on paper.

In risk assessment and machinery audits, it is not enough that someone spotted the issue. What matters is whether they can describe it in a comparable way: which machine life phase, which task, which hazard source, which hazardous situation, which event, and what harm could result.

A standards database and a hazard catalogue built on ISO 12100 logic do not replace the content of standards or the expert’s responsibility. What they do is keep the terminology under control, so the team does not turn risk assessment into a pile of free-form comments.

For companies that want risk assessments and audits to stay comparable across people, machines, and projects

Expert authority comes from disciplined decisions, not a long list of standard numbers.

A standards database and hazard catalogue help the team use the same categories, tasks, and terminology in risk assessment and audits of existing machinery.

ISO 12100
hazard -> situation -> event -> harm logic as a shared working model
▲ UP
Standards B/C
reference point for protective measures, validation, and documentation
▲ UP
Team language
fewer random descriptions across multiple auditors and projects
▲ UP

What does the standards database and ISO 12100 methodology bring under control?

Standards assigned to the project
Each machine project can carry its own set of standards and reference points to support the choice of protective measures, documentation requirements, and verification approach.
Hazard sources and harm
A hazard catalogue built on ISO 12100 logic helps describe hazards in consistent categories instead of mixing mechanical, electrical, thermal, and organisational issues in one text field.
Life phases and tasks
Transport, installation, cleaning, changeover, jam clearing, service, and dismantling can be treated as real risk context instead of an afterthought at the end of the report.
Technical decision in context
Shared categories help keep the link intact between the observation, scenario, risk, recommendation, and risk reduction measure.
risk_scenario:
  source: moving_part
  task: jam_removal
  situation: access_to_zone
  event: unexpected_start
  consequence: hand_injury
One shared risk language

The same problem should be recognisable across different projects.

If one person writes “missing guard”, another “contact with motion”, and a third “risk of hand injury”, the system ends up with three descriptions but not necessarily one clear picture of the issue. In a larger machine fleet, that kind of freedom makes risk comparison painful.

A catalogue of concepts helps describe the scenario using one consistent pattern: hazard source, hazardous situation, event, possible harm, and task context.

  • fewer free-form comments in audits
  • easier comparison of findings across machines
  • clearer reports for engineers and decision-makers
Standards as the reference point

A standard in the system should not decorate the report. It should drive the decision.

Type A, B, and C standards help structure requirements, but in real projects they are often treated like a list tacked onto the end of the documentation. Then it becomes hard to show which standard actually supported a specific protective measure.

Safety Software lets you use standards as part of project work, recommendations, and verification, not just as the bibliography at the end of the report.

  • standards linked to the project and documentation
  • reference point for protective measures and recommendations
  • clearer conversations with the client, integrator, or auditor
standard_context:
  type_a: EN_ISO_12100
  type_b: EN_ISO_13857
  type_c: machine_specific_standard
  use: decision_reference
  output: consistent_report
boundary:
  software: structured_methodology
  expert: interpretation_and_decision
  standards: external_reference
  compliance: not_automatic
Legal and expert boundary

The standards database supports expert work. It does not replace it.

The application does not replace the current content of standards, the right to use standards, expert interpretation, or the manufacturer’s responsibility. Its value is in structuring the work and keeping one shared language inside the system.

That alone is a strong sales argument: the company stops relying entirely on one specialist’s memory and loose spreadsheet notes.

  • no promise of full compliance with standards
  • the tool supports methodology but does not replace expert judgement
  • the organisation remains responsible for the currency and interpretation of standards

What does a mature working methodology actually show?

The point is not to stuff the report with standard names. The point is to connect standards, an ISO 12100-based hazard catalogue, and technical decisions.

Problem in the team’s workflow
How Safety Software brings order
Free-form descriptions
Each specialist uses different names for similar hazards and tasks.
A catalogue of hazards, sources, tasks, and harm helps keep terminology aligned.
Standards at the end of the report
Standards are listed in general terms, with no link to the technical decision.
Standards can be maintained as a reference point for the project, protective measure, and documentation.
No comparability
An audit across multiple machines produces a list of comments, but priorities are hard to compare.
A common language makes it easier to compare findings, risks, and recommendations across the machine fleet.
Unclear methodology
The report shows the result, but not always how the team arrived at the decision.
The methodology keeps the chain intact: task, hazard, situation, event, harm, risk, and measure.

The difference is not having a list of standards. The difference is using them inside the process.

A standards database and hazard catalogue only matter when they help with day-to-day risk descriptions, audits, and documentation, not just the “applied standards” section.

Spreadsheet Standards list Safety Software
Project-linked standards Partly Partly, in a cell Yes Yes, as a list Yes Yes, as project context
Hazard catalogue Partly Partly, manually Partly Partly, as plain text Yes Yes, as a structure
Life phases and tasks Partly Partly, as a section Partly Partly, as a checklist Yes Yes, as risk context
Audit comparability None None, descriptions are arbitrary Partly Partly, manually Yes Yes, shared language
Responsibility boundary None Unclear Partly Partly described Yes Yes, without overpromising
Yes Partly None

Frequently asked questions about the standards database and ISO 12100 methodology

Does the standards database replace buying standards?
No. Safety Software does not replace the official content of standards or the right to use them. The module helps maintain a reference point, a working structure, and consistent language throughout the risk assessment and audit process.
Does the module guarantee compliance with ISO 12100?
No. The system supports the methodology and a structured description of scenarios, but whether an assessment is compliant depends on the team’s competence, current standards, machine data, and the decisions made by the manufacturer or integrator.
Is the standards database only for risk assessment?
Its main role is to support risk assessment, but the same language also helps with audits of existing machinery, recommendations, and comparison of findings across the machine fleet.
Why is this different from a simple form?
Because the system supports the way experts actually work: shared categories, standards, tasks, life phases, and technical decisions. That is a lot more than text boxes in a spreadsheet.

Build a shared risk assessment language across your team.

Keep standards, the hazard catalogue, tasks, life phases, harm, and ISO 12100 methodology in one process instead of relying on free-form spreadsheet descriptions.

Build a shared risk assessment language across your team

The best place to start is a project or audit where several people need to describe risk in the same language.

Practical articles on risk assessment, machinery directives and compliance — supporting this product page.