Why a green verification result has an expiry date

Picture Anita, a Mumbai society secretary signing off worker badges. The decision to trust a stranger inside a home, an office, or a society is made dozens of times each week across Indian cities — and almost none of those decisions are backed by a verification record that answers the basic questions: who said this person is who they claim to be, how recently, and what happens if the record turns out to be wrong. Why a green verification result has an expiry date is the topic of this article, but the question underneath every paragraph here is the same: how does a household, society, or SMB move from gut-feel to a documented, consent-backed trust loop without turning verification into document hoarding or surveillance theatre.

India's Digital Personal Data Protection Act has changed the operating rules. Verification result expiry recency is no longer a one-time exercise the requester runs in private. It is a workflow with five visible surfaces — purpose, consent, source, recency, and grievance — and every one of those surfaces is auditable. PRAMAAN treats those five surfaces as product, not policy. This piece walks through what that looks like in practice for Anita's situation, what operators should verify against current official sources, and what households and operators can do today.

Under DPDPA 2023, every personal-data processing operation needs four things before it begins: a written purpose, a notice to the data principal in a language they understand, a recorded consent, and a published grievance officer. For verification specifically, the purpose has to be specific — 'background check for onboarding a domestic worker into Block B' is acceptable; 'general due diligence' is not. The notice has to be served before the data flows, not after.

The next layer is what the requester does after the data lands. Consent receipts must be stored close to the transaction, not buried in a privacy policy. Source category must be visible — if a document came from an issuing authority's API versus a self-uploaded photograph, the requester needs to know which. Recency stamps must accompany every result so a year-old 'green' check is not mistaken for a current one. And the data principal must have a working route to view, correct, erase, nominate, or grieve — not buried four clicks deep on a help-centre page.

Most verification result expiry recency workflows in India today miss at least two of those surfaces. A photocopy of an ID gets emailed, sometimes screenshotted into a WhatsApp group, and then never refreshed. A consent checkbox is treated as a one-time formality rather than an ongoing relationship. When something goes wrong, the person who was verified often has no clear route to dispute the result. The DPDPA framework changes the cost of getting this wrong — and the next 18 months will see operators forced to rebuild these surfaces or pay the price.

PRAMAAN's approach to verification result expiry recency starts with a deliberate inversion: instead of asking the verified person to hand over raw documents to every new requester, the worker, vendor, tenant, or partner carries a portable, consent-backed badge. The badge holds verification status, source category, recency, and renewal cadence — but never raw documents. A new requester scans the badge, sees the status, and the verified person controls what gets shared in that moment.

This is not a single check. It is a renewable, revocable workflow. Anita's newly-hired helper is verified once through an approved partner integration, then re-verified on a calendar — every six months, every twelve months, depending on the risk profile of the role. If the helper leaves a job after a disputed incident, the next household sees the renewal-due flag at the gate. The helper, in turn, retains the right to see who scanned their badge, when, and for what purpose.

For operators — SMBs, platforms, RWA committees — the same loop scales. Vendor onboarding gets a portable trust layer that survives staff rotation. Delivery and field-service teams get a badge readable at the gate without an app install. Society guards stop maintaining stacks of photocopied IDs in registers that nobody reads. Every scan generates a receipt; every receipt is auditable; every audit respects the verified person's rights under DPDPA.

Consider the typical first-month experience of an Indian household that switches from photocopy-based verification to a renewable badge. The number of separate documents the household holds drops from seven or eight per worker to zero. The number of times the household has to re-verify the same worker for a new society role drops from three or four per year to one. The number of consent records held by the household grows from zero to one per active worker — and each one is a working URL the worker can revoke. The administrative burden on the household drops. The fairness to the worker rises.

That is not theoretical. In societies that have started piloting PRAMAAN badges across single towers, the most common feedback in the first two weeks is not about technology — it is about how much less paper the gate has to handle and how much fewer arguments happen at the door. The verification workflow stops being a point of friction and becomes a quiet operational background.

A renewable badge does not eliminate every risk. Source records can still conflict. A worker who clears verification on day one can change behaviour on day three hundred — verification is a snapshot, not a prediction. Source rails can be slow or briefly unavailable. A poorly-designed flow can still funnel workers into manual-review purgatory with no SLA and no escalation owner. These failure modes are real and the answer is not to pretend they are not.

The answer is to design for them. Manual review must be a named state with an owner and a clock. Disputed results must have a published route the verified person can use without legal representation. Rail failover must be transparent — when a source is slow, the user should know, not just see a spinner. And the entire posture should sit on a public trust page, not in a sales-only document. PRAMAAN publishes its grievance officer, residency, sub-processor list, and breach disclosure route on the trust page specifically to invite this scrutiny.

For a household evaluating verification result expiry recency this week, the first move is operational, not technological. Write down the specific purpose for each verification you currently run — 'cook entering home weekdays 8am-10am' is different from 'one-time furniture installer'. Match the depth of check to the actual risk. Avoid asking for documents over WhatsApp; use a controlled flow instead. Save the consent receipt and the result, not the raw documents. Set a renewal date on your calendar — verification ages.

For an SMB or RWA, the move is structural. Name the person who owns verification end-to-end (not the finance team, not the IT team — a named owner). Publish your retention policy on your own website. Train the gate team on what to scan and what to do when the scan returns a yellow flag. Build a dispute path that any worker can use. Measure how many manual-review cases stay open past 48 hours, and treat that number as a leading indicator of how fair your workflow is.

The shift from photocopy verification to a renewable, consented badge is one of the operational changes the next two years will demand of Indian households, societies, and SMBs. Anita's experience hiring a helper this morning is the same workflow that decides whether a delivery agent enters a residential tower this evening, whether a contractor signs in at a campus tomorrow, whether a tenant moves into a building next month. PRAMAAN's role is to make that workflow boring — readable, renewable, respectful of rights on both sides. Trust earned this way compounds. Trust hoarded never does.