Data quality as a compliance factor is a topic that is on the agenda in many technical writing departments right now. Here is what really matters in practice, beyond marketing claims and tool promises.
It sounds unspectacular: a wrong weight in a product database. A few kilograms off, somewhere in a system nobody has thoroughly checked in a long time. And then comes a fine in the millions. Not because of gross negligence, not because of a strategic decision. But because of a data slip that could have been prevented systematically.
I have spoken on this topic at several industry conferences, and every time the reaction in the room is the same: first a slight nodding — „yes, I know that“ — and then a curious silence in which the listeners evidently start to calculate whether it could happen to them too.
The answer in most cases is: yes.
Why data quality is not an IT problem
The first misunderstanding I regularly encounter is this: data quality is treated as a technical topic located somewhere in IT or quality management. Someone is responsible, some tool runs, somebody occasionally performs a data export and looks at the numbers. The result of this diffusion of responsibility is that, de facto, nobody is responsible.
Data arises at interfaces. It arises where people capture information — in design, in product development, in purchasing, in sales, in technical writing. Each of these stations has its own system, its own fields, its own habits when filling them in. When these stations are not connected by a common governance model, errors accumulate. Not because the people work badly, but because the system allows it.
Data quality is therefore not a technical question but a leadership question. Who decides which data is maintained and how? Who is responsible when a value is wrong? Who checks whether a product really has the weight that is in the system? When there is no clear answer to these questions, the problem is not the software but the organisation.
Typical error patterns — and why they repeat
In practice I keep seeing the same patterns. Not at one particular type of company, but at all of them. Large enterprises, mid-sized companies, well-organised operations with ISO certification, all of them.
The most common pattern: information silos. Product data lives in the design software. Technical data for the documentation lives in the CCMS or in an Excel file. Logistics data for shipping lives in the ERP. Marketing data for the online shop lives in the PIM system. When nobody has ensured that these systems talk to one another — or that at least a human regularly checks the consistency — then discrepancies are inevitable. At some point a product weight is updated in the ERP because a supplier used a different material. But the old value is still in the online shop. And when customs or a supervisory authority checks it, nobody cares that the ERP was correct.
The second pattern: missing validation. Data is released without automated checking mechanisms. An editor or clerk releases a piece of information because it sounds plausible, not because it was verified. That is a reproach to the process, not to the person — the process that built in no validation gates.
The third pattern: no governance structure. There is data, but nobody officially responsible for its correctness. When an error surfaces, the search begins: who entered it? Who should have checked it? What was the source? In many companies this question cannot be answered within five minutes, which is fatal in a regulatory audit.
What is at stake
The concrete case I alluded to at the start — a fine in the millions over faulty weight specifications — is not an isolated incident. It is symptomatic. The legal basis for such fines varies by industry: the Machinery Directive, the CE-marking obligation, the Product Safety Act, the Packaging Ordinance, the General Data Protection Regulation, the Supply Chain Due Diligence Act. The list is getting longer, not shorter.
And the authorities check ever more closely. Not because they want to harass companies, but because digitalisation makes it easier for them. Automated check routines, digital product passports, market surveillance based on database comparisons — that is not a distant future, it is already happening.
Anyone still holding the attitude today that data quality is a nice-to-have risks an inspection tomorrow that gets expensive. And the cost of a fine is the smallest problem in all this. Recalls, delivery stops, reputational damage, internal clean-up work — that is the real picture of the damage.
What helps in concrete terms — and what doesn’t
There is no shortcut. Anyone who tells me they have introduced a new PIM system and thereby solved the data-quality problem, I tell: no. A system cannot repair bad processes. It can sometimes make them more visible — which is already valuable — but it does not solve them.
What helps is a combination of three things:
First, governance. Define who is responsible for which data. Not in the sense of „who enters it“, but in the sense of: who is professionally responsible for its correctness? Who has to release it before a piece of information goes out into the world? This has to be anchored in processes and job descriptions, not only in people’s heads.
Second, system integration. When product data lives in four different systems, the probability of inconsistencies is high. That does not mean all four systems have to be merged into one — in most organisations that is neither feasible nor sensible. But it means interfaces have to be defined: which system is the leading source for which kind of data? And how do you ensure that downstream systems use this source instead of developing their own versions?
Third, quality assurance within the process. Not as a downstream control, but as an integrated component of the data-creation process. Automated validation rules that take effect before a record is released. Mandatory fields, plausibility checks, the four-eyes principle for critical attributes. That is an investment, not a mere expense — because it dramatically reduces the effort of fixing errors.
A personal tip from me: don’t start with a big data-cleansing campaign. Most such projects lose themselves in their own scope and end half-finished. Start instead with a question: which data could land us a fine tomorrow or trigger a recall? Begin there with governance and validation. The rest follows.
Whom this applies to
These insights are relevant to almost every company that manufactures physical products or operates in heavily regulated industries. Mechanical engineering, medical technology, automotive, consumer goods with safety relevance. But in the B2B service sector too, data is becoming increasingly relevant in regulatory terms: data protection, supply-chain due diligence, sustainability reporting.
There are companies for which this is less urgent. Consultancies without product responsibility, purely creative service providers. But even there, the quality of customer data or internal process data is often an underestimated risk. I deliberately say „less urgent“, not „not relevant“.
If you are unsure whether there is a need to act in your case: as a rule, a critical look at three points is worthwhile. First: for every relevant product attribute, can you say which system is the authoritative source? Second: do you have defined responsibilities for critical data categories? Third: are there automated checking mechanisms before data is published or transmitted to authorities?
If the answer to one of these questions is „not really“, then the recommendation is: act. Not because it would be regulatorily nice. But because the next inspector may be only a database query away.
Further standards and industry information are available from tekom — the German professional association for technical communication.
You can find more on concrete real-world cases in our article series on Artificial Intelligence and Technical Documentation.