Workplace accident on the production line: how to manage the crisis and avoid increasing liability after modifying a machine

An accident on a production line very quickly stops being just a workplace safety incident. In practice, it also becomes a test of the plant’s technical maturity, the quality of its change management, and the completeness of its machine documentation. What happens next is rarely determined solely by the moment of injury. Much more often, the outcome depends on what the plant can demonstrate a few hours and a few days later: what condition the machine was in, who introduced changes and on what basis, whether technical evidence was preserved, and whether the documents actually describe the system that was operating at the time of the incident.

This also has practical significance when the machine or line had previously been modified. After an accident, the same question returns: was it still a repair or an operational adjustment, or had it already become a substantial modification that shifts the user toward responsibility normally assigned to the manufacturer. From the same perspective, the plant must assess minimum requirements audits, EU declarations of conformity, operating instructions and the full technical documentation, if it has in fact shaped the technical solution. That is why a crisis management procedure cannot end with securing the scene. It must lead to one clear answer: does the organisation have control over the technical condition, the documentation, and the decisions that led to the machine operating in that specific configuration.

The first hours after the incident

In the first hours after an accident, the most important thing is to define the problem correctly. The plant is no longer dealing only with a failure or only with an accident investigation. It is facing a technical, evidential, and management crisis at the same time. This distinction helps set priorities: first, people’s safety and stabilising the scene; then protecting technical evidence and data; and only after that making decisions about restoring operations.

At this stage, the greatest damage is often caused by reflex actions. Someone moves components, resets the control system, clears alarms, starts the machine “just for a test,” or tries to reconstruct the sequence of events from witness memory. Meanwhile, the most valuable information is still stored in the controller, the operator panel, alarm logs, the vision system, cameras, and the access history for the area. Later findings can still be corrected. Lost technical evidence usually cannot be recovered.

That is why, in the initial phase, the response should not be handled like a fault-removal team but like a team organising a technical investigation. In practice, this means separating roles and stopping decision-making chaos. One person should be responsible for safety at the scene and access control, another for a consistent flow of information, another for contact with the supplier’s service team, and another for securing documentation and making copies of data from control and supervisory systems. Without this, it is easy to end up in a situation where the service team connects to the machine remotely and overwrites the fault history, maintenance restores power, and production management simultaneously pushes for a partial restart.

The as-found condition has the greatest value before the workstation is “put in order.” The machine therefore needs to be viewed not only through the damage itself, but also through its actual safety configuration and method of operation. What matters are the position and condition of guards, the operating mode set on switches, any bypasses of protective functions, the condition of sensors and actuators, setpoint parameters, the history of changes to the controller program, entries in the maintenance system, and the most recent service interventions. Witness statements are necessary, but they are only supplementary: after an incident, memory is often incomplete and distorted by stress.

From an operational standpoint, the answer to how far the machine may be interfered with after the incident is simple: only to the extent necessary to rescue people, remove the immediate hazard, and secure the area, while documenting every change. Any test run, guard removal, alarm reset, or component replacement before the as-found condition has been recorded should be treated as a high-risk decision.

• protect people and isolate the incident area without restoring machine operation,
• record the as-found condition: photographs, component positions, panel indications, alarms, and messages,
• make data copies and stop remote and local access that could overwrite the history,
• appoint a single owner for decisions on stopping or partially resuming operations.

Only after the facts have been organised in this way can the discussion move on to compliance and liability. Only then is it possible to assess reliably whether the machine was used as intended, whether the required level of safety was maintained after modifications, and whether there is current evidence of conformity assessment, complete technical documentation, and operating documents that match the actual condition. This is also the point at which it must be decided whether the plant remains only a user, or whether the scope of the changes has already moved it into the role of the entity responsible for the technical solution.

Where cost and liability really increase

After an accident, the real risk often stems not from the event itself but from the history of earlier technical decisions. In practice, the biggest problems are rarely caused by a machine operating in its original factory condition. Much more often, the dispute centers on an added feeder, a replaced gripper, modified control logic, a bypassed guard, integration with another workstation, or a change in operating mode introduced under output pressure. From a production perspective, such interventions may seem reasonable. After an incident, however, what matters is not the intention but whether the organisation can demonstrate the design basis for the change, the course of the machine risk assessment, the selection of protective measures, and who approved the solution for operation.

This is exactly where the question of a substantial modification arises. The issue is not who physically repaired or altered the machine. What matters is whether the scope of the changes was broad enough that the plant ceased acting solely as a user and assumed responsibilities normally assigned to the party responsible for the technical solution. This boundary is easiest to miss when changes are spread across maintenance, automation, process engineering, and production, and each one on its own looks like a minor adjustment. The nature of the change is not determined by its internal label, but by its actual impact on the machine’s function, control method, hazardous zones, operating sequence, conditions for human intervention, and foreseeable operator errors.

In practice, this pattern is often repeated. To reduce downtime, the sequence of actuator movements is changed locally, a part-presence sensor is added, and operation with an open guard is allowed in setup mode because the operator needs to see the process. After some time, the solution becomes standard daily practice. When an accident occurs, no one can clearly identify who approved the change, what safety assumptions were adopted, whether the protective functions were checked after the modification, whether personnel were trained, and whether the instructions reflect the actual condition. At that point, the cost rises sharply not only because the line is down, but because the plant loses a coherent technical basis for its defence.

In cases like this, what matters is not verbal assurances but evidence of change management. If that evidence is missing, every subsequent answer becomes ad hoc and open to challenge.

• a change request describing the purpose, scope, and impact on safety,
• technical approvals and a clear indication of responsibility for release to operation,
• results of tests, acceptance checks, and verification of protective measures,
• updates to instructions, energy isolation procedures, and training records.

The second axis of risk concerns the relationship between minimum requirements for machines in use and the obligations that may arise after a rebuild, integration, or recommissioning in a modified configuration. The argument that a machine has been operating for years does not replace evidence from audits, compliance reviews, and a current assessment of the configuration in which it is now being used. The manufacturer’s original EU Declaration of Conformity may still be relevant, but it does not automatically answer whether, after a line rebuild or a change in control logic, it still describes the actual condition. That is why, after an accident, it is necessary to determine precisely whether the case involved a repair or a substantial machine modification, and whether the analysis concerns a single machine or a line as an assembly of machines.

Decisions that bring order to the situation

Once the incident has been brought under control, the first question should not be how quickly production can be restarted. The priority is to establish the logic by which further decisions will be made. In practice, this means reviewing three layers in parallel: the machine’s actual technical condition, the completeness and consistency of the documents, and the history of design, control, and organisational changes. Only this approach provides a sound basis for a reliable risk assessment.

If even one of these layers is missing, the team sees only part of the picture. The failure itself does not yet explain whether the technical solution failed, the method of use was at fault, or an earlier modification had consequences that were never formally assessed. For the same reason, a shutdown decision should not always be limited to a single workstation. If the same protective measures, the same control architecture, or a similar change exists elsewhere on the line, the scope of the stoppage should be defined more broadly before a secondary incident occurs.

At management level, questions about operation must also be separated from questions about compliance. First, it must be established in what role the organisation stands in relation to the machine or assembly of machines. If it remains the user, it must demonstrate at a minimum that it has the documents supplied with the machine and evidence of safe operation in the current working arrangement. If, however, the extent of the rebuild, integration, or change in operating logic shifts it toward the role of the actual manufacturer, the expected level of justification increases significantly. In that case, more complete technical documentation is needed to explain the adopted safety solutions, the selection of protective measures, test results, and the basis for the risk assessment used.

A simple document assessment matrix is useful: the document exists, is up to date, is inconsistent with the actual condition of the machine, or is missing. This split quickly shows whether the issue is purely formal or whether it means control over the technical solution has been lost. In practice, a few basic questions need to be answered: is there an EU declaration of conformity and does it relate to the current configuration, has the operating manual been updated after the changes, are schematics, lists of safety components, test records, results of minimum requirements audits, inspection records, energy isolation records, and training records available. The absence of a single document does not always mean the machine must be permanently shut down, but if several key pieces of evidence are missing at the same time, it usually means the plant cannot justify either the way the machine was operated or the decision to restart it.

• EU declaration of conformity and operating manual — do they describe the machine’s current condition,
• schematics, risk assessment, acceptance and test records — do they justify the protective measures applied,
• change log, audit results, inspection records, and training records — do they confirm safe operation after the modifications.

A common mistake is to treat removal of the damage as removal of the cause. Replacing a light curtain, guard interlock, or safety module does not close the matter if it is not known why the safeguard stopped performing its function or why the plant allowed operation under changed conditions. Returning to operation therefore requires not only repair, but also proof that both the technical and organisational causes have been removed and that the adopted method of use matches the current condition of the machine, the control system, and the protective measures.

In some cases, it is enough to bring operation back under control and verify the protective measures before restart. In others, a broader review of the entire machine assembly, an external audit, or a more complete conformity assessment will be necessary, especially where the changes affected safety functions, interacting systems, or equipment subject to separate technical regimes, such as pressure installations. From a standards and compliance perspective, the key point here is not to multiply legal bases, but to be able to demonstrate due diligence in the conformity assessment and operation of the machine.

How to avoid repeating the same accident

The most valuable lesson after an accident rarely concerns a single operator error. It usually reveals how the organisation makes decisions about technical, organisational, and software changes. If the impact of a change on safety is checked only after implementation, the next incident does not have to happen on the same machine. It will recur elsewhere on the line, with a different team, and under a different project name.

That is why closing the crisis is not about adding one more prohibition to the manual. It is about redesigning the decision-making rules: who may request a change, who determines its impact on protective measures, who is responsible for the risk assessment, and who formally authorises continued use of the machine. This is the essence of change management. This is where it is decided whether the plant is actually learning from the incident or merely creating the appearance of a response.

In practice, what is needed is a simple model applied without exceptions. Every technical change should go through the same sequence: classification of its impact on safety, identification of the decision owner, definition of the required tests and acceptance steps, update of the documentation, and formal approval for use. This is not about expanded bureaucracy, but about a decision trail that can be reconstructed a month later and after an accident. If the modification covers the control system, fencing, hazardous area, machine interaction logic, or the way people intervene in the process, it must not be treated as an ordinary repair.

After an incident, it also becomes immediately clear whether machine safety in minimum requirements audits was a real tool for controlling operating conditions or merely an archived form. Good audits make it possible to answer quickly which guards and protective devices should be on the machine, what deviations had previously been identified, who accepted them, and whether corrective actions were closed out. Weak audits end in general statements with no evidential value. That is why, after an accident, it is worth going back not only to the place where it happened, but also to similar modifications across the plant and checking whether the same decision-making mechanism exists more widely.

A separate source of problems remains the relationship with suppliers, integrators, and service providers. External support may be technically necessary, but it does not transfer responsibility for what ultimately operates in the plant. If the organisation cannot clearly establish what was changed, who approved the scope of work, what the contractor’s limits of responsibility were, and whether the documentation was handed over in a usable condition, then after an accident it is left without its own decision basis. At that point, the most difficult question returns: is the user still only a user, or, because of the scope and manner of the changes introduced, has it become the party responsible for the technical solution and therefore required to hold not only user documentation, but in practice more complete documentation appropriate to the adopted solutions and the responsibilities associated with the manufacturer’s role.

The final conclusion is straightforward. After an accident, the advantage comes not from the speed of declarations, but from the quality of the evidence and disciplined decision-making. These factors determine whether the crisis is contained to a single incident and one shutdown, or turns into a long-term problem of liability, disputes over the scope of changes, and further downtime. An organisation that can demonstrate a logical sequence—change, qualification, test, documentation update, formal approval for use—has a real basis for its defence. An organisation that relies on people’s memory and the assumption that it was only a minor modification ends up facing the same type of accident again, even when it does not recur in exactly the same form.