A colleague of mine asked me a fairly simple question a few days ago. He wanted to know the difference between data governance and chain of custody, and whether they were basically the same thing with different names.
I gave him a quick answer at the time, but the question stayed with me.
The more I thought about it, the more I realised that both ideas had influenced a lot of the systems I had worked on, even in situations where nobody used either term.
I have spent most of my working life building systems and software across a few different industries. In many of those projects, the difficult part was not getting the software to work. It was making sure that the data coming out of the system could be trusted.
Telecommunications was probably where I first became very conscious of this.
Consider billing. A customer is charged based on their usage, and that usage is recorded by systems operating deep within the network. Those records eventually go through other systems and processes before they become the figure that appears on a customer's bill.
If something goes wrong along the way, the consequences are fairly straightforward. The customer might be overcharged. That damages trust and can create regulatory problems. Or the customer might be undercharged, which becomes a direct loss of revenue. If the problem happens consistently, it might not be noticed until someone eventually starts looking closely at the numbers.
That experience taught me something I have carried into other projects: a billing system is not simply a software problem with a data component attached to it. It is also a data problem.
The same was true when working with telecommunications network data.
When deciding where additional network capacity is needed, you are not guessing. You are looking at utilisation, traffic patterns and capacity over time. Those figures can influence decisions about where infrastructure should be expanded.
If the underlying data is wrong or incomplete, the decision can be wrong too. You might invest in capacity where it is not needed, or fail to address a bottleneck until customers start experiencing problems.
In that situation, data quality is no longer just about whether a report contains the right number. It can influence what physical infrastructure gets built.
My experience in oil and gas brought another dimension to the same issue.
When a system reports how much a field is producing, that figure can have financial consequences well beyond the system that generated it. Production figures can feed into revenue calculations and the amounts shared between different parties.
That means there can be a very simple question behind a seemingly simple number:
Where did this figure come from?
If the answer is difficult to establish, confidence in the number starts to suffer.
There was also a safety dimension that I came to appreciate while working in that sector. People working in an operation depend on accurate and timely information to understand what is happening and recognise when conditions may be becoming dangerous.
A data problem in that situation is different from an incorrect figure on a management report. If important information is wrong, delayed or missing, people may not see a developing problem in time.
That made me take things such as validation and monitoring much more seriously in the systems I worked on afterwards.
The part of this that connects most directly to my colleague's question came from studying digital forensics at KNUST.
Chain of custody is a core concept in digital forensics. At its simplest, it is about being able to account for evidence from the point at which it is collected through its handling, examination and storage, right up to the point where its authenticity or integrity might be challenged.
The important question is not simply whether the evidence exists. It is whether you can demonstrate what happened to it.
Who collected it? How was it handled? Where was it stored? Who had access to it? Was it transferred? Was it examined or changed in some way?
If there are gaps in that history, it becomes more difficult to demonstrate that the evidence presented later is the same evidence that was originally collected and that it has remained trustworthy.
That is why chain of custody is particularly important in forensic work.
But this is also where it is important not to stretch the term too far.
Most ordinary business data is not evidence in a legal case, and most business systems do not need to operate under formal forensic chain-of-custody procedures.
What interested me was the underlying discipline.
In the systems I had worked on in telecommunications and oil and gas, there were situations where it mattered that we could explain where a number came from, what had happened to it and whether it had been changed.
The reason was not necessarily that a court was going to examine the data.
It might be a customer disputing a bill. An auditor questioning a production figure. A business partner wanting to understand how a number was calculated before agreeing to a revenue split.
The circumstances were different, but the question was often similar:
Can we explain how we got this number?
This is where data governance and chain of custody start to overlap, but they should not be confused.
Data governance is the broader framework an organisation uses to manage its data. It deals with things such as who is responsible for particular data, what standards and policies apply, who can access it, how data quality is managed and who is accountable for decisions involving that data.
Governance is therefore about how an organisation manages data as an asset over time. It is not limited to one record or one transaction. It applies across the organisation and across the different processes through which data is created, stored, changed and used.
Chain of custody has a much narrower purpose. In the forensic sense, it is concerned with documenting the handling of specific evidence so that its integrity and authenticity can be demonstrated if they are challenged.
That distinction matters.
A company can have data governance policies, clearly defined ownership and processes for maintaining data quality without necessarily being able to answer a very specific question such as: who changed this particular record, when did they change it, and what happened to it before and after that change?
The reverse is also true. A system might maintain detailed records of changes and provide excellent traceability without the organisation having a mature governance framework around the data as a whole.
The two ideas are related, but they are solving different problems.
This is where I think auditability becomes particularly useful.
An audit trail records what happened. Depending on the system, that might include changes to a record, who or what made the change, when it happened and, where appropriate, what the previous value was.
Auditability is the ability to use those records and other information in the system to understand how the current state of the data was reached.
That is an important distinction.
Governance establishes the rules for how data should be managed. An audit trail provides a record of what happened. Auditability is what allows someone to go back later and reconstruct the story.
That could mean tracing a billing calculation back to its source, understanding why a production figure changed, or working out how a number in a management report was produced.
This is also where the thinking behind chain of custody can be useful outside forensic work. You may not need a formal forensic process, but you may still need enough traceability to defend the integrity of important data.
For me, the practical lesson is fairly simple.
Not every application needs formal chain-of-custody procedures. Most do not.
But if data is likely to be disputed, audited or relied upon for a decision with financial, operational or safety consequences, the system should be designed with traceability in mind.
Some of this comes down to ordinary design decisions.
Record who or what made an important change and when it happened.
Keep a history of previous values where overwriting information would make later investigation difficult.
Validate data when it enters the system rather than assuming that everything received from another system is correct.
Where appropriate, make it possible to trace an important figure back to its source.
These are not particularly exotic ideas. They are system design decisions.
The problem is that they are easy to overlook because they do not always appear as functional requirements.
A system can pass its tests, perform exactly as specified and still leave you unable to explain how a particular figure was produced six months later.
The gap may not become visible during development. It becomes visible when someone asks a question the system was never designed to answer.
I do not think every developer needs to become a digital forensics specialist, and I am not suggesting that ordinary business systems should be treated as though they are collecting legal evidence.
What I do think is worth carrying across from forensic work is the habit of asking a few basic questions.
Where did this data come from?
What has happened to it since then?
Who or what has changed it?
Can we tell when that happened?
And, if someone challenges the number later, can we explain why we believe it is correct?
Those questions become particularly important when the data affects money, operations, safety, customers or decisions made by other people.
My colleague's question started as a question about the difference between two terms.
I ended up thinking about something slightly different.
When we build systems, we tend to think about whether the software works. We think about features, performance, security and usability. We should also think about whether the data produced by the system can be explained later.
If a number matters to a customer, a partner, an auditor or an operator, there should be a way to understand where it came from and what happened to it.
That is worth considering when the system is being designed, rather than waiting until someone has already started asking questions about the data.