Start here: the short version
Driver Codes is not a processor for the whole service. Data protection roles depend on the specific processing activity.
Driver Codes collects the driver's authority, retrieves the driving record from DVLA, keeps evidence of the authority and check, and shares the result with you.
Driver Codes also acts as your processor for limited portal and workspace processing, such as hosting your company dashboard, user access, notes, exports and administrative records.
Three service areas, activity-specific roles
Driver Codes operates distinct service areas. Our data protection role depends on the specific processing activity — it is not a single label applied to the whole platform.
Consumer app
Drivers who use Driver Codes as a personal utility. This has no involvement from you as a business customer — Driver Codes is the sole controller for all processing in this context.
Driver check service
The capture of driver authority, retrieval of DVLA records via concierge or ADD, delivery of check results, and maintenance of mandate and audit records. Driver Codes acts as an independent controller — not as your processor — for this layer.
Driver checks portal
You control which drivers to invite, monitor or remove based on your employment, contractor, fleet, insurance or compliance decisions. Driver Codes hosts and operates the portal workspace on your instructions as processor under Article 28.
When you use the portal to decide which drivers to invite, monitor or remove, you are exercising your own controller function. Driver Codes does not make that employment, contractor, fleet or compliance decision for you. At the same time, Driver Codes operates the portal infrastructure and workspace environment as your processor. These two layers sit within the same interface but carry different data protection roles, which is why both a Data Sharing Agreement and a Data Processing Addendum are required.
Plain-English data flow
This is how a typical company driver check moves through the Driver Codes service, with the data protection role shown at each stage.
| Step | What happens | Main role | What this means in practice |
|---|---|---|---|
| 1 | Your organisation decides to check a driver You choose who to invite, why the check is needed, and how often checks should run. | Customer controller | You are responsible for your own lawful basis, privacy information, internal policy and decision to carry out the check. |
| 2 | Driver Codes sends or manages the invitation The customer decides to invite the driver; Driver Codes then routes the driver into its own authority flow. |
Customer controller
Driver Codes independent controller |
You decide that the driver should be invited. Driver Codes controls the hand-off into its own authority flow and how the driver journey is presented. |
| 3 | The driver gives authority The driver signs the declaration and authorises Driver Codes to retrieve their DVLA driving record. | Driver Codes controller | Driver Codes controls the authority wording, evidence capture, signature process and mandate record. This authority is not UK GDPR consent. |
| 4 | Driver Codes retrieves the DVLA record The check is completed through the concierge workflow or ADD fallback. | Driver Codes controller | Driver Codes retrieves the record under its own DVLA access arrangements and keeps mandate and audit evidence for its own compliance purposes. |
| 5 | Driver Codes shares the result with your organisation The result is made available in the portal or otherwise delivered to you. |
Driver Codes independent controller
Customer independent controller |
Driver Codes controls the delivery of the result from the check service. Your organisation receives the result for its own employment, contractor, fleet, insurance or compliance purposes. |
| 6 | Your organisation reviews and uses the result You decide what action, if any, to take after the check. | Customer controller | You decide whether the result affects employment, contractor, fleet, insurance or compliance decisions. Driver Codes does not make that decision for you. |
| 7 | Portal records are hosted and administered This includes dashboard records, admin users, notes, exports and workspace settings. |
Driver Codes processor
Customer controller |
For the portal workspace, Driver Codes acts on your instructions as processor under the Data Processing Addendum. You remain controller for your organisation’s portal use. |
| 8 | Records are retained or deleted Different records are kept for different reasons. |
Driver Codes controller
Customer controller Driver Codes processor |
Driver Codes keeps mandate, audit and service-integrity records for its own compliance purposes. Your organisation applies its own retention rules to downloaded reports, local records and internal decisions. Portal workspace retention is handled under the DPA where Driver Codes acts as processor. |
Your organisation decides who needs to be checked and what to do with the result; Driver Codes controls the driver authority and DVLA retrieval process; and Driver Codes acts as processor only for the limited portal workspace it hosts for you.
The driver authority is not UK GDPR consent
Customers often ask whether the driver's signed authority is the same thing as consent under UK data protection law. It is not.
It is not the same thing as consent under UK GDPR. Driver Codes and your organisation each need their own lawful basis for the personal data they process.
Are Driver Codes and the customer joint controllers?
Usually, no. Driver Codes and your organisation process related information, but they do not decide all purposes and means together.
Your organisation decides
- which drivers to invite;
- why checks are required;
- how often checks should happen;
- who in your organisation can see results;
- how the results are used for employment, contractor, fleet, insurance or compliance decisions.
Driver Codes decides
- how the driver authority is captured;
- how the DVLA retrieval process is operated;
- whether the concierge workflow or ADD fallback is used;
- what mandate and audit evidence is retained;
- how the check is technically completed and delivered.
Because the purposes and means are not jointly determined for the whole process, the usual position is sequential independent controllership, with a separate processor relationship for the portal workspace.
Detailed role allocation by activity
This table is the detailed reference version of the plain-English flow above. Activities are grouped by service area. Where both parties are marked as controller, they act independently — neither party instructs the other for that processing.
| Processing activity | Driver Codes | You (customer) | Instrument |
|---|---|---|---|
| Consumer app · driver.codes | |||
| Personal app account & securityDriver-initiated, no company involvement | Sole controller | Not decision-maker | Consumer T&Cs & privacy notice |
| Driver checks portal · app.driver.codes — your controller decisions | |||
| Decision to invite a driverChoosing which employees or contractors to check | Not decision-maker | Sole controller | Data Sharing Agreement |
| Decision to cancel or remove a driverRevoking access based on employment status or risk | Not decision-maker | Sole controller | Data Sharing Agreement |
| Review, storage & use of check resultsEmployment, fleet-risk, insurance & contractor decisions | Not decision-maker | Sole controller | Data Sharing Agreement |
| Driver checks portal · app.driver.codes — Driver Codes as processor | |||
| Portal hosting & administrationWorkspace environment, admin accounts, notes, exports | Processor (Art. 28) | Controller | Data Processing Addendum |
| Driver check service — licence verification | |||
| Driver invitation workflow executionSending the invite at the customer's request and handing the driver into the Driver Codes authority flow | Independent controller | Independent controller | Data Sharing Agreement |
| Driver authority captureMandate, declaration & signature | Sole controller | Not involved in capture | Data Sharing Agreement |
| DVLA record retrievalConcierge workflow & ADD fallback | Sole controller | Not involved in retrieval | Data Sharing Agreement |
| Platform security & audit logsFraud prevention, mandate retention, service integrity | Sole controller | Not decision-maker | Business Customer Terms |
Why Driver Codes is controller for the check service
This is the question we are asked most often. The answer is grounded in our DVLA access arrangements and in how the checking process actually works.
Because neither party acts on the other's documented instructions for this processing, both parties act as independent controllers for their own purposes. This is consistent with UK data protection guidance on controller and processor roles.
What your organisation should have in place
Before inviting drivers, your organisation should make sure it has the following in place for its own use of driving record check results.
- a clear reason for carrying out driving record checks;
- an Article 6 lawful basis under UK GDPR for your own processing;
- a Schedule 1 DPA 2018 condition where you process endorsements, disqualifications or other criminal offence data;
- an Appropriate Policy Document where required;
- a workforce, contractor or driver privacy notice explaining your use of driving record checks;
- an internal policy for when checks are run, how often they are repeated, who can see results, and how decisions are made;
- role-based access controls for portal users in your organisation;
- retention rules for any exported reports or records stored outside Driver Codes.
Responsibility checklist
Driver Codes
- Maintaining the DVLA ADD access agreement
- Capturing and retaining valid driver authority records
- Executing checks lawfully via concierge or ADD
- Providing drivers with a Driver Checks Privacy Notice
- Maintaining its own LIA, APD and ROPA where required
- Retaining mandate and audit records for evidential purposes
- Executing the Article 28 DPA for the portal workspace
- Maintaining appropriate technical and organisational security measures
You (business customer)
- Deciding which drivers to invite, monitor or remove
- Documenting your own Article 6 lawful basis
- Identifying a Schedule 1 DPA 2018 condition for criminal offence data
- Maintaining an Appropriate Policy Document where required
- Issuing workforce, contractor or driver privacy information covering your use of check results
- Acting on results lawfully and fairly in employment, contractor, fleet or compliance decisions
- Controlling portal access and reviewing user permissions
- Applying your own retention rules to exported reports
Which document should I read next?
Use this section to find the right document for the question you are trying to answer.
All documents are available at app.driver.codes/documents. The Business Customer Terms, Data Sharing Agreement and Data Processing Addendum apply automatically at signup.
| If you want to understand... | Read this |
|---|---|
| The commercial terms for using Driver Codes business services | Business Customer Terms |
| The overall role split between you and Driver Codes | Data Sharing Agreement |
| The limited areas where Driver Codes acts as your processor | Data Processing Addendum |
| What the driver is told during the mandate flow | Driver Invite / Mandate |
| How drivers are informed about Driver Codes' processing | Driver Checks Privacy Notice |
| Security, hosting and operational safeguards | Security & Technical Measures Schedule |
| Suppliers used by Driver Codes | Sub-processors |
Note on regulator naming: at the version date of this document, the Information Commissioner's Office (ICO) remains the operative legal name of the UK data protection regulator. References in this document to the "Information Commission" anticipate the regulator's reconstitution under Part 6 of the Data (Use and Access) Act 2025. Our registration (ZA788385) is held with the regulator and will transfer to the Information Commission by operation of law on commencement of sections 118 and 119 of that Act.