Operator Agreement
Concluded between:
[CLIENT REGISTERED NAME], registration number […], of [registered address] (the Responsible Party);
and
[FUSARO REGISTERED NAME], registration number […], of [registered address], trading as Fusaro Fleet (the Operator).
Background
A. The Responsible Party uses the Operator's fleet management service, Fusaro Fleet, under the [name of service agreement or order form] dated [date] (the Main Agreement).
B. In providing that service, the Operator processes personal information on the Responsible Party's behalf, as an operator in terms of the Protection of Personal Information Act 4 of 2013.
C. Section 21 of POPIA requires a written contract between a responsible party and its operator. This agreement is that contract.
1. Definitions and interpretation
1.1 In this agreement:
POPIA means the Protection of Personal Information Act 4 of 2013 and its regulations, as amended.
Client Personal Information means personal information (as defined in POPIA) that the Operator processes for the Responsible Party in providing the Service, as described in Annexure A.
Service means the Fusaro Fleet platform, including the web application at app.fusaro.co.za, the driver application, and the related support the Operator provides under the Main Agreement.
Security Compromise means a situation where there are reasonable grounds to believe that Client Personal Information has been accessed or acquired by an unauthorised person.
Sub-operator means a third party the Operator engages that processes Client Personal Information.
Business Day means any day other than a Saturday, Sunday or South African public holiday.
1.2 Words defined in POPIA, including data subject, processing, operator, responsible party, special personal information and Information Officer, have the meanings given to them in POPIA.
1.3 Headings are for convenience only. The annexures form part of this agreement. "Including" means "including without limitation".
2. Roles
2.1 The Responsible Party determines the purpose of and means for processing Client Personal Information, and is the responsible party for it in terms of POPIA.
2.2 The Operator processes Client Personal Information only as the Responsible Party's operator, in terms of a mandate and not under the direct authority of the Responsible Party.
2.3 The Responsible Party warrants that it has a lawful basis for the processing it instructs, and has given data subjects the notices POPIA requires. This includes telling its drivers about location processing (clause 13).
3. Commencement and duration
3.1 This agreement starts on the date of last signature, or when the Operator first processes Client Personal Information if that is earlier.
3.2 It continues for as long as the Operator, or any Sub-operator, holds Client Personal Information, including after the Main Agreement ends, until clause 14 has been complied with.
4. Processing only on instructions
4.1 The Operator processes Client Personal Information only with the Responsible Party's knowledge or authorisation (section 20(a) of POPIA), namely:
to provide the Service as described in the Main Agreement and Annexure A;
on the Responsible Party's documented instructions, which include instructions given by using the Service's settings and functions; and
where the law requires it, in which case the Operator will tell the Responsible Party first, unless the law forbids that.
4.2 The Operator will not:
process Client Personal Information for its own purposes;
sell it, or disclose it to anyone except as this agreement allows;
use it to train analytics or artificial intelligence models; or
combine it with information from other clients.
4.3 The Operator will tell the Responsible Party promptly if, in its opinion, an instruction would breach POPIA.
5. Confidentiality
5.1 The Operator treats Client Personal Information as confidential and won't disclose it, unless the law requires it or this agreement allows it (section 20(b) of POPIA).
5.2 This obligation survives the end of this agreement.
6. The Operator's staff
6.1 The Operator gives access to Client Personal Information only to staff and contractors who need it to provide the Service, and only to the extent needed.
6.2 Everyone with access is bound by written confidentiality obligations and has been told of their obligations under this agreement.
6.3 Production access is limited to named administrators, each using two-factor authentication. Their access is withdrawn when they no longer need it.
7. Security measures
7.1 The Operator will establish and maintain the security measures referred to in section 19 of POPIA: appropriate, reasonable technical and organisational measures to prevent loss of, damage to, unauthorised destruction of, and unlawful access to or processing of Client Personal Information.
7.2 As a minimum, these are the measures in Annexure B.
7.3 The Operator will:
identify reasonably foreseeable internal and external risks;
verify that its safeguards are effective, through automated testing, a security review at least once a year, and a backup restore drill at least once a quarter; and
update the safeguards as risks change.
7.4 The Operator won't reduce the overall level of protection in Annexure B during the term.
8. Security compromises
8.1 If the Operator becomes aware of a Security Compromise, or has reasonable grounds to suspect one, it will notify the Responsible Party's Information Officer (Annexure D) immediately, and in any event within 24 hours (section 21(2) of POPIA). It will use the form in Annexure E, or give the same information.
8.2 The notice will state, as far as it is then known:
the nature of the Security Compromise;
the categories and approximate number of data subjects and records affected;
its likely consequences;
the measures taken or proposed to contain it and reduce its effects; and
a contact person at the Operator.
8.3 Information not known at first will be given as soon as it becomes available.
8.4 The Operator will:
take reasonable steps to contain the Security Compromise and preserve evidence;
keep the Responsible Party updated; and
give reasonable help with the Responsible Party's own notifications to the Information Regulator and data subjects under section 22 of POPIA.
8.5 The Operator won't notify the Information Regulator or data subjects about Client Personal Information on the Responsible Party's behalf without its written agreement, unless the law requires it.
9. Sub-operators
9.1 The Responsible Party authorises the Operator to use the Sub-operators listed in Annexure C.
9.2 The Operator will give the Responsible Party at least 30 days' written notice before adding or replacing a Sub-operator. The Responsible Party may object on reasonable grounds within that period. If the parties can't resolve the objection, the Responsible Party may end the Main Agreement for the affected part of the Service, without penalty.
9.3 The Operator will bind each Sub-operator in writing to data protection obligations no less protective than those in this agreement.
9.4 The Operator remains responsible to the Responsible Party for each Sub-operator's processing of Client Personal Information.
10. Transfers outside South Africa
10.1 Some Sub-operators process Client Personal Information outside the Republic of South Africa. Annexure C states where.
10.2 The Operator will transfer Client Personal Information outside the Republic only as section 72 of POPIA permits. In particular, the recipient must be subject to a law, binding corporate rules or a binding agreement that provides an adequate level of protection substantially similar to the conditions for lawful processing in POPIA, including rules on onward transfer.
10.3 On request, the Operator will give the Responsible Party a copy, or a summary, of the safeguards it relies on for each transfer.
11. Data subject requests
11.1 If the Operator receives a request, objection or complaint from a data subject about Client Personal Information, it will forward it to the Responsible Party within 2 Business Days and won't respond itself, except to acknowledge receipt.
11.2 The Operator will help the Responsible Party meet its obligations to data subjects, including access, correction, deletion and objection. Where the Service has a function for this, such as exporting, correcting or archiving records, the Operator will make it available. Where it doesn't, the Operator will act on the Responsible Party's written instruction within a reasonable time.
12. Information Regulator
12.1 Each party will tell the other promptly about any inquiry, investigation, assessment or enforcement notice from the Information Regulator concerning Client Personal Information, unless the law forbids it.
12.2 The Operator will co-operate reasonably with the Responsible Party in responding.
13. Driver location information
13.1 The Operator processes drivers' location information only as described in Annexure A. In summary:
only while a driver has set themselves On duty;
only after the driver has seen the in-app notice explaining what is collected;
with a position recorded when a driver presses the panic button; and
deleted after 30 days.
13.2 Each viewing of a driver's route is recorded in the Service's audit log.
13.3 The Responsible Party is responsible for:
its lawful basis for processing its drivers' location information;
informing its drivers, including through workplace policies; and
deciding who in its organisation may view routes.
14. Retention, return and deletion
14.1 The Operator keeps Client Personal Information only for as long as needed to provide the Service or as the Responsible Party instructs, in line with the periods in Annexure A.
14.2 When the Main Agreement ends, or earlier on written instruction, the Operator will:
within 14 days, give the Responsible Party an export of Client Personal Information in a commonly used electronic format; and
within 30 days after that, delete Client Personal Information from the live Service.
Backup copies are deleted as they expire under the backup cycle in Annexure B. Until then, they are kept secure and aren't used.
14.3 The Operator will confirm deletion in writing.
14.4 Clause 14.2 doesn't apply to information the Operator must keep by law. That information stays subject to this agreement.
15. Records and audit
15.1 The Operator will keep records of its processing of Client Personal Information. On request, it will make available the information reasonably needed to show that it complies with this agreement. This includes:
extracts from the Service's audit log;
the latest security review and backup restore drill results; and
the current Sub-operator list.
15.2 Once in any 12-month period, on at least 30 days' written notice, the Responsible Party, or an independent auditor bound by confidentiality, may audit the Operator's compliance during business hours. This is at the Responsible Party's cost, and arranged so as not to disrupt the Service or other clients. An audit may also be held at any time after a Security Compromise, or if the Information Regulator requires one.
16. Liability
16.1 Each party is liable to the other for damage caused by its breach of this agreement or of POPIA, subject to the limits in the Main Agreement.
16.2 Guidance: insert the cap from the Main Agreement, and the attorney's carve-outs, for example fines and wilful misconduct. […]
17. Breach
If a party breaches this agreement and doesn't remedy the breach within 10 Business Days of written notice, the other party may claim specific performance or damages, or end this agreement and the Main Agreement on written notice. This doesn't affect its other rights. A breach that causes or is likely to cause a Security Compromise must be remedied immediately.
18. Termination
This agreement ends only when clause 14 has been complied with. Clauses 5, 8, 14, 15, 16 and 19 survive termination.
19. Disputes
19.1 The parties will first try to resolve any dispute through senior representatives within 10 Business Days of written notice of it.
19.2 If they can't, the dispute will be referred to [arbitration under the rules of the Arbitration Foundation of Southern Africa, in Johannesburg / the courts of South Africa].
19.3 Either party may approach a court for urgent relief at any time.
20. Notices
20.1 Notices are given in writing to the addresses in Annexure D, and may be given by email.
20.2 A notice sent by email is received on the next Business Day after it is sent, unless the sender gets an automated message that it wasn't delivered. Security Compromise notices under clause 8 also go by email to the Information Officer, and by phone where possible.
20.3 Either party may change its notice details by notice to the other.
21. General
21.1 Precedence. If this agreement conflicts with the Main Agreement on the processing of personal information, this agreement prevails.
21.2 Entire agreement. This agreement, with the Main Agreement, is the whole agreement on its subject.
21.3 Variation. A change to this agreement is valid only if it is in writing and signed by both parties. Updates to Annexure C under clause 9.2 are the exception.
21.4 Severability. An invalid provision is severed and the rest remains in force.
21.5 No waiver. A relaxation or indulgence isn't a waiver.
21.6 Law. The laws of the Republic of South Africa govern this agreement.
21.7 Signature. This agreement may be signed in counterparts and by electronic signature, as provided for in the Electronic Communications and Transactions Act 25 of 2002.
Signatures
| For the Responsible Party | For the Operator |
|---|---|
| Name: […] | Name: […] |
| Capacity: […], who warrants their authority | Capacity: […], who warrants their authority |
| Signature: | Signature: |
| Date and place: […] | Date and place: […] |
Annexure A: Processing details
Purpose: managing the Responsible Party's fleet. That covers:
dispatching jobs;
keeping vehicles and drivers legal (licences, permits, roadworthy and disc expiries);
recording fuel, defects, repairs and pre-trip checks;
emergency and help requests from drivers;
proof of delivery;
preparing information for invoicing;
costs reporting; and
keeping an audit trail of actions.
Nature of processing: collection, recording, storage, organisation, retrieval, use, display to authorised users, export at the Responsible Party's request, and deletion.
Strike any category below that doesn't apply to this client.
| Data subjects | Personal information | Retention in the Service |
|---|---|---|
| The Responsible Party's staff who sign in | Name, work email, role, password (stored as a salted hash), two-step sign-in secret (encrypted) and backup codes (hashed), sign-in history, actions recorded in the audit log | While the account exists. Audit entries can't be edited or deleted, and are kept for the life of the Responsible Party's account unless agreed otherwise |
| Drivers | Name, mobile number, employee number, ID number, driving licence and professional driving permit details and expiry dates, uploaded licence and medical documents, duty status, jobs, fuel and defect reports, pre-trip checks, panic and help requests, comments and delay reports | While the Responsible Party keeps the driver record. Documents until the Responsible Party deletes them |
| Drivers: location | Position, speed and accuracy, only while On duty; position with each panic alert; positions from the Traccar Client app if the driver sets it up | 30 days, then deleted automatically |
| The Responsible Party's customers and their contacts | Customer name, account number, VAT number, delivery addresses, name of the person who signed for a delivery, signature and photographs on proofs of delivery | While the Responsible Party keeps them |
| Emergency contacts | Name and phone number of the Responsible Party's emergency contact and armed response provider | While set in the Service |
| Drivers' phones (on the device only) | Session tokens, the last jobs list, and records waiting to send without signal | Until the driver signs out. Unsent records until they are sent or deleted |
Special personal information:
None is intended.
Uploaded medical certificates may contain health information. The Responsible Party will limit who uploads and views them. The Service limits documents filed against a driver to people who manage driver records.
Children: none intended.
Annexure B: Security measures
1. Separating clients
Each client's records are separated in the database by row-level security on every table holding client data.
The application connects with a restricted database role. Its health check fails if that role could skip the separation.
Automated tests confirm that one client can't read or change another's records through any part of the Service.
2. Access control
Every user signs in with a password and a time-based code from an authenticator app (two-step sign-in), drivers included.
Five wrong passwords or codes lock the account for 15 minutes. Repeated attempts from one network address are slowed.
Sessions expire. Signing out, deactivating a user or resetting a password ends that user's sessions immediately.
Each role can see and do only what its job needs, enforced on the server for every request. Drivers see only their own work.
Passwords are stored only as salted hashes. Authenticator secrets are encrypted. Backup codes are stored only as hashes, and each works once.
3. Transmission
All traffic uses HTTPS (TLS), with HTTP Strict Transport Security.
The web application uses a strict content security policy and refuses to be framed.
4. Integrity and accountability
An audit log records who did what and when, with before-and-after values for important changes.
The application can't change or delete audit entries: database permissions and a database trigger both refuse it.
Corrections to fuel records and invoice marks keep the earlier values and the reason given.
5. Files
Only images, PDF, spreadsheet, Word and text files are accepted, with size limits. Each file is checked by its content as well as its name.
Files are stored under random names, and released only to users authorised to see them, as downloads.
6. Location information: collected only while On duty and after the in-app notice; deleted after 30 days; route viewing recorded.
7. Availability and recovery
The database provider keeps continuous point-in-time backups for [retention window].
The Operator runs a backup restore drill at least once a quarter: it restores the production database into an isolated, temporary database and verifies every table.
8. Development and operations
Source code is kept in a private repository. Every change passes an automated test suite, including security and isolation tests, before it is deployed.
Secrets are held in the hosting providers' secret stores, never in source code.
Dependencies are checked for known vulnerabilities.
Uptime is monitored.
Logs strip passwords, tokens and similar values.
9. People: production access is limited to named administrators with two-factor authentication on every administrative account.
Known limitation, disclosed to the Responsible Party: uploaded files aren't currently scanned for malware.
Annexure C: Approved sub-operators
Current as at [date of signature].
| Sub-operator | Processing | Location |
|---|---|---|
| Cloudflare, Inc. | Hosting of the web application and application servers; storage of uploaded files; scheduled maintenance tasks | Global network; storage region […] |
| Neon (Databricks, Inc.) | Database hosting and backups | Frankfurt, Germany (AWS eu-central-1) |
| Unitpost | Sending service emails (recipient name and address, message content) | […] |
| Google (Firebase Cloud Messaging), Apple, Mozilla, Microsoft | Delivering phone and computer notifications to users who switch them on (job reference, driver, vehicle and customer name) | The provider's network |
| GitHub, Inc. | Source code hosting and deployment. During the quarterly backup restore drill, a temporary copy of the database exists for a few minutes on a GitHub-hosted server, which is then destroyed; nothing is kept | United States |
Not sub-operators: map images (OpenStreetMap) and map links (Google Maps) are opened by the user's own browser. They receive the map area being viewed, not records from the Service.
Annexure D: Contacts and Information Officers
| Responsible Party | Operator | |
|---|---|---|
| Information Officer | [name] | [name] |
| Information Regulator registration number | […] | […] |
| Deputy Information Officer | [name, or none] | [name, or none] |
| Email for notices (including Security Compromises) | […] | […] |
| Phone, for urgent matters | […] | […] |
| Physical address for legal notices | […] | […] |
| Support contact and hours | n/a | […] |
Annexure E: Security compromise notice
Sent by the Operator to the Responsible Party's Information Officer under clause 8. Send what is known within 24 hours; complete the rest as it becomes known.
| To (Information Officer) | […] |
| From (Operator contact, phone) | […] |
| Date and time of this notice | […] |
| When the compromise happened, or is believed to have happened | […] |
| When the Operator became aware of it | […] |
| What happened | […] |
| Personal information affected (categories) | […] |
| Data subjects affected (categories, approximate number) | […] |
| Records affected (approximate number) | […] |
| Likely consequences for data subjects | […] |
| Steps taken to contain it and reduce its effects | […] |
| Steps proposed, with dates | […] |
| Is it still continuing? | Yes / No / Not yet known |
| Has anyone else been told (police, Information Regulator, data subjects)? | […] |
| Next update by | [date and time] |
Template prepared from the attorney-reviewed draft of 31 October 2026. Re-check with the attorney if POPIA, its regulations, or the Service's processing changes materially.