DPDP for logistics, couriers, ride-hailing and delivery platforms

Logistics and mobility move people and parcels, but what they really handle is location. A courier knows where a person lives, when she is home and what she ordered. A ride-hailing app knows where she goes every morning and who she travels with. A fleet platform knows how every driver brakes, where he stops and for how long. Add phone numbers passed to riders, doorstep photos and driver ID files, and this sector holds some of the most revealing data in the economy.

The risk sits in three places. Exposure at the edge: thousands of riders and drivers who see names, numbers and addresses on their phones. Location kept too long: trip histories and GPS trails nobody deletes. Unclear roles: couriers that treat an e-commerce client’s recipient list as their own marketing database. This guide applies the Data Fiduciary playbook to logistics, mobility and delivery.

Are you a Data Fiduciary, a processor, or both?

• Courier or 3PL delivering for e-commerce clients: for the recipient names, addresses and phone numbers a marketplace or brand sends you, you are usually that client’s Data Processor. You may use them only to deliver, under a valid contract (section 8(2)). If you message those recipients to sell your own services, you have made yourself a Data Fiduciary for that use, with no ground for it.
• Courier serving walk-in or app customers directly: you are the Data Fiduciary for senders, and for recipient details the sender gives you to complete the delivery. Use recipient data only to deliver and erase it when the shipment closes.
• Ride-hailing, bike-taxi or auto aggregator: you are the Data Fiduciary for riders and for drivers. Your map provider, payment gateway, telephony masking vendor, background-check agency and cloud host are your processors.
• Quick-commerce or food-delivery platform: you are the Data Fiduciary for customers and for the riders on your network. If riders come through a staffing agency or a fleet partner, write down who is the fiduciary for rider onboarding, tracking and payments.
• Fleet operator and telematics provider: a company running its own fleet is the Data Fiduciary for its drivers’ telematics and dashcam data. The telematics or dashcam vendor is a processor unless it uses the data for its own products, benchmarking or model training, in which case it is a fiduciary for that use.
• School and staff transport operators: you are usually a processor for the school, company or crèche that engages you. A transport operator engaged by an educational institution, crèche or child day-care centre may track children’s location during travel to and from it, for their safety, without verifiable parental consent (Fourth Schedule Part A item 5). Nothing beyond that.

The data you hold

Data category	Where it usually lives	Typical purpose	Sensitivity	Typical retention
Recipient name, address, phone, landmark, geo-pin	Client manifest, TMS, rider app, label printers	Delivery	High (home location, routines)	Until delivery and returns close, plus the client’s instructions
Sender details and shipment contents description	Booking system, counter, invoices	Booking, billing, customs	Medium to high (contents can reveal health or religion)	Accounting, tax and customs law minimums
Proof of delivery: photos, signatures, OTPs, recipient name	Rider app, POD server, client portal	Dispute resolution	Medium to high (photos of people, homes, ID)	Through the client’s dispute window; short
Rider and passenger accounts, payment tokens	App backend, payment gateway	Rides, billing	Medium to high	While the account is active
Live location and trip history (pickup, drop, route)	Trip service, maps, data warehouse	Matching, ETAs, fares, safety, disputes	High (where people live, work, worship and stay overnight)	Live data minutes; trip history short, then aggregated
Masked call and chat logs, call recordings	Telephony vendor, support tools	Coordination, safety, support	Medium to high	Short unless a complaint is open
SOS and safety incident records	Safety team, police correspondence	Passenger and driver safety	High	Long enough for investigations and claims
Driver and rider KYC (licence, vehicle RC, PAN, bank, address proof, photo)	Onboarding system, verification vendor	Onboarding, payouts, legal compliance	High	During engagement and as aggregator rules and tax law require
Police and background verification results	Verification vendor, onboarding system	Safety, aggregator compliance	High	Engagement period; keep the outcome, not the full report
Telematics: GPS trails, speed, harsh braking, idling, fuel	Telematics platform, fleet dashboard	Fleet operations, safety, insurance	High (continuous monitoring)	Short raw retention, longer aggregates
Dashcam and in-cabin video or audio	Device, vendor cloud	Safety, accident claims	High	Short rolling period, longer for an incident
Driver and rider performance, ratings, deactivations	Ops tools, data warehouse	Quality, allocation, deactivation decisions	High (decides livelihoods)	During engagement plus the dispute period
Gig-worker social security registration details	HR or partner ops, government portals	Statutory registration and contributions	High	As the social security law requires
Children’s data (school transport, teen riders, accompanied minors)	Transport app, school portal	Safe transport	High	Minimum; see section 9

Risk hotspots

1. Phone numbers on riders’ phones. Riders and drivers see recipients’ and passengers’ numbers, save them, and call or message later. Failure: harassment and stalking, and a disclosure that makes you liable for your network. Control: number masking for calls and chats, masking that expires when the delivery or trip closes, and no raw number in any rider or driver app.
2. Addresses that outlive the delivery. Manifests and rider apps keep full addresses for weeks. Failure: scraped or leaked address lists, and data that criminals use for targeted scams. Control: show the address only during the active task, purge it from devices on completion, and keep the full address on the server only as long as returns and disputes need.
3. Live location and trip history kept indefinitely. Trip logs show home, office, hospital visits and overnight stays. Failure: a single leaked trip table can expose a person’s whole life. Control: short retention for raw trip data, aggregation or coarsening after that, strict internal access with logged reasons, and no secondary use without consent.
4. Treating a client’s recipients as your own customers. Couriers market to recipients, build address databases across clients, or sell “address intelligence”. Failure: you step outside the processor role, have no ground, and breach your contract. Control: a written rule that client data is used only for that client’s deliveries, logical separation per client, and no cross-client enrichment without each client’s instruction and the person’s consent.
5. Proof-of-delivery photos. Riders photograph the recipient’s face, the inside of a home, a family member or an ID card. Failure: sensitive images stored long after any dispute window. Control: photograph the parcel at the door, not people; prefer OTP proof; blur faces; set a short retention period agreed with the client.
6. Driver and rider KYC files. Full Aadhaar copies, licences, bank details and police certificates for thousands of gig workers, often collected by local fleet partners on WhatsApp. Failure: identity theft at scale and a breach involving low-income workers. Control: DigiLocker or masked Aadhaar, an onboarding system instead of WhatsApp, keep the verification outcome rather than full reports, and contracts with fleet partners and verification agencies.
7. Telematics and in-cabin cameras as constant surveillance. Driver-facing cameras, audio recording and second-by-second GPS on drivers’ own vehicles or during off-shift hours. Failure: monitoring beyond any stated purpose. Control: tell drivers exactly what is recorded and when, switch tracking off outside shifts, prefer event-triggered clips over continuous recording, and keep raw data short.
8. Automated deactivation and penalties. Ratings, fraud scores and GPS anomalies decide whether a driver or rider keeps earning. Failure: decisions on inaccurate data, against section 8(3). Control: accuracy checks before acting, a human review for deactivation, and a correction channel for drivers and riders.
9. Safety data shared too widely. SOS recordings, trip-sharing links and incident files shared with police, insurers and internal teams. Control: written requests from police, sharing only what is needed, a register of disclosures, and expiry on trip-sharing links.
10. Children and accompanied minors. Teen riders on parents’ accounts, school-run trips, and parcels addressed to children. Failure: tracking or profiling children (section 9(3)) and processing without verifiable parental consent (section 9(1)). Control: adult-only accounts with a parent-managed child profile where you allow minors, real-time location for safety only, and no marketing or ad profiling.

Legal basis, purpose by purpose

Purpose	Basis	Notes
Delivering a client’s shipments	Your client’s ground; you act as processor under section 8(2)	Follow the client’s instructions; the client stays responsible (section 8(1)).
Booking and delivering a shipment for a direct customer	7(a)	The sender provides the data to get the parcel delivered. Use recipient data only for that delivery.
Matching a ride, fares, ETAs, in-trip tracking	7(a)	The rider asked for the ride. Keep tracking to the trip.
Number-masked calls and chats during a task	7(a)	Masking is a security measure under rule 6(1)(a).
SOS, trip sharing with contacts, safety response	7(a) for features the rider uses; 7(f) in a medical emergency; 7(h) in a disaster or breakdown of public order	Say how SOS data is used and shared before the rider needs it.
Driver and rider onboarding, KYC and background checks	7(a), and retention required by law where aggregator rules require checks; 7(i) for employees	Gig workers are not usually employees, so 7(i) may not apply to them.
Payouts, incentives, tax deduction	7(a), and retention required by law	Tax law sets minimum retention for payment records.
Gig-worker social security registration and data shared with the government	7(d) where a law requires disclosure to the State	Share only the fields the law or portal requires. Confirm the current requirement with counsel.
Telematics and dashcams for own employees	7(i)	Tell drivers what is monitored. Off-shift tracking is a different purpose.
Telematics and in-cabin cameras for gig drivers	Consent, or 7(a) where strictly part of the service the driver signed up for	Continuous audio or driver-facing video needs a clear, separate yes.
Fraud prevention, fake bookings, payment abuse	17(1)(c) for preventing offences, otherwise consent	Document it; do not reuse fraud scores for marketing.
Responding to police and court requests	7(d), 7(e), and 17(1)(c)	Take written requests; section 11(2) means you need not disclose such sharing in an access reply.
Marketing rides, offers and subscriptions	Consent, per channel	Also follow TRAI’s commercial-communication rules (TCCCPR).
Using trip or delivery data for product analytics, AI models or data products	Consent, unless aggregated so people cannot be identified	Location data is very hard to anonymise; treat it as personal unless proven otherwise.
School transport location tracking	Fourth Schedule Part A item 5 (transport engaged by the institution)	During travel to and from the institution, for safety only.

Notices and consent: getting the screens right

Channel	Do	Don’t
Rider and customer app	Show a short notice at sign-up itemising account, location and payment data; ask for location permission when booking, with “while using the app” as the default.	Ask for “always” location, contacts or SMS access at install.
Driver and rider partner app	Give a notice at onboarding listing KYC, tracking, telematics and rating data, and what decisions they drive.	Bury tracking and camera monitoring in the partner terms.
Counter and franchise booking points	Display a printed notice and offer a QR code to the full notice; record recipient data only for the shipment.	Photocopy the sender’s ID unless a law requires it for that shipment.
Doorstep and delivery	Use OTP or parcel photos; tell the recipient why a photo is taken.	Photograph faces, homes or ID cards.
Call centre and support	Read a short notice before recording; send a link to the full notice.	Use support recordings to train models without a ground.
SMS and WhatsApp updates	Keep delivery and trip updates transactional; put promotions only in messages to people who opted in.	Add tracking-update recipients to promotional lists.
Field onboarding by fleet partners	Give partners a standard form and onboarding app with the notice built in.	Let local partners collect documents over WhatsApp.
In-vehicle cameras	Put visible stickers inside the vehicle and describe recording in the app.	Record audio silently.

Each notice must be readable on its own, itemise the data and the purposes, and give the link and other means to withdraw consent, exercise rights and complain to the Board (rule 3). Offer it in English and any Eighth Schedule language (section 5(3)). Driver and rider networks are multilingual; start with Hindi and the languages of your top cities, and make the onboarding notice available in all of them.

Other laws you must line up with

• Motor Vehicles Act, 1988 and the Motor Vehicle Aggregator Guidelines issued under it: aggregators must verify drivers, keep trip and safety records, provide safety features and share data with state authorities in specified cases. States adopt and modify the guidelines, so the requirements differ by state. Confirm the current requirement with counsel.
• Code on Social Security, 2020 and state gig-worker laws: registration of gig and platform workers and sharing of worker details with government portals and welfare boards. Several states have their own platform-worker laws with data-sharing duties. Confirm the current requirement with counsel.
• Labour codes, Shops & Establishments Acts, PF and ESI: records for employed drivers, warehouse staff and hub workers. See the employers and HR guide.
• Customs Act and courier import and export regulations: KYC and shipment records for international couriers.
• Consumer Protection Act, 2019 and the E-Commerce Rules, 2020: grievance handling for platform users, and dark-pattern rules that also affect consent screens.
• IT Act, 2000 and CERT-In Directions (2022): cyber incidents may need to be reported to CERT-In on a much shorter clock than the DPDP 72 hours. Confirm the current requirement with counsel.
• TRAI TCCCPR: consent and registration for promotional SMS and calls; transactional delivery messages are treated differently from promotions.
• Income-tax Act and GST: invoices, payouts and tax deducted at source set minimum retention for payment records.
• Your clients’ sector rules: banking, insurance and pharmacy clients may impose extra conditions on document and medicine deliveries through their contracts.

Retention and erasure

1. When the purpose ends (section 8(7)): a delivery and its return window close, a trip’s dispute window ends, or a driver leaves the network. Stop using the data and erase it, unless a law requires you to keep it.
2. The one-year minimum (rule 8(3)): keep the personal data, associated traffic data and logs of the processing for at least one year from the date of processing, for the Seventh Schedule purposes, then erase them unless another law requires more. Keep this copy restricted; it is not a licence to keep using trip histories.
3. As a processor: erase or return a client’s data when the contract or the client says so (section 8(7)(b)), and keep the one-year logs the client must ensure you retain (rule 8(3), illustration case 2). Agree in the contract what happens to data held for that year.
4. Legal holds: accident claims, police investigations, aggregator record-keeping duties, tax records and labour records each set their own periods. Hold the specific records, not the whole account.
5. Location and telematics: separate raw GPS trails from aggregates. Delete or coarsen raw data on a short cycle once rule 8(3) and any legal duty are met.
6. Third Schedule: a ride-hailing or delivery app is not in the Third Schedule as such. A quick-commerce or marketplace platform that is an e-commerce entity with 2 crore or more registered users in India must erase a user’s data three years after she last engaged, with a 48-hour warning (rule 8(2)), excluding data needed to access the account and virtual tokens such as wallet balances. See the e-commerce guide.
7. Devices and backups: purge manifests and photos from rider and driver phones at task completion, and make sure restored backups replay erasures.

Rights requests and grievances

• Channels: an in-app privacy section in both the customer and partner apps, a web form and an email address. Publish them with the identifier you need: the registered mobile, a booking ID, an AWB or tracking number, or a partner ID (rule 14(1)).
• Identity: an OTP to the registered mobile is usually enough. Do not ask drivers or riders for documents you do not already hold.
• Recipients of client shipments: where you are the client’s processor, pass the request to the client promptly and help it answer. Tell the person you have done so.
• Access (section 11): give riders a summary of trips, location data, payments and devices; give drivers a summary of KYC, tracking, ratings and deactivation records. List the fiduciaries and processors you shared data with: insurers, payment providers, verification agencies, fleet partners, and state authorities where a law required it. Sharing with police on a written request for an investigation is excluded (section 11(2)).
• Correction (section 12(2)): drivers and riders must be able to correct ratings errors, wrong trip records and KYC details, because these drive decisions about their earnings (section 8(3)).
• Erasure (section 12(3)): erase trip history, saved places and marketing data on request. Refuse what aggregator rules, tax law or an open claim require you to keep, and say what you kept and why.
• Grievances: publish a response period within the rule 14(3) ceiling of 90 days; 15–30 days is good practice. Partners’ data grievances should go to the same team, not only to driver operations.
• Contact person (rule 9): publish it in both apps and in every reply.
• Nomination (section 14): let riders and drivers nominate someone, which matters for drivers’ pending payouts and records.

Breach readiness

Likely scenarios:

• a rider app or partner API leaking recipient names, numbers and addresses
• a trip-history table exposed through a misconfigured warehouse or bucket
• a fleet partner’s WhatsApp groups of driver KYC documents leaked
• a telematics or dashcam vendor compromised
• an insider at a hub or call centre selling recipient lists to scammers
• account takeover of riders’ accounts with saved home and work addresses

Run-book:

1. Contain within hours: revoke API keys, cut off the compromised partner or device, rotate credentials, and take exposed storage offline.
2. Assess: which data, how many people, and which consequences: physical safety where home addresses and routines leaked, identity fraud from KYC documents, scam calls posing as delivery agents.
3. Tell your clients at once where you are their processor, with the facts they need for their own notices. Their 72-hour clock depends on you.
4. Notify affected people without delay where you are the fiduciary, through the app or registered contact, covering every point in rule 7(1): what happened, when and how much; the likely consequences for them; what you are doing; what they should do (for example, ignore calls asking for a “redelivery OTP”); and a contact.
5. Notify the Board without delay, then send the detailed report within 72 hours (rule 7(2)), including the events and reasons, mitigation, findings about the person who caused it, remedial steps and a report on the notices sent.
6. Report to CERT-In where its directions apply, and to the police where an insider or a crime is involved.
7. Learn: fix the root cause, tighten partner contracts, and retrain the hub or partner network involved.

The checklist

Phase 1: discover (days 0–30)

• [Leadership] Appoint a DPDP owner with authority over operations, the partner network and technology.
• [Legal] For every client contract, record whether you are a processor or a fiduciary for each data set.
• [Eng] Map every system that holds recipient, rider, driver or location data: TMS, trip service, rider and driver apps, warehouse, telematics, support tools, backups.
• [Ops] List what each rider or driver sees on their phone during and after a task.
• [Ops] Find where driver and rider KYC is collected outside your systems: fleet partners, WhatsApp, email, paper.
• [Eng] Measure how long raw GPS, trip history, POD photos and call recordings are actually kept today.
• [Legal] List processors and partners: maps, telephony masking, verification agencies, payment gateways, fleet partners, telematics, cloud, BPO.
• [Legal] Note what aggregator guidelines in each operating state, social security law, customs and tax law require you to keep or share.
• [DPO] Estimate the number of riders, recipients and drivers whose data you process, to judge the chance of SDF notification.
• [Ops] Identify where children appear: school transport, teen riders, accompanied minors.

Phase 2: design and build (days 31–90)

• [Legal] Assign a legal basis to every purpose using the table above, and stop purposes without one.
• [Legal] Write notices for the customer app, partner app, counters, support and in-vehicle cameras.
• [Ops] Translate notices into Hindi and the languages of your top cities; make the partner notice available in all 22 Eighth Schedule languages.
• [Eng] Mask all calls and chats between recipients, riders, drivers and passengers; expire masking at task close.
• [Eng] Show full addresses only during an active task and wipe them from devices on completion.
• [Eng] Separate each client’s shipment data logically and block cross-client joins.
• [Product] Switch location permission to “while using the app” by default and explain each permission at the point of use.
• [Eng] Set retention jobs for raw GPS, trip history, POD photos, call recordings and telematics.
• [Product] Change POD to OTP or parcel-only photos; blur faces where photos are unavoidable.
• [Ops] Move driver and rider onboarding to an in-app flow with DigiLocker or masked Aadhaar; stop WhatsApp document collection.
• [Ops] Keep the background check outcome and reference number, not the full report, once onboarding is decided.
• [Legal] Sign fleet-partner and verification-agency contracts with purpose limits, security, breach notice, erasure and one-year logs.
• [Product] Switch telematics and in-cabin recording off outside shifts; prefer event-triggered clips.
• [Ops] Add human review before deactivating a driver or rider, and a channel to dispute ratings and records.
• [Eng] Encrypt addresses, phone numbers and KYC files at rest; restrict warehouse access to named roles with logged reasons.
• [Security] Add MFA for hub, ops and support consoles and rate limits on tracking pages and partner APIs.
• [Eng] Keep access and processing logs for at least one year (rule 6(1)(e), rule 8(3)).
• [Legal] Offer clients a standard processor addendum: instructions, security, breach notice within hours, sub-processors, erasure, logs, audit.
• [Security] Set an internal target to tell clients about a breach within hours of discovery, and name who makes the call.
• [Marketing] Separate transactional updates from promotions; check consent before every promotional send.
• [Product] Expire trip-sharing links when the trip ends.
• [Product] For school transport, limit tracking to the journey and share it only with the institution and parents.
• [Product] Publish the privacy page: contact person, request channels, identifier needed, grievance period.
• [CX] Build a route to forward requests from client recipients to the right client.

Phase 3: operate (ongoing)

• [Ops] Audit a sample of rider and driver devices every quarter for leftover manifests and photos.
• [Legal] Review client and partner contracts and renewal dates every quarter.
• [Security] Run a penetration test every year on the apps, tracking pages and partner APIs.
• [Security] Run a breach drill every year, for example a leaked manifest, against your clients’ 72-hour clock.
• [CX] Review rights and grievance timelines every month.
• [Ops] Review deactivation disputes every month for patterns of bad data.
• [Ops] Train hub staff, riders and fleet partners every year on what they may keep and share.
• [DPO] Review new features, partners and data products before launch.
• [DPO] Keep evidence: notices, consent records, client instructions, erasure confirmations, police request letters.
• [Leadership] Re-assess the likelihood of SDF status each year as volumes grow.
• [Ops] Check every quarter that fleet partners have stopped collecting documents outside the onboarding app.
• [Eng] Confirm every quarter that retention jobs for GPS, trip history and POD photos ran and deleted what they should.

Where myconsentapp comes in

You need to	With myconsentapp	You still own
Separate what the service needs from marketing and analytics	Define purposes (rides, deliveries, safety features, offers, product analytics, partner sharing) once, each tagged consent or legitimate use with sensitivity and retention days. Consent purposes show as separate toggles, off by default, on the hosted consent page, widget or through the SDKs.	Designing your app flows.
Give drivers and riders a clear onboarding notice	Versioned notices, frozen per version, in English and all 22 Eighth Schedule languages, with machine-translation drafts flagged for review. Rights, withdrawal and Board-complaint text and your contacts are added automatically.	Reviewing translations and the content of the notice.
Record consent captured at a counter or by phone	Record consent captured elsewhere, marked as not verified by the person.	The counter or call process itself.
Prove a rider or driver agreed	A signed, hash-chained consent ledger, receipts with QR codes, a public verifier, and evidence packs per consent or per person.	Linking records to your user IDs.
Check before every promotional message or analytics job	The verify API returns not permitted immediately after a withdrawal. Signed webhooks and acknowledgements with overdue alerts make sure your systems act on it.	Calling it from your campaign and analytics pipelines.
Make processors stop and erase	A processor registry (maps, telephony, verification, fleet partners, telematics) with contract dates, expiry flags and per-processor webhooks. Erasure stays open until each confirms or you record an override. Record of processing exports as JSON, CSV or PDF.	Signing the contracts and enforcing them.
Run retention	Retention days per purpose, a retention job that ends access and alerts linked processors, and retention obligations (legal holds) shown in the notice.	Deleting rows in your trip, telematics and POD systems.
Handle requests from riders and drivers	A rights inbox with SLA timers for access, correction, erasure and grievances; nomination; erasure closes with a structured proof.	The answers, including deactivation disputes.
Handle child riders	An age gate and guardian verification through DigiLocker; tracking and ad purposes can never be marked child-safe.	Deciding whether minors may use the service.
Manage a breach	A breach register with the 72-hour clock, Rule 7 notices in English and Hindi, and Board intimation and report documents.	Detection, forensics and telling your clients.

Not included: myconsentapp does not mask phone numbers, scrub GPS data, run background checks or integrate with your TMS or fleet software out of the box; integration is through the API and webhooks. It is a proposed Consent Manager, not a security programme or legal advice.

Common mistakes

• Using recipient data from e-commerce clients to market your own services.
• Showing raw phone numbers to riders and drivers “because masking costs money”.
• Keeping every GPS ping forever because storage is cheap.
• Collecting driver Aadhaar copies over WhatsApp through local fleet partners.
• Photographing recipients’ faces or ID cards as proof of delivery.
• Deactivating drivers on automated flags with no human review or way to correct the record.
• Assuming 7(i) covers gig workers in the same way as employees.
• Promising clients a 72-hour breach notice, which leaves them no time to meet their own deadline.

Frequently asked questions

We deliver for 200 e-commerce brands. Are we a fiduciary or a processor? Usually a processor for each brand’s recipient data, because the brand decides why the data is used and you deliver on its behalf. You become a fiduciary for anything you decide to do with the data yourself. Write the role into each contract (section 8(2)).

Do we need consent to track a ride? Not for the trip itself. A rider who books a ride gives her location for that purpose, which fits section 7(a). Using trip histories for marketing, profiling or data products is a different purpose and needs consent.

Can we keep drivers’ trip data to defend against claims? Yes, for the claim. Section 17(1)(a) covers processing necessary to enforce a legal right or claim, and rule 8(3) requires a one-year minimum for logs. Keep the specific records under a hold, not everything forever.

Does 7(i) cover our gig riders? Section 7(i) covers employment. Most gig riders and drivers are engaged as partners, not employees, so rely on 7(a) for what they provide to join and work, on legal duties where aggregator or social security law requires checks or sharing, and on consent for monitoring beyond that. Confirm the position for your contracts with counsel.

Our e-commerce client wants breach notice within 6 hours. Is that a DPDP requirement? Not in those words. The client must intimate the Board without delay, then send the detailed report within 72 hours of becoming aware (rule 7(2)), and CERT-In may need notice sooner. A short contractual deadline for you is how the client meets those duties.

Can we track children on school buses? Yes, if a school, crèche or child day-care centre engages you. The Fourth Schedule lets you track children’s location during travel to and from the institution for their safety without verifiable parental consent. Any other use of that data still needs parental consent.

Are proof-of-delivery photos personal data? Yes, if a person, a home or a document can be identified in them. Photograph the parcel, not people, and keep the images only for the dispute window.