Government and public services

Sector regulation

The Central or State body must identify its exact statutory function, applicable DPDP provision, service rule, records law and delegated processor arrangement. “Government purpose” is not a general-purpose processing ground, and a contractor does not inherit public authority merely by operating the portal.

Service and data map

Typical services include benefits, licences, certificates, tax/fee collection, grievance, inspection, law enforcement support, health, education, employment and regulator portals. Data can include identity, family/household, eligibility, financial, health, disability, caste/community, location, biometric/authentication result, grievance and disciplinary information.

flowchart LR
  P[Person / authorised representative] --> CH[Portal, assisted centre, office, call centre]
  CH --> ID[Identity / eligibility service]
  CH --> CASE[Department case system]
  CASE --> REG[Authoritative registers]
  CASE --> PAY[Payment / benefit rail]
  CASE --> V[Cloud, integrator and service providers]
  CASE --> ARCH[Records / archive]
  CASE --> ANA[Approved statistics / research]

For each arrow capture the legal owner, purpose, minimum fields, disclosure authority, system of record, location, retention trigger, processor/subprocessor, rights route and exception.

Processing assessment

Map each purpose separately to consent or a specific section 7 use and to any other enabling law. Record the provision and the facts that satisfy it. Do not:

• bundle an optional communication, survey or reuse into access to an essential service;
• treat a submitted application as permission for unrelated profiling;
• use one department’s statutory power as another department’s disclosure authority;
• infer that an exemption removes security, governance or contract risk beyond its exact scope.

Notice remains operationally valuable even where the assessed ground is not consent: it explains the purpose, data route, contact, rights/grievance path and any lawful limits.

Identity and assisted access

Use the least intrusive assurance that resolves the risk. Support representatives, guardians, offline applicants, disability accommodations and people without a smartphone or English literacy. An Aadhaar authentication use case requires its own lawful approval and UIDAI ecosystem controls; do not copy the DPBI’s voluntary portal approval into another service. Store the authentication result and transaction reference where sufficient, not identity artefacts by default.

Records, disclosure and erasure

Configure schedules per record series: application, decision, payment, appeal, inspection, grievance, correspondence, audit/security log and archival record. Each schedule names its source, trigger and disposal authority. On an erasure request, identify the exact statutory/records hold, restrict further use, explain the scoped outcome and delete all portions not covered by the hold.

Inter-departmental or public disclosure requires a recorded authority and minimum field set. Open-data publication needs re-identification and small-cell review; removing direct names alone is not reliable anonymisation.

Procurement and operating model

Contracts and architecture must make the public body’s accountability and the provider’s permitted processing explicit: instructions, staff access, localisation where separately required, subprocessors, security, incident cooperation, audit, portability, exit, deletion and source-code/ configuration continuity. Privileged support uses time-bound customer-approved access with audit.

The control plane must operate in government/community cloud, private cloud or on-premises without hidden telemetry or mandatory vendor access. Exportable evidence and offline incident/rights runbooks preserve service during network or supplier failure.

Minimum configuration

Configuration	Required detail
authority profile	ministry/department/body, enabling sources, delegated officers, geography
service map	channels, assisted access, eligibility, authoritative registers, recipients
purpose register	exact DPDP ground, other authority, minimum data, prohibition/exception
identity ladder	anonymous, account, document check, representative, approved authentication
records pack	series, trigger, schedule source, archive/hold, disposal approval
provider pack	role, instruction, location, subprocessor, support, incident and exit terms
public interface	notice, contact, accessible grievance/rights route, status and receipt
incident pack	DPDP/CERT-In/department clocks, contacts, approval and manual fallback

Integration workflow

Begin with inventory and read-only case/register connectors. A request creates scoped tasks against authoritative systems; correction is approved by the data-owning officer; disclosure and deletion use signed purpose-bound instructions. Where no safe API exists, generate a checker-approved task and reconcile the receipt. Never invent a regulator or government API.

Evidence and oversight

Retain applicability decisions, source versions, notices, field minimisation, access reviews, processor instructions, disclosure approvals, request outcomes, retention exceptions, incident clocks, notification receipts, restoration/re-deletion tests and exit certificates. Separate security observability from employee/citizen profiling.

Counsel and programme questions

• Which DPDP ground and enabling law apply to each service purpose and disclosure?
• Which records schedule, archive rule or litigation/investigation hold governs each series?
• Is Aadhaar or another identity mechanism authorised, voluntary where required and proportionate?
• Which entity is Fiduciary, Processor or independent Fiduciary in shared platforms and missions?
• Which national, State, departmental, sector, procurement and critical-system duties overlay the service?
• What accessible offline route exists when the portal, phone, identity method or language fails?