A tanker held at a terminal costs money. So does a disputed invoice, an empty return journey or a dispatcher spending half the morning chasing paperwork. Transportation software can help an oil and gas business see where those costs arise.
But the information behind a delivery is often about people as well as cargo. A vehicle’s location may reveal a driver’s movements. A delivery note may contain a name and signature. Contractor records may include personal phone numbers and bank details.
That puts data protection on the project brief alongside routing, fuel costs and invoice accuracy. For operations covered by the EU GDPR or UK GDPR, buying a new platform does not settle the compliance questions. The business still needs to decide what information it needs, why it can use it and who should see it.
Table of Contents
Before comparing dashboards, follow one shipment through the business. Look at the booking, driver assignment, route updates, proof of delivery and invoice. Where does personal information enter the process? Who receives a copy?
Providers such as Wezom offer oil and gas transportation management software designed around industry workflows. When assessing a proposed system, ask how those workflows handle personal information as well as how they calculate transport costs.
For example, an invoice dispute may require a delivery timestamp and an agreed carrier rate. It may not require a complete record of where the driver travelled that week.
The distinction matters. A shipment’s weight is not necessarily personal data. A location record linked to an identifiable driver is. Removing the driver’s name does not make the record anonymous if a vehicle number or shift roster still identifies them.
A dispatcher checking whether a tanker will reach a terminal before its loading slot has a specific operational question. Keeping every driver’s movements indefinitely in case somebody finds them useful later is much harder to justify.
Set out the purpose of each data use before collection begins. Dispatching, compliance with driving-hours rules and investigating delivery disputes may involve different records and different lawful bases.
The chosen lawful basis must fit the activity. A legal obligation can support processing that a particular law requires; it is not a blanket justification for every tracking feature. Where ordinary legitimate interests is appropriate, assess the business interest, the necessity of the processing and the effect on the people involved.
Workers also need an understandable explanation of the monitoring: what is collected, why, who receives it and how long it is kept. The ICO says employers must inform workers and passengers about vehicle monitoring. Where a work vehicle is also available for private use, monitoring during that private use will rarely be justifiable.
Build those boundaries into the system. An off-duty setting is more useful than a privacy notice promising that nobody will look at unnecessary location records.
Finance teams may need to know why a route regularly exceeds its budget. They will not always need a named driver’s detailed movement history to find the answer.
A useful report might show mileage, fuel use, waiting time, carrier charges and the cost per delivery. Start there. Add personal detail only where the purpose requires it.
This is a practical application of data minimisation: personal information must be adequate, relevant and limited to what is necessary. It does not mean collecting so little that records become misleading or unusable.
Possible design choices include:
Better data does not automatically eliminate financial risk. Nor does collecting more of it guarantee better decisions. If the real problem is a recurring queue at a terminal, the report should make that queue visible.
Assess privacy risks while the system is being designed, when changes are still straightforward.
A data protection impact assessment, or DPIA, is required where planned processing is likely to create a high risk to people’s rights and freedoms. A new logistics platform does not automatically require one simply because it is new. The nature and extent of the processing matter.
For UK operations, the ICO specifically identifies driver behaviour monitoring and monitoring tools that use analytics to make inferences, predictions or decisions about drivers as requiring a DPIA.
Consider a proposed driver score based on idle time. Does the system distinguish a driver taking an unexplained break from one waiting under instructions at a terminal? Can a supervisor investigate an apparent problem? Could a faulty GPS record affect a person’s pay or work allocation?
These questions belong in the design discussion. A score that cannot account for ordinary working conditions may generate disputes instead of useful savings.
A central platform can reduce duplicate records and repeated data entry. It can also expose a much larger set of information if everyone receives broad access.
Set permissions around actual work. Dispatchers may need current assignments and locations. Finance staff may need approved charges and delivery evidence. An external carrier should only see the jobs and records it is authorised to handle.
Security measures should reflect the risks. For a system holding driver and contractor information, sensible measures to assess include individual accounts, multi-factor authentication, controlled exports, encryption, access logs and prompt removal of unused accounts. Backups should be protected and restoration tested.
Check the small details during acceptance testing. Can a temporary user download the entire driver directory? Does a shared delivery link remain active after the job ends? Can someone see another carrier’s records by changing a reference number?
Those tests tell the buyer more than a broad promise that the platform is secure.
A transport platform may connect to telematics services, accounting software, cloud hosting and support teams. Each connection needs a clear purpose and an agreed scope.
Where a supplier processes personal data on the company’s behalf, an appropriate processor contract is required. It should address matters including documented instructions, confidentiality, security, subprocessors, assistance with individual rights and what happens to the data when the service ends.
Do not assume every contractor is a processor. A carrier or insurer may determine its own purposes for some processing and act as a separate controller. Map the actual roles.
Also check where information is stored and who can access it. In the UK, making personal information accessible to a separate organisation overseas can be a restricted transfer, including through remote access. A UK hosting location alone does not settle that question.
Ask about overseas support, subprocessors and the applicable transfer arrangements before signing.
An accounting record and a detailed GPS trail serve different purposes. They should not automatically share the same retention period.
GDPR does not prescribe one universal retention period for transport records. The company must decide how long identifiable information is needed for its purposes, taking account of relevant legal obligations.
A workable schedule separates categories such as:
Record the reason for each period and implement deletion or effective anonymisation when the information is no longer needed. Check exports and connected systems too: removing a record from the dashboard achieves little if copies remain in a shared folder.
A named owner should review exceptions, including records retained for a live dispute.
Automation can reduce repeated entry, flag duplicate invoices and match delivery records to agreed rates. When employees spend less time on those tasks, they can focus on exceptions that need judgement.
Keep the data exchanged by each integration narrow. An accounting system may need a shipment reference, charge and approval status. It may have no reason to receive the driver’s location history.
There should also be a route for correcting errors. A driver assigned to the wrong vehicle or a delivery recorded against the wrong person can distort both operational reports and personal records.
Test a correction from beginning to end. Does it reach the systems that received the incorrect information, or does the old value return during the next synchronisation?
A lost device, an exposed tracking link or an incorrectly addressed export can create a personal data breach without bringing the transport platform down.
Decide who receives an alert, who can restrict access and who assesses the consequences for the people affected.
Under UK GDPR, a controller must notify the ICO of a reportable breach without undue delay and within 72 hours of becoming aware of it. Notification is not required where the breach is unlikely to create a risk to people’s rights and freedoms. All personal data breaches still need to be documented, including the reasoning behind a decision not to report.
Where a breach is likely to result in a high risk to individuals, they must also be informed without undue delay, subject to the applicable exceptions.
The response plan should be usable during an evening shift, with current contacts and clear responsibilities.
Before deployment, record the transport problems the project is supposed to fix: empty mileage, waiting time, invoice discrepancies or administrative hours per shipment.
After deployment, compare those figures. Alongside them, check whether unnecessary accounts are being removed, retention rules work and staff can retrieve or correct personal information without searching through scattered spreadsheets.
Custom software gives a business room to build these controls around its operations. Their value depends on the specification, configuration and day-to-day management.
A useful first project might be quite modest: connect delivery evidence to invoices, restrict access by role and stop sending driver details to people who do not need them. That can give the finance team a clearer view of costs while making personal information easier to account for.
If you require help with a GDPR Compliance, Online Reputation Management, Removing content from Google, or a Right to be Forgotten request, please use the form below. By submitting an enquiry you agree to the gdpreu.org privacy policy.