A safety data sheet goes out of date when something changes that it should reflect and the change does not make it into the document. The information is technically wrong from that moment, but nothing visibly breaks, so it can sit wrong for a long time. This is practical guidance for regulatory and technical teams, not legal advice. Confirm your own obligations against the source.
What triggers a revision
Most out-of-date safety data sheets are not the result of neglect. They are the result of a trigger firing in one part of the business and not reaching the person who maintains the document. The common triggers are:
A study, a supplier notification or new data changes what you know about a substance or mixture. The safety data sheet has to reflect the current state of knowledge.
A change in the harmonised classification of a substance, or in how you classify a mixture, flows through to the safety data sheet and often to the label.
When a substance is added to the REACH Candidate List and it is present in your product above the relevant threshold, that can require an update and supply-chain communication.
The required format and content of safety data sheets is set in regulation and is revised from time to time. A format change can oblige a revision even when your product has not changed.
A raw material supplier reformulates, changes source, or issues a revised safety data sheet of their own. Their change becomes your change.
A candidate-list update is one of the more predictable triggers, which is why the two processes are worth connecting.
Why version drift is silent, and where it starts
Drift starts at the handover points. The supplier notification lands in a shared inbox that the document owner does not watch. The classification change is agreed in a meeting and not written into a task. The format change is published by the regulator and nobody owns the job of checking the estate against it. None of these are dramatic. Each one just quietly leaves a document saying something that is no longer true.
It stays silent because a safety data sheet does not fail loudly. It keeps opening, keeps printing, keeps attaching to emails. The error only surfaces when someone downstream checks it against reality, and by then it may have been in circulation for months.
The distribution problem
Revising the document is only half the duty. The other half is getting the current version to the people who need it, and being able to show that you did. When a revision is triggered by certain changes, there are duties to provide the updated safety data sheet to recipients you have supplied within a defined period. Meeting that duty means knowing who you supplied, when, and which version they received.
Most manual processes cannot answer that on demand. They can produce the current document, but not a reliable record of who holds which version. That gap is where the real exposure sits.
Cannot show who holds which version?
We build the audit trail: a source of truth for your safety data sheets, the triggers that require a revision, and a record of what was distributed to whom and when. A short technical call, no pitch.
Book a technical callWhat an auditable review and distribution process looks like
- A single owner and a single current version for each product, so there is never a question of which document is authoritative.
- The triggers wired to the document, so a supplier notification, a classification change or a candidate-list change creates a review task automatically rather than relying on someone remembering.
- A record of distribution: which version reached which customer, when, and by what route, kept as you go rather than reconstructed under audit pressure.
- A named reviewer who approves each revision before it is issued. The system prepares the change; the competent person signs it off.
A practical review cadence
Triggers catch the changes you are told about. A periodic review catches the ones you are not. A workable pattern is a scheduled review of each safety data sheet on a fixed cycle, weighted so that higher-hazard and higher-volume products are looked at more often, on top of the trigger-driven revisions. The point of the cadence is not to rewrite documents for the sake of it, but to make sure nothing sits unchecked indefinitely.
The same product facts that drive these revisions are what your team restates every time a customer sends a compliance questionnaire, which is why a single source of truth pays for itself across both jobs.
Frequently asked questions
When do I have to update a safety data sheet?
When the information in it is no longer accurate or complete: new hazard data, a classification change, a relevant candidate-list change, a regulatory format change, or a change from your own supplier. The exact triggers and timescales are set in regulation, so confirm your specific obligations against the source. This is practical guidance, not legal advice.
Do I have to send updated safety data sheets to past customers?
There are duties to provide updated safety data sheets to recipients you have supplied within a defined look-back period when certain changes occur. What applies depends on the change and your role. Confirm the specifics with HSE or ECHA, and keep records of who you supplied and when.
Is a safety data sheet the same as a COSHH assessment?
No. A safety data sheet is an input to a COSHH assessment, not a substitute for one. The assessment considers how the substance is actually used in a specific workplace. HSE is clear on this distinction.
How do we prove a customer received the current version?
With a record: which version went to which customer, when, and by what route. Without that record you cannot demonstrate the duty was met, which is the part most manual processes cannot produce on demand.
Sources
The triggers, timescales and distribution duties for safety data sheets are set in regulation. Confirm the specifics that apply to your products and role against the primary sources. This article is practical guidance, not legal advice.
How we take documentation and knowledge work off regulatory and technical teams.
A candidate-list change is one of the triggers for an SDS revision.
The SDS is one input customers ask about. Here is the rest of the load.