At first glance, the term “legally watertight documentation” sounds reassuring. It suggests control, stability and one thing less to worry about for those legally responsible. Technical writers frequently encounter this expectation – in project briefings, proposals or internal discussions. The topic is so widespread that we dedicated an entire episode to it in our podcast “kothes trifft …” (Note: our podcast is in German).
Our guest in that episode, lawyer Jens Heuer‑James, who has specialised for many years in product liability and product safety law, responded to the idea of “legally watertight documentation” with a clear message: There is no such thing as legal certainty in technical documentation. Full stop.
In the conversation, it becomes clear why that is the case – and why this insight can even be liberating for documentation teams. This blog post summarises and contextualises the key points from the episode.
Companies understandably want certainty when it comes to product liability. Mistakes in documentation can result in operational downtime, claims for compensation or issues with market surveillance authorities. The intuitive reaction is therefore: “Please make the documentation legally watertight.”
But this desire is based on the assumption that a single, objectively correct documentation outcome exists. According to Heuer‑James, this is the first major misconception.
The expectation that an instruction manual can be “legally watertight” is rooted in a misunderstanding of how the law works. Technical instructions follow rules, standards and clear structures. If a device is to be switched on, the manual specifies which button to press. If a component must be assembled, there are precise steps to follow.
Legal requirements, however, are fundamentally different. They define objectives, not detailed solutions. They open up interpretive space rather than narrowing it down. And they require decisions.
For technical documentation, this means:
• There is no single objectively correct text that covers all scenarios.
• There is no standard that, when followed, automatically protects you.
• There is no checklist that guarantees legal immunity.
Instead, all content must be assessed in the context of the product, its risks and its target users. The desire for legal certainty is human – but unrealistic.
Heuer‑James uses an illustrative real-world case to show why legal certainty in documentation is an illusion: On a construction site, several large wooden supports collapsed because the fastening eyes had not been screwed in correctly. The initial suspicion was that the assembly manual must have been unclear.
However, closer inspection revealed that the documentation was precise and unambiguous. The error lay not in the text but in the execution.
What makes this case so instructive is not the outcome but the reasoning behind it. The manufacturer was able to demonstrate how the manual had been developed, which considerations were taken into account and why particular wordings were chosen.
This is exactly where the term “legally watertight” becomes misleading: the expectation is not invulnerability but a traceable decision-making process. The law does not demand perfection but rather that decisions made during information development are transparent and well-founded. That is the true protective mechanism.
Many companies wish for simple rules: if all standard requirements are met and all warning notices are checked, then the documentation must surely be safe. A comforting thought – but an illusion.
Checklists only record what was done, not why it was done.
When evaluating documentation, what really matters is the underlying development process. Market surveillance authorities or expert witnesses will not only ask about the finished document but also how the organisation arrived at its content. Merely knowing the standards and owning the relevant standards documents is not enough. The crucial question is whether their principles were actively applied.
If you cannot demonstrate a structured process, you lose credibility – even if the manual looks good on the surface.
All professional documentation projects share one characteristic: manuals are not created in isolation. They are part of a larger system involving product development, risk assessment, usability, quality management and legal expertise.
Products evolve. Software is updated. Standards develop further. And users increasingly rely on digital help systems, videos or online portals rather than printed manuals.
In such an environment, the idea of something being “legally watertight” feels almost antiquated. It assumes stability, finality and immutability. Good documentation, by contrast, is dynamic. It is updated, expanded, corrected and adapted to new findings. Rigid certainty is therefore impossible by definition.
Standards, such as ISO 82079, provide important structure. They define terminology, describe principles of good instruction design and specify requirements around clarity, user focus and consistency. These standards are indispensable tools.
But they do not replace a risk analysis. And they do not relieve companies of the responsibility to decide which information is essential for the product and how risks must be communicated.
A manual that complies with a standard can still be unclear if the product’s risks were poorly assessed. Conversely, a very effective manual may deviate from the standard and still be robust from a legal standpoint.
Again, the key point: the standard itself does not protect you; the reflected use of it does.
Heuer‑James makes this clear in the podcast: A standard is a tool, not a shield. Only the combination of understanding standards, conducting risk analyses and maintaining a mature documentation process leads to solid documentation.
Another case study from Heuer‑James highlights the limits of formal completeness: A manufacturer had produced a 500‑page manual that appeared extremely thorough. But a critical warning notice was hidden on page 296, almost impossible to find.
To the manufacturer, this may have looked “legally watertight” – the warning was included. In practice, it was useless. The court ruled accordingly.
This example is almost a parable: documentation can be formally complete and still practically ineffective. That is why impact, not completeness, is the true measure of quality.
If an instruction manual can never be legally watertight, what is the goal instead?
The answer is surprisingly clear: transparent, well-founded and appropriate decisions during information development.
Good documentation is not one that gets everything right, but one whose development process can be explained. It shows that the organisation understood, evaluated and meaningfully communicated the product’s risks. This leads to more realistic expectations, higher quality and greater safety – for users and companies alike.
“Legally watertight documentation” is a myth that causes more harm than good. It leads to misguided priorities, overloaded texts and a false sense of security.
Truly robust documentation emerges from the processes that guide information creation. It is transparent rather than perfect, appropriate rather than absolute, and it grows with the product. Those who accept this work more professionally – and ultimately more safely.
By the way: If you want to understand how robust your existing documentation really is, we are happy to support you. With our "Docucheck", we review your manuals systematically and independently and provide clear guidance on where there is potential for improvement.