Set a retention and access policy for POD images and consignee details

Why "keep all POD photos and consignee records accessible forever" creates unnecessary risk

Over the past five years, logistics operations across India have digitised proof of delivery at massive scale. Every day, millions of smartphone photos showing residential doorways, shopfronts, rubber-stamped invoices, recipient signatures, gate registers and sometimes personal identity snippets are uploaded into TMS buckets alongside consignee names, exact GPS coordinates and mobile phone numbers. In most systems, once that data lands in storage, it stays live forever: a public SMS tracking link sent three years ago still renders the consignee's address and delivery photo, and any call-centre agent or third-party broker login can search historical consignee mobile numbers across the entire database.

Retaining personal and commercial delivery records without lifecycle controls creates a dual exposure. First, under data-protection principles reflected in the MeitY — Digital Personal Data Protection Rules 2025, personal data should be retained only so long as necessary to fulfil the specified purpose or comply with legal obligations, and protected by reasonable security safeguards. Second, as highlighted in the OWASP — API Security Top 10 2023, long-lived public tracking URLs and overly broad internal search endpoints are prime targets for automated scraping.

At the same time, a logistics company cannot blindly delete every POD after thirty days: B2B freight settlement, GST/tax documentation, customer contract SLAs, insurance claims and security log directives—such as the framework discussed in the CERT-In — Cyber Security Directions FAQs—create legitimate retention requirements. The solution is a tiered lifecycle policy agreed across Operations, Finance, Legal and Information Security.

Separate the four distinct purposes embedded in a "POD record"

A single delivery record often bundles data elements that serve very different business and legal purposes:

1. Live customer & consignee delivery confirmation (Days 0 to 14–30 post-delivery): The consignee or shipper checks that the parcel or pallet arrived, views the delivery timestamp and raises any immediate shortage or non-delivery query.
2. B2B freight billing and commercial contract audit (Contractual settlement & audit window): Finance and client procurement verify the signed lorry receipt (LR) or commercial challan against the freight invoice and contractual SLA audit clause.
3. Active shortage, damage, insurance or legal dispute (Duration of dispute / legal hold): Claims, quality and legal teams preserve original high-resolution photos, custody timestamps and communication logs until the claim or proceeding is formally closed.
4. Statutory tax, accounting and cybersecurity log obligations: Accounting vouchers, tax invoice records and system access logs retained for the periods mandated by applicable Indian statutes and regulatory directions, as confirmed by qualified legal and tax counsel.

Once you separate these four purposes, you realise that expiring broad operational and public access is completely different from destroying an accounting voucher. You can revoke public tracking links and mask individual residential contact details on closed B2C orders while keeping commercial B2B accounting evidence locked in a restricted archive.

Illustrative example: applying a lifecycle policy across 1,000 historical POD records

Consider a logistics operator reviewing a cohort of 1,000 historical delivery records that have reached the company's 90-day post-delivery policy review boundary. Instead of applying a crude "keep everything open" or "delete everything" rule, the lifecycle engine classifies the 1,000 records across three policy states based on shipment type, billing settlement status and open claims flags.

The lifecycle reconciliation accounts for every record in the 1,000-shipment review:

• 720 closed B2C deliveries (72%) have their public tracking links expired and personal contact fields masked/purged in line with the agreed retention schedule, eliminating unnecessary exposure of residential doorstep data.
• 210 B2B commercial shipments (21%) move out of general dispatch visibility into a restricted Finance and Audit archive to satisfy commercial billing and statutory record-keeping rules.
• 70 disputed or claim-linked shipments (7%) are protected by an explicit hold flag so automated cleanup jobs cannot touch them (720 + 210 + 70 = 1,000).

Stop collecting unnecessary personal data at the doorstep in the first place

The easiest POD privacy problem to solve is the data you never needed to capture. Review your driver delivery app workflow with Operations and Legal:

• Avoid capturing photos of government ID cards at the doorstep unless a specific regulated product or high-value contractual workflow legally requires identity verification—and where verification is required, use masked confirmation or a verified OTP/token rather than storing raw photographs of Aadhaar or PAN cards in a general POD image bucket.
• Frame delivery photos on the parcel and label, not people's faces or home interiors: Train and prompt delivery associates (and configure in-app camera guides) to photograph the sealed carton label and placement location rather than taking selfies with recipients.
• Mask phone numbers via call-bridge during delivery: Use virtual number masking between delivery riders and consignees so the rider's personal phone does not retain a permanent local address book of customer mobile numbers after the shift ends.

Protect public tracking links and internal search from enumeration

While a shipment is in transit and during its immediate post-delivery window, customers need convenient status access. Design that access so convenience does not become a bulk data leak:

1. Unguessable, time-limited tracking tokens: If you send an SMS or WhatsApp tracking link, use a cryptographically random token that expires a set number of days after confirmed delivery, and display only city/hub progression and masked recipient initials on the unauthenticated view. Require a secondary verification step (such as post-code or authenticated login) before displaying full street addresses or downloadable POD images.
2. Rate-limit and audit internal call-centre lookups: A support agent legitimately looks up one shipment at a time while handling a ticket. Following the controls in the OWASP — API Security Top 10 2023, block wildcard exports on the support screen, log every POD view with the agent's user ID and ticket reference, and alert security if an account queries an abnormal volume of historical consignee records.

Next actions

1. Map every field and attachment in your current POD packet (recipient name, phone, GPS, signature, photo, commercial LR) against its specific operational, contractual and statutory retention purpose with Legal and Finance.
2. Configure unauthenticated SMS/web tracking links to mask street-level consignee PII and expire automatically once the post-delivery query window closes.
3. Implement an explicit Claims / Legal Hold flag on shipment records that overrides automated archival or deletion jobs until released by an authorised owner.
4. Remove historical closed shipments (>90 days) from general dispatcher and call-centre search views, restricting archival lookup to authorised Finance, Claims and Audit roles.