Customer communications change all the time.
A regulator updates guidance. A product changes. A fee is amended. A complaints team notices that customers repeatedly misunderstand one sentence. Legal asks for a disclaimer to be rewritten. Compliance decides that a risk or customer right needs to be made clearer.
Sometimes the change is substantial. Sometimes it is one word. In a regulated organisation, however, the important question is not simply what the communication says now.
You may also need to answer: What did it say before? Who changed it? Who reviewed it? Who approved it? When did the new wording become active? And which approved version was used when a particular communication was generated?
That is the problem customer communication version control is designed to solve.
What is customer communication version control?
Customer communication version control is the controlled management of changes to templates used for emails, letters, PDFs, notices, statements and other customer communications.
Instead of treating a template as a single document that is repeatedly overwritten, each meaningful change creates a distinct version. For example, Version 1 might contain the original approved wording, Version 2 a change to payment-support language, and Version 3 an updated disclosure.
The current communication may only use Version 3, but Versions 1 and 2 remain part of its history. That history can help an organisation understand what wording existed at an earlier point in time, what replaced it, and how the change moved through the organisation's control process.
Version control therefore turns communication history into something structured rather than something that has to be reconstructed later from emails, tickets, shared folders, source code and people's memories.
Version control is more than saving copies of a document
Many organisations already have something that looks like version control. A shared folder might contain files such as:
- Arrears-Letter-Final.docx
- Arrears-Letter-Final-v2.docx
- Arrears-Letter-Final-v2-Compliance.docx
- Arrears-Letter-Final-v2-Compliance-FINAL.docx
- Arrears-Letter-Final-v2-Compliance-FINAL-USE-THIS.docx
That is document history. It is not necessarily controlled communication history.
For regulated customer communications, a useful version needs context around it. The organisation should be able to distinguish a draft from a version under review, an approved version from a rejected one, and a live version from one that has been superseded.
The content and the decision around that content need to remain connected.
Why does this matter in regulated communications?
A customer communication can affect what a person understands about a product, payment, right, obligation, risk or decision. That makes communication governance more than a writing exercise.
For UK financial services firms within scope of the Consumer Duty, the FCA's PRIN 2A.5 Consumer Understanding outcome requires firms to support retail customer understanding and communicate information in a way that is clear, fair and not misleading. The rules and guidance also address matters such as testing, monitoring and adapting communications where appropriate.
In March 2026, the FCA also published Consumer understanding: good practice and areas for improvement. Among its examples of good practice, the FCA discussed firms documenting what changed, why it changed and the impact of those changes, alongside clear governance and sign-off processes.
This does not mean that version-control software automatically makes a communication compliant, and the FCA does not simply require firms to install a particular version-control system.
The operational connection is more practical. If communications are reviewed, tested, changed and approved over time, firms need a reliable way to know exactly which wording those activities related to.
Without that link, an approval can become ambiguous. Someone may be able to show that Compliance approved an arrears letter, for example. That is not necessarily the same thing as demonstrating that Compliance approved the exact version that was later used.
The lifecycle of a controlled communication
A useful communication lifecycle separates creation from approval, and approval from operational use.
Draft → Review → Approved → Live → Superseded
A business or operational user may make several changes while a communication remains in draft. Those edits should not alter the wording currently being used for customers.
When the proposed version is ready, it can move into review. A reviewer examines that particular version and, depending on the organisation's governance model, it can then be approved, rejected or returned for changes.
Once an approved version becomes operational, it can be used for generation. When a later approved version replaces it, the earlier version becomes part of the historical record rather than simply disappearing.
This distinction matters because latest edited and latest approved are not the same thing. A draft created five minutes ago may technically be the newest version, but that does not mean it should be customer-facing.
Version control and approval workflow are different controls
Version control and approval workflow are closely related, but they do different jobs.
Version control tells you what changed. Approval workflow tells you what decision was made about that change.
A strong control model connects the two. Approval should relate to a specific version rather than vaguely to a template name.
If Version 7 is approved and someone later changes the wording, that new content should not silently inherit Version 7's approval. It is different content and should move through whatever review and approval process the organisation requires.
Otherwise, an approval can gradually become detached from the wording that was actually reviewed.
This deserves its own topic because the useful record extends beyond a simple Approved status. It can include who proposed the change, what changed, who reviewed it, who approved or rejected it and when it became operational. See What an Approved Wording Workflow Needs to Record.
What should happen to old versions?
Superseded versions should not automatically be treated as rubbish to be deleted once a replacement goes live. They can provide important historical context.
An organisation investigating a complaint months later may need to establish what wording was in use at the relevant time. Compliance may need to understand how a disclosure evolved. Operations may need to establish when a process change appeared in customer communications. Internal audit may need to follow the decision trail.
Overwriting or deleting the earlier wording makes those questions much harder to answer.
Retaining historical versions creates a second control question, though: how do you stop a superseded version being accidentally used again?
Historical visibility should not mean historical versions remain freely available for normal production use. A controlled system can preserve an old version as part of the record while removing it from the normal generation path.
Version control should continue into generation
There is another important boundary in the communication lifecycle.
Some organisations carefully control a template during drafting and approval, then lose the connection when an application actually generates the customer email, letter or PDF.
This creates two separate worlds: the template world, where teams know what was approved, and the production world, where systems generate communications at scale.
Those worlds should remain connected.
A generation record should be capable of identifying the template and approved version on which a generated communication was based. This gives the organisation a much stronger answer if somebody later asks:
Which approved wording was this communication generated from?
The evidence needed around that question is explored separately in How to Evidence a Generated Customer Communication.
Generation evidence is not delivery evidence
This distinction is important.
Knowing which approved version was used to generate a communication does not, on its own, prove that the communication was successfully sent, delivered, opened or read.
Those are separate events. Sending and delivery evidence may depend on information returned by the configured client system, email provider, print-and-post provider or another delivery service.
Generation evidence answers one question: what controlled wording was used to create the communication?
Delivery evidence answers a different question: what happened to that communication after generation?
Combining the two into one vague claim of "proof" can create more confusion than clarity.
Why allowing every calling system to choose a version can create risk
Consider an API design in which an application requests both a template and a version:
template = payment-reminder
version = 14
That gives the calling application flexibility, but it also pushes part of the version-control decision into every connected system.
If Version 15 has subsequently been approved and Version 14 is superseded, an old configuration, hard-coded value or integration mistake could continue requesting Version 14.
An alternative model is to make the template identifier the stable reference while the communication platform determines which approved version is current for generation.
This separates two responsibilities:
- The client application decides which communication it needs.
- The controlled communication system determines which approved version of that communication is current for generation.
CommsPliant follows this model. A generation request uses the template identifier rather than allowing the calling application to select an arbitrary historical version. At generation time, CommsPliant uses the latest approved version available for that template.
This keeps version selection inside the controlled communication lifecycle instead of recreating that control across every connected application.
What should a good version record contain?
The exact design will depend on the organisation, communication type and regulatory context, but a useful version record normally needs enough information to reconstruct the communication's history without piecing it together manually.
That may include:
- a stable template identifier;
- a unique version identifier;
- the content associated with that version;
- its status, such as draft, review, approved, live or superseded;
- who created or changed it and when;
- what changed between versions;
- review and approval decisions associated with that version;
- when the approved version became operational; and
- records connecting generated communications with the approved version used.
The important principle is not the number of database fields. It is whether the organisation can follow the history clearly without reconstructing the story from several disconnected systems.
Version history, audit logs and evidence are not the same thing
These concepts are often grouped together, but each answers a different question.
- Version history: What were the different states of this communication?
- Audit log: What actions occurred, when, and by whom?
- Approval record: Who made the relevant review or approval decision for this version?
- Generation record: Which controlled version was used when an output was created?
Together, these records can form a much stronger evidence chain. Separately, each tells only part of the story.
An audit log showing that somebody edited a template does not prove that the resulting wording was approved. An approved template does not, by itself, identify which version generated a particular PDF. And a generated PDF does not automatically explain the governance process behind the wording inside it.
Why templates inside application code create a release dependency
Many organisations still store customer-facing wording directly in application code or application-specific configuration. There can be perfectly valid historical reasons for this. Engineering originally built the process, templates evolved alongside the application, and changing them through the normal software lifecycle felt controlled.
But this architecture can create an expensive dependency.
A Compliance or Operations team identifies a wording change. A ticket is raised. A developer makes the change. The code is reviewed. Testing follows. A release is scheduled. The change is deployed.
None of those engineering controls are inherently bad. The question is whether every customer wording change needs to inherit the complete software release process.
Software deployment and communication approval solve different problems. Code may need engineering review, while customer wording may require compliance, legal, product or operational review.
When the two processes are tightly coupled, even a small communication change can inherit the cost and delay of a software release.
That does not mean Engineering should disappear from the process. Changes to integrations, new data fields, new channels or changes to technical contracts can still require engineering work. The aim is to separate communication-content governance from software deployment where the technical architecture allows it.
We explore that boundary in When a Wording Change Should Not Wait for a Software Release.
Regulatory record keeping still depends on context
There is no single retention rule that applies to every customer communication in every regulated organisation.
Different activities, products and regulatory regimes can impose different requirements. For example, FCA COBS 4.11 contains specific record-keeping requirements for financial promotions within its scope, including requirements to make adequate records of relevant promotions communicated or approved. It also specifies different retention periods for different categories.
That is one example, not a universal retention rule for all communications.
Organisations therefore need to determine what should be retained, in what form and for how long according to the activities, products, customers and rules that apply to them.
Version control supports that governance. It does not replace the regulatory analysis behind it.
How CommsPliant approaches customer communication version control
CommsPliant treats regulated communication templates as controlled operational assets rather than pieces of wording buried inside application code.
Business or operational users can work on templates in a controlled workspace. Changes create identifiable versions, and review and approval activity can remain associated with the version to which the decision actually applied.
Once a version is approved for use, connected systems can request the communication by template identifier. The calling system does not choose an arbitrary historical version; CommsPliant uses the latest approved version available at generation time.
The CommsPliant Evidence Vault provides the evidence layer around that controlled lifecycle. It can preserve the approved-version context and approval history together with rendering evidence such as the rendering timestamp and a tamper-evident hash. Full rendered-content retention is optional rather than being assumed for every implementation.
This is deliberately different from claiming that a generation record proves delivery. The Evidence Vault can help establish the controlled version and evidence associated with generation, while sending and delivery status depend on information available from the configured systems or delivery providers.
The aim is not to turn Compliance into Engineering, and it is not to remove Engineering from the architecture. It is to give each team control over the part it actually owns.
- Business and Operations manage communication content.
- Compliance governs review and approval according to the organisation's process.
- Engineering controls integrations, systems and technical contracts.
- CommsPliant maintains the controlled version history and evidence connecting those activities.
A simple test for your current process
There is a straightforward way to test whether an organisation really has control over customer communication versions.
Choose a communication that changed six months ago and ask:
- What did the previous wording say?
- What changed?
- Why was it changed?
- Who reviewed the proposed wording?
- Who approved it?
- When did the replacement become operational?
- Can an operational system still generate the superseded wording?
- Can we identify which approved version was used for a specific generated communication?
If answering those questions requires searching Jira, email, SharePoint, source code, release notes and somebody's memory, the organisation may have document history.
It does not necessarily have controlled customer communication versioning.
And that distinction matters when somebody needs the answer months or years after the wording changed.