Field research

The Privacy Notice at the Bottom of the Form

What IRCTC, GSTN and EPFO reveal about India's public facing DPDP readiness

19 August 2026 · about 45 minutes · Research cutoff: 19 August 2026

A privacy policy can be completely accurate and still fail the citizen it is supposed to protect.

The reason is simple: the privacy policy describes the front door. The citizen experiences the entire building.

At 11:58 p.m., a passenger opens the Indian Railways ticketing portal. The train is almost full. The passenger enters a name, age, mobile number and email address, chooses a berth, pays and receives a confirmation on WhatsApp. It feels like administration, a ticket rather than a data protection event. But the transaction creates a trail that may involve multiple databases, payment infrastructure, messaging services, APIs, fraud controls and service providers.

The same pattern appears when a business files a GST return or an employee checks an EPFO account. The citizen sees one service. Behind it may be several departments, processors, authentication systems and privately operated technology layers, and the DPDP framework makes those relationships something an institution has to identify and govern.

That is why privacy readiness is not a page; it is an operating model. It means knowing what data exists, why it is processed, who can touch it, how long it is kept, how a citizen can exercise a right, and what happens in the first hours after an incident.

The implementation period is already running, but the regime does not commence as one block. The DPDP Act, 2023 and the DPDP Rules, 2025 use a phased commencement structure. The provisions in the eighteen month tranche, including the core processing, fiduciary, rights, security and enforcement provisions, are scheduled to commence on 13 May 2027. Separately, Rule 4, which governs registration and obligations of Consent Managers, is scheduled to commence one year after publication, on 13 November 2026. The statutory provisions establishing the Data Protection Board commenced earlier; that is a legal establishment milestone, not, by itself, proof that the Board is functioning as a fully operational enforcement mechanism. This is therefore neither a free pass nor a finished compliance regime. It is the period in which institutions are expected to move from policy statements to working controls.

The central conclusion is simple: IRCTC, GSTN and EPFO appear to be in different stages of preparation, but none can be described, on the public evidence reviewed, as demonstrably ready for the DPDP transition. GST presents the greatest apparent challenge of public facing governance transparency among the three systems reviewed, not because there is evidence that its security controls are weaker, but because the journey a taxpayer actually takes spans portals, operators and service layers that are never presented as one coherent chain of accountability. In GSTN's case there is direct evidence of the gap: the privacy governance it describes to an insurer in a published procurement document is substantially more developed than anything a taxpayer can read. Of the three policies reviewed, IRCTC provides the most detailed public description of the data categories involved in a transaction, but its broad language around vendors, affiliates, marketing and retention needs a sharper DPDP architecture. The reviewed EPFO website policy is clear about technical logs and session cookies, yet it does not visibly provide a comparable description of the processing behind the authenticated member and employer services that the same site presents.

The good news is that these gaps are visible while there is still time to close them. The bad news is that the transition window will disappear quickly once institutions start treating the final date as the beginning rather than the deadline.

Methodology

This assessment reviews publicly accessible privacy notices, website policies, service documentation, ecosystem documentation and official regulatory materials available as of 19 August 2026. It does not constitute a technical security audit, a legal compliance audit or an examination of internal processing records. Sources were checked against the versions publicly available at the research cutoff, and the IRCTC, GSTN, NIC, IRIS IRP and EPFO pages were verified against full page captures taken at that date; where a policy describes only a website rather than an authenticated service, the finding is limited to that public surface. Where a service forms part of a wider digital ecosystem, an individual portal's policy is treated as evidence about that portal's own public transparency, not as proof of the legal status of every entity or processing activity connected to it. "Readiness" therefore refers to what the public evidence demonstrates about transparency, governance signals and preparation for scheduled DPDP obligations. Absence of public disclosure is treated as an evidence gap, not as proof that an internal control does not exist. Evidence about public transparency is also kept separate from evidence about internal controls: procurement disclosures, security certifications and operational documentation are treated as evidence that an internal capability exists, and never as evidence that the capability is exposed to the citizen through the privacy architecture of the service. Where such a document is used in this article, it is used to establish that a control exists, not to criticise the institution.

What this assessment does not establish

This assessment does not establish that IRCTC, GSTN or EPFO is technically insecure, legally not compliant, or internally unprepared. Public privacy material cannot establish any of those things. The question asked here is narrower: what does the evidence facing the citizen demonstrate about each institution's readiness to make its processing, accountability, retention and rights architecture intelligible to the person whose data it holds?

1. Three blind spots before the legal checklist

A privacy notice usually looks at the website. This article looks at the data journey. That distinction is the central idea: the visible page is only the front door, while the meaningful privacy exposure may sit in the transaction, the connected ecosystem and the entire lifecycle of the record.

Before asking whether a portal has complied with a particular section, it helps to ask what the portal is failing to show the citizen. Across IRCTC, GSTN and EPFO, the public material points to three recurring forms of blindness.

Transactional blindness. A notice may describe visiting a website, but not what happens when a person books a ticket, files a return, registers an invoice, activates a UAN or submits a claim. The transaction, not the homepage, is where the sensitive data is created and acted upon.

Ecosystem blindness. A notice may describe the organisation, but not the vendors, APIs, connected government departments, authorised operators and service providers that process data in the same journey. The service design can look seamless while responsibility is distributed across several entities.

Lifecycle blindness. A notice may describe collection and use, but not correction, access, deletion, archival, legal holds, backups and communication after an incident. It tells the citizen what happens at the front door, but not what happens to the record after it enters the building.

These blind spots are particularly serious in India because public digital services are layered. A citizen may move from a central portal to a mobile app, payment gateway, identity service, state department or private operator without ever feeling that they have left one continuous government service. A digital service can feel like one transaction to the citizen while being several processing relationships to the institution.

A notice built for the DPDP framework should therefore be designed around the citizen's questions rather than the institution's organisational chart: What exactly are you collecting from me? Why is each item needed? What is mandatory and what is optional? Who will receive it? Will it be used for marketing, analytics or fraud prevention? What determines how long it is kept? How do I correct it? How do I complain? What happens if I withdraw consent where consent is the basis? What happens if the system refuses?

The public notices reviewed here answer some of these questions in pieces. IRCTC comes closest to describing transaction and sharing categories, but leaves rights and lifecycle control underdeveloped. The disclosures across the GST ecosystem vary by portal, making the network difficult to understand. EPFO is comparatively clear about its public website but does not visibly describe the operations that members actually care about.

2. First, the legal clock must be read correctly

The DPDP Act is India's statutory framework for processing digital personal data. It recognises both an individual's interest in protecting personal data and the need to process data for lawful purposes.¹ Its architecture is built around two roles. The Data Principal is the individual to whom the personal data relates. The Data Fiduciary is the person who determines the purpose and means of processing. A Data Processor processes personal data on behalf of the fiduciary.¹

Those roles attach to activities, not to organisations. IRCTC may be a fiduciary for some processing while Railways, a payment provider or a messaging provider holds a different role for another purpose, and the same is true across the GST and EPFO ecosystems. The legal map is therefore specific to each purpose, and a single corporate identity does not answer who is responsible for every processing activity carried out under it.

Section 4 provides that a person may process personal data only for a lawful purpose, for which the Data Principal has given or is deemed to have given consent, or for which processing is otherwise permitted under the Act.¹ Section 5 requires a notice when a Data Fiduciary seeks consent under Section 6. Section 6 says consent must be free, specific, informed, unconditional and unambiguous, given through clear affirmative action, and limited to the data necessary for the specified purpose.¹

This matters for government services because a citizen often cannot simply walk away. A passenger who wants a reserved ticket, an employer making a statutory filing and an employee awaiting a provident fund claim have no alternative route. In such contexts the decisive issue is not whether every transaction needs a consent banner, but whether the service can explain the lawful purpose, the data required, the use of each field, and the consequences of withholding it.

A privacy policy is not a DPDP notice

This distinction deserves to be stated plainly, because much of the public debate collapses it.

A privacy policy describes an organisation's general approach to privacy across a website or a group of services. A DPDP notice is a different instrument. It operates close to the point of processing, and where the Data Fiduciary seeks consent, Rule 3 gives it a specific shape. That qualification matters enough to state before the detail: Rule 3 is the notice framework for consent, not a universal banner that every government processing activity must display. Processing on other lawful routes, including State processing under Section 7(b), carries its own transparency requirements, which Section 8 below takes up. The notice must be presented and be understandable independently of any other information the Data Fiduciary has made available. It must give, in clear and plain language, an itemised description of the personal data and the specified purposes, including a description of the goods or services to be provided or the uses to be enabled. It must give the particular communication link, and a description of any other means, by which the Data Principal may withdraw consent with comparable ease, exercise rights under the Act and complain to the Board.²

The independence requirement is the demanding part. A notice cannot borrow its meaning from a policy page, a terms document and a help centre article read together. A citizen should be able to understand the specific processing from the notice alone.

The consequence for this article is direct: a general privacy policy does not by itself demonstrate that the required notice architecture exists.

The commencement calendar

The Rules were notified on 13 November 2025 and published in the Official Gazette of that date. They create a staged runway. Rules 1, 2 and 17 to 21 came into force on publication. Rule 4, concerning Consent Managers, is scheduled one year after publication. Rules 3, 5 to 16, 22 and 23 are scheduled eighteen months after publication.²

The commencement notification for the Act, G.S.R. 843(E), follows the same pattern and is worth reading precisely, because it is widely paraphrased and rarely quoted. It appoints the date of publication in the Official Gazette as the date on which section 1(2), section 2, sections 18 to 26, sections 35 and 38 to 43, and section 44(1) and (3) come into force. It appoints one year from the date of publication for section 6(9) and section 27(1)(d). It appoints eighteen months from the date of publication for sections 3 to 5, section 6(1) to (8) and (10), sections 7 to 10, sections 11 to 17, section 27 except clause (d) of sub section (1), sections 28 to 34, sections 36 and 37, and section 44(2).³

The legal calendar therefore has two milestones. The one year tranche arrives on 13 November 2026 and carries Consent Manager registration under section 6(9). The provisions assigned to the eighteen month tranche, including the core processing, fiduciary, rights, security and enforcement provisions, arrive on 13 May 2027.^{2 3} These dates should not be treated as permission to wait. They are a staged implementation plan.

One note on precision. Both the Act notification and Rule 1(2) run their periods from the date of publication in the Official Gazette rather than from any other date, so the publication date is the one that matters. The Gazette issue is dated Thursday, 13 November 2025 and the notifications bear the same date, and the statutory record runs the one year and eighteen month periods from 13 November 2025.³ The milestones are therefore 13 November 2026 and 13 May 2027.

One detail is worth knowing without being over read. The electronic Gazette copy carries the identifier CG-DL-E-14112025 and a Controller of Publications digital signature applied on 14 November 2025, which is when the electronic copy was signed and made available.³ That timestamp should not be treated as the commencement date. Institutions setting a programme gate or a contractual deadline should work from the Gazette notification and the statutory record, and confirm the calculation with counsel, rather than from a signature applied to a PDF.

A word on the Data Protection Board, kept deliberately short. Section 19(1) of the Act provides that the Board shall consist of a Chairperson and such number of other Members as the Central Government may notify, and Rule 17 sets up Search cum Selection Committees to recommend appointments.^{1 2} The Board's composition and the state of its appointments at any given moment are matters for the notifications and appointment notices themselves, and readers should work from those rather than from any secondary account, including this one.

The structural point does not depend on those details. Establishing a Board in law is not the same as having an enforcement mechanism a citizen can use, and the two calendars are independent: the Board's staffing neither accelerates nor delays the commencement of the substantive obligations. What it affects is whether the route to enforcement is practically available once those obligations bite.

What the Rules add

The Rules give the abstract duties operational shape. Notice content is governed by Rule 3, as described above. State processing for subsidies, benefits, services, certificates, licences and permits must follow the standards specified in the Second Schedule.² Security safeguards under Rule 6 include encryption, obfuscation, masking or virtual tokens; access control over the computer resources used; visibility over access through logs, monitoring and review; measures for continued processing such as backups; suitable provisions in the contract with a processor; and appropriate technical and organisational measures.²

Retention is where careful reading matters most, because the Rules contain more than one mechanism and they are frequently collapsed into a single misremembered figure.

Rule 6(1)(e) requires logs and personal data to be retained for one year so that unauthorised access can be detected, investigated and remedied, unless another law in force requires otherwise. This is a retention rule for security investigation, not a blanket requirement that every item of personal data be kept for a year.

Rule 8(3) is separate. It requires a Data Fiduciary to retain, in respect of any processing undertaken by it or on its behalf by a Data Processor, the personal data, the associated traffic data and other logs of processing for a minimum period of one year from the date of processing, for the purposes specified in the Seventh Schedule, after which they must be erased unless a longer period is required by another law or notified by the Government.² The rule expressly covers processing undertaken by the Data Fiduciary or on its behalf by a Data Processor, so outsourcing does not by itself remove the retention obligation. The Seventh Schedule purposes are State purposes: use by the State or its instrumentalities in the interest of sovereignty and integrity of India or the security of the State, performance of functions or disclosure obligations under law, and the assessment of a Data Fiduciary for notification as a Significant Data Fiduciary.² The first two concern specified State or State instrumentality functions; the third is an assessment by the Central Government for notifying a Data Fiduciary or class as a Significant Data Fiduciary. For institutions that are themselves part of the State, that is worth sitting with: one of the retention mechanisms in the Rules preserves personal data and processing records for these specified purposes. It is also not a general one year retention rule for every purpose, and should not be quoted as one.

Rule 8(1) is different again. It applies an inactivity clock, but only to the classes listed in the Third Schedule, which are e-commerce entities with at least two crore registered users, online gaming intermediaries with at least fifty lakh registered users, and social media intermediaries with at least two crore registered users. For those classes and purposes, the period specified is three years, and the Data Fiduciary must tell the Data Principal at least forty eight hours before erasure.² On the public evidence reviewed, none of the three institutions examined here appears to fall within one of those specific classes and user thresholds, so the three year clock is not the rule that governs their retention. The Third Schedule turns on class and threshold rather than on institutional identity, so that is a reading of the evidence, not a classification derived from the name over the door.

Retention required by other laws, including tax, accounting, benefit administration and record keeping statutes, sits on top of all of this. Two things follow, and they are the ones most often got wrong. Neither Rule 6(1)(e) nor Rule 8(3) creates a universal one year retention period for all personal data processed by every Data Fiduciary. And a one year figure in the Rules is a floor rather than a deletion deadline, so neither mechanism authorises keeping everything forever, and neither licenses deleting early.

The breach rule is similarly practical. Once a Data Fiduciary becomes aware of a personal data breach, it must intimate each affected Data Principal without delay, in a concise, clear and plain manner, describing the nature, extent and timing of the breach, the consequences relevant to that person, the mitigation measures taken, the safety steps that person can take, and the business contact information of someone who can answer queries. It must also inform the Board without delay and provide updated and detailed information within seventy two hours, unless the Board allows a longer period on a written request.² Rule 7 is scheduled to commence in May 2027, so the present task is to build and rehearse the capability rather than to assume the statutory clock has already started. One caution belongs with that sentence, because the practical inference is easy to get wrong. A Rule 7 clock that has not yet started does not mean an organisation has no incident reporting duty today. Other regimes apply on their own terms, including the CERT-In directions issued under the Information Technology Act, and sectoral regulators impose their own timelines. The DPDP breach obligation is an addition to that landscape, not a replacement for it, and it is a good deal less forgiving than an internal escalation policy.

The named human the Rules keep asking for

One thread runs through the Act and the Rules and is easy to miss because it appears in several different contexts.

It starts in the Act. Section 8(9) requires a Data Fiduciary to publish, in the prescribed manner, the business contact information of a Data Protection Officer, if applicable, or of a person who is able to answer the Data Principal's questions about the processing of her personal data.¹ Rule 9 supplies that manner: the information must be published prominently on the website or app, and mentioned in every response to a communication about the exercise of rights.² Rule 7(1)(e) requires the same kind of contact to be given to affected people in a breach intimation, and the Second Schedule requires it again where the State processes personal data under Section 7(b).² Alongside these, Rule 14 requires the means of making a rights request to be published prominently, together with the identifying particulars a requester must supply, which is a route rather than a person but serves the same end.²

Note what Section 8(9) does and does not say. The Data Protection Officer limb applies only where one is required, which under Section 10 means Significant Data Fiduciaries. The fallback limb binds everyone else, and it asks for business contact information rather than for an individual's name.

The Rules, in short, keep asking for a reachable person attached to the processing. In the public privacy material reviewed, no prominently published processing contact of the kind Rule 9 contemplates could be identified for any of the three services. The reviewed material surfaced general support and grievance routes, which are related but different things.

That finding is about visibility, not existence, and in one case this article can show the difference rather than assert it. GSTN has stated in a published procurement document that it has designated personnel for the Data Protection Officer and in house counsel function responsible for data protection matters.¹⁰ The person exists. The public material does not name them, or anyone. Section 5 sets this out in full, because it is the clearest evidence in the piece that the gap is one of accessibility rather than absence.

That is also why this may be among the lower cost transparency fixes available. What Section 8(9) and Rule 9 ask for is business contact information capable of answering questions about the processing, not the publication of an individual's name, and where a suitable contact already exists the work is to make it discoverable.

The test for a government portal, therefore, is not simply whether it has a privacy policy. The real test is whether the institution has built a chain from data inventory to notice, from notice to purpose, from purpose to retention, from retention to deletion or legal preservation, and from security monitoring to breach communication. In other words, can the citizen follow the data after pressing "Submit"?

3. What "ready" should mean in the public sector

There are at least four kinds of readiness, and they should not be collapsed into one score.

Legal readiness means the organisation has identified its statutory purposes, exemptions, fiduciary role, processor relationships and the provisions applying to each activity. Governance readiness means someone owns the data map, retention schedules, rights process, processor register and incident response plan. Technical readiness means the systems can log access, restrict privileges, encrypt where appropriate, detect unauthorised activity and delete or segregate records to policy. Readiness facing the citizen means the person whose data is processed can understand what is happening and find a usable route to exercise a right.

Public websites carry relatively strong evidence about transparency facing the citizen, indirect evidence about governance maturity, and weak evidence about technical and legal implementation. A policy can be inaccurate or disconnected from the actual code, and a sparse policy can sit on top of strong controls. The comparison below therefore offers compact judgments on public evidence, measured against obligations scheduled to commence in May 2027, rather than legal findings.

Each of the four dimensions below tests one specific question against the reviewed material, so that a reader can check the reasoning rather than take the label. Transaction transparency asks whether the categories of personal data and the purposes are disclosed for the service a citizen actually uses, as distinct from a website visit. Ecosystem transparency asks whether the recipients are named and whether the material says who is acting as fiduciary and who as processor for each purpose. Lifecycle transparency asks whether retention, deletion, archival and legal preservation are distinguished for different categories of record, rather than covered by a single formula. Rights visibility asks whether a citizen can find a route for access, correction, erasure or grievance, along with the particulars required and an indication of how long it will take. A judgment of "weak" on any dimension means the reviewed material did not answer that question, not that the institution has no answer.

What the public evidence shows

IRCTC

Transaction transparency: Better disclosed. The policy identifies registration, traveller, transaction, session and marketing data.

Ecosystem transparency: Broad and unclear. The policy names Railways, suppliers, vendors, affiliates and alliance partners without providing a complete map of responsibility purpose by purpose.

Lifecycle transparency: Weakly specified. Retention is described as "reasonably necessary," but the policy does not visibly distinguish the lifecycles of tickets, passenger records, documents, support records and marketing data.

Rights visibility: Limited. The notice does not publicly identify a rights workflow, a route for correction or erasure, or a named privacy contact beyond general customer support.

GST ecosystem

Transaction transparency: Fragmented. The public material varies across the GSTN corporate site, the surfaces operated by NIC and the authorised invoice registration portals.

Ecosystem transparency: The most visibly complex of the three systems on the evidence reviewed, involving potentially different fiduciaries, processors and independently operated systems.

Lifecycle transparency: Fragmented. Tax, invoice, payment, audit, analytics and fraud records may have different purposes and different bases for retention, but the public material does not connect them into one visible map.

Rights visibility: Uneven. Rights and grievance routes vary by portal, and no unified channel for rights requests is visible across GSTN, NIC and the authorised IRPs.

EPFO

Transaction transparency: Weakly disclosed. The reviewed policy explains a website visit more clearly than a UAN activation, KYC update, claim or pension transaction.

Ecosystem transparency: Weakly mapped. The reviewed policy sits on a site whose header carries Employee Login and Employer Login, and whose footer links to EPFiGMS, but it does not describe the processing behind any of them.

Lifecycle transparency: Weakly disclosed. The lifecycle of the member and employer record is not visibly mapped from collection through correction, archival, deletion or legal preservation.

Rights visibility: Limited. EPFiGMS provides a visible grievance route, but response times, steps for verifying identity and escalation for rights requests are not clearly documented in the reviewed material.

The most important word in this comparison is "ecosystem." Readiness will not be achieved by rewriting three web pages if the underlying institutions still cannot answer where data goes after a citizen presses "Submit."

4. IRCTC: a detailed notice, framed for a different question

IRCTC's public privacy policy is more informative than a bare website disclaimer. It begins by saying that the website and mobile application generally do not collect personal information merely from a visit unless the user chooses to provide it.⁴ It then describes data from a site visit such as IP address, browser type, operating system, access date and time, pages accessed and download dates. It also says the ticketing website and applications record session data, including user activities, to analyse browsing patterns and administer the system.⁴

This is a useful starting point, because it acknowledges that a visitor is not only a name and a phone number. The policy says cookies are used for personalisation, functionality, identifying user interest and tracking advertising effectiveness, that browser controls can delete or block them, and it sets out how to opt out of promotional email.⁴ It also separates technical identifiers from what it calls personally identifying information.⁴ That distinction deserves more care than it gets: IP addresses, session data and browsing activity can form part of an identifiable trail once combined with account or transaction records.

The more revealing part comes under the heading "Type of information collected", which the policy splits between registration on the website and mobile applications and a further category of other information.⁴ The policy reaches well beyond a name and a payment: it covers the account holder, the journey, and other travellers booked through the same account.

The listed purposes include confirming reservations, communicating transaction status, sending booking confirmations by SMS, WhatsApp or another messaging service, sending updates, enabling customer service contact, customising the website or app, requesting reviews, sending verification messages, validating accounts and preventing misuse.⁴ The policy separately discusses surveys, research, marketing promotions, discounts, special offers, newsletters and new services.⁴

There is much to commend here. IRCTC has not pretended that a ticketing platform is only a name and a payment form. It identifies travel companions, communication channels, account authentication, behavioural history, surveys and marketing. It also recognises that booking data is shared with Railways and other service providers responsible for fulfilling the booking.⁴

But the policy also exposes the hardest DPDP questions. IRCTC says it retains personal information on its servers for as long as is "reasonably necessary" for the purposes listed, with longer retention where legal, regulatory, tax or accounting requirements apply.⁴ That is a familiar privacy formulation, but it is not a retention schedule. A citizen cannot tell from it whether a cancelled ticket, a passenger manifest, an abandoned account, a failed payment, a customer service email, a marketing preference or a stored document has the same lifecycle. Under a framework organised around purpose, these should not silently become one indefinite archive.

The sharing section is even more consequential. IRCTC says information may be shared with end service providers such as Railways or other suppliers responsible for the booking. It says IRCTC does not authorise those providers to use the information for other purposes, but also says that how those providers use the information "is beyond the purview and control of IRCTC as they process Personal Information as independent data controllers, and hence IRCTC cannot be made accountable for the same", advising the passenger to review each provider's own policy instead.⁴ Two things follow. The phrase is IRCTC's own and belongs to a different vocabulary: under the DPDP framework the question is not whether a recipient is a controller but how the roles of Data Fiduciary and Data Processor apply to each specific processing activity. And a policy or contractual disclaimer cannot itself determine whether a recipient is a Data Fiduciary or a Data Processor. That classification follows from the actual purpose and means of the processing. Where a recipient genuinely determines its own purposes it may well answer separately, but that follows from the facts, not from a sentence the other party wrote. The policy also permits sharing with business or alliance partners and vendors involved in referral services and promotional benefits, and with affiliates or associates to improve personalisation and service efficiency.⁴

None of this is necessarily unlawful. A railway booking involves multiple operational actors, and some may indeed be separate fiduciaries. But a broad disclaimer is not a map of responsibility drawn purpose by purpose, and the questions it leaves open are the operative ones: for each transfer, who determines the purpose and means, what is the passenger told, which data is necessary for fulfilment as against marketing, and how does a passenger exercise a right once the data has moved on?

The policy says personal information may also be disclosed for law enforcement, court orders, legal process, regulatory, internal compliance and audit exercises, security, or protection of IRCTC's rights. It says disclosure and storage may occur without the user's knowledge and disclaims liability for damages arising from such disclosure and storage.⁴ Again, lawful disclosure may be required in some situations. But a notice built for what is coming should distinguish mandatory legal disclosure, security processing, service fulfilment, sharing within a corporate group and optional commercial use, rather than placing them in one large paragraph.

There are positive signals. IRCTC says payments are secured, that it uses secure servers for account access and maintains guidelines against unauthorised access, permits unsubscribing from promotional email, and states that a user must be at least eighteen to transact directly and to give consent to the processing of their personal data.⁴ These are general assurances rather than architecture. The notice identifies no rights workflow, no structured route for correction or erasure, no channel for breach communication and no deletion schedule.

The contact route is worth following, because it shows what the policy is built for. The policy ends with a Contact Us link, and what sits behind it is a customer service apparatus: an online query interface, an email address for problems cancelling a ticket or filing a TDR, helpline numbers in twelve languages, a wallet query link, and separate customer care numbers for four banks that issue the co branded loyalty cards, alongside the registered office address.⁴ It is a capable support operation. What it is not is a route to a person accountable for the processing. A passenger who wants to know why a field is collected, how long it is kept or who else received it has nowhere in that list to send the question.

The policy also tells the passenger that by browsing the portal the user accepts being bound by the current terms, privacy policy and disclaimer, and so should check these on each visit, and that IRCTC reserves the right to amend the privacy policy from time to time.⁴ One point of caution follows, and it should be stated conditionally. If continued browsing were being relied on as the mechanism for obtaining consent to a particular processing activity, that formulation would sit uneasily with a standard requiring consent to be free, specific, informed and unambiguous and given by clear affirmative action. The policy does not distinguish which of its processing activities rely on consent and which rely on another lawful route, so a reader cannot tell whether that reliance is being placed at all. That ambiguity is itself the transparency point.

The IRCTC conclusion is therefore not that the portal is careless. It is that the public policy still reads primarily as a conventional website privacy statement. It explains security, cookies, categories of information and broad sharing, but it does not yet visibly operate as a transparency architecture organised around specific purposes. The DPDP era asks a harder question: Can the passenger follow the data after the booking is made? On the evidence visible to the public, IRCTC appears to be preparing, but readiness is not demonstrable from the material reviewed.

5. GST: the portal is a network, not a page

If IRCTC's challenge is a broad notice framed for an older question, GST's challenge is structural. The GST data journey is distributed across a network of technology and service providers. The GSTN privacy policy, hosted on its corporate website, says that the site generally does not collect personal information from a visitor unless the visitor provides it. It says information collected is used only for the purpose for which it was provided, and that GSTN will not rent, sell, share or otherwise disclose personal information to third parties. It adds that data may be shared with other government agencies after due process.⁵

The notice also says GSTN may contact users about services they subscribed to, may send promotional announcements where applicable, and allows users to opt out or ask for their contact information to be removed, where applicable.⁵ It warns that third party websites may have different privacy practices, and it adds that the information is intended to be safe barring actions by entities beyond the legal jurisdiction of this country.⁵

Two things about this document are worth stating plainly. The first is its length: the substantive privacy policy of the company that builds and runs the GST system's technology backbone is a single paragraph. The second is a tension inside that paragraph. It promises that GSTN will never rent, sell, share or otherwise disclose personal information to third parties, while the wider GST technology ecosystem can involve authorised private operators, GSPs, IRPs and software integrations, depending on the service and the route a given taxpayer uses. Both statements can be true at once if the policy is read as governing only the corporate website. Nothing on the page tells the citizen that, which is exactly the problem.

As a policy for a corporate site, this is a straightforward statement. As a description of the taxpayer ecosystem, it is plainly incomplete: it says nothing about registration, authentication, authorised signatories, bank and payment data, return filings, invoice records, API access, e-way bills, e-invoice registration, GSPs or accounting software integrations.

One caution belongs here before the detail, because it is where this argument is most easily attacked. The existence of multiple operators does not itself establish that each operator is a separate Data Fiduciary. The legal role depends on who determines the purpose and means of the particular processing activity, and a private operator can run infrastructure without becoming a fiduciary for everything that crosses it. That is precisely why the material facing the citizen needs to make those relationships intelligible: the roles are not readable off the architecture.

The individual GST surfaces make the point. The website policy for the e-Invoice 1 portal says NIC does not collect personal information unless it is explicitly and voluntarily provided, uses it only for the request, does not sell or share volunteered personally identifiable information except as required by government order, notification, policy or request, and collects technical information such as IP address, domain, browser, operating system, visit time, pages and referring URL for aggregated statistics.⁶

Two details on that page do more work than the policy text. It is stamped Version 1.01 and carries a 2022 copyright line, which places it before the DPDP Act came into force and before the Rules existed. And its hyperlink policy tells the reader that following an external link means "you shall be leaving the e-way bill website", on a portal that is not the e-way bill website. The wording is mismatched to the surface it sits on.⁶ It is a small thing, and it is precisely the kind of small thing that shows whether a privacy document is a live governance instrument or a static page carried forward.

That policy may be accurate for the public website and its operator. But the operational data environment can be much richer. The privacy policy for IRIS IRP 6 states that IRIS IRP is a GSTN authorised Invoice Registration Portal serving taxpayers, GSPs and solution providers, that IRIS was appointed as an official IRP by the government in June 2022, and that the website is maintained and operated by IRIS GST, a business line of IRIS Business Services Limited. What is notable is the structure. The policy is organised into numbered sections covering what information is collected, how it is used, how it is shared, how it is stored and secured, cookies, and how a user may access and control personal data. Within those, it carries separate headings for account and user information, payment information, log files, cookies, third party integrations, usage information, information collected from other sources, and information processed on behalf of customers, then further headings for sharing with service providers and partners, corporate events, compelled disclosure, data storage and security, retention of personal data, and reviewing, correcting and removing personal data.⁷

The contrast runs deeper than length. The IRIS IRP policy contains a retention section that says what happens when a business need ends: personal data is securely deleted or anonymised or, where that is not possible, securely stored and isolated from any further processing until deletion becomes possible. It also carries a section on accessing, reviewing, correcting and removing personal data, and a change of control clause under which an acquirer would receive all information gathered by the portal.⁷ The GSTN corporate policy contains none of these.

The IRIS policy also does something none of the other documents reviewed attempts. Its structure separates the processing it carries out for its own subscription service from a distinct category of information it processes on behalf of its customers, which it treats under its own heading.⁷ That is the role question the DPDP framework turns on, addressed inside a single operator rather than assumed away. It also shows why ecosystem mapping cannot stop at the boundary between government and private: one company can occupy different roles for different activities on the same portal.

That is the finding worth holding on to, and it is the opposite of the one a reader might expect. On the material reviewed, the authorised private operator publishes more of a privacy architecture than the government entity at the centre of the system does.

What GSTN says when a citizen is not the audience

There is a second GSTN document in the public domain, and reading it beside the privacy policy is the sharpest illustration this article can offer of the difference between the front door and the building.

In a request for proposal for renewal of its cyber risk insurance, published on its own tenders page, GSTN answers an insurer's due diligence questionnaire.¹⁰ Asked to confirm whether it holds a documented Data Protection and Privacy Policy, a documented Information Security Policy, and documented guidelines on the retention, storage, handling and disposal of records and information, GSTN answers yes to all three, and adds that the GST system is certified against ISMS, ITSMS and BCMS with certificates valid to financial year 2026, with policies and processes aligned to those standards. Asked whether those documents are shared with all employees and with third parties including updates, it answers yes. Asked whether its data protection and privacy policy complies with applicable data protection legislation, it answers yes, remarking that this is limited to Indian compliances. Asked whether it has appointed designated personnel for the roles of Chief Compliance Officer, Data Protection Officer and or in house counsel responsible for data protection related matters, and Chief Information Security Officer, it answers yes to each. The phrasing of that question matters: it establishes that a designated person holds the data protection function, not that a Data Protection Officer has been formally appointed under the Act. It describes a dedicated security operations centre running twenty four hours a day, every day of the year.¹⁰

Set that against the public page. GSTN has a documented data protection and privacy policy; the policy the citizen can read is one paragraph. GSTN has documented retention, storage, handling and disposal guidelines; the public policy says nothing about retention at all. GSTN has designated personnel holding the data protection function; the public material identifies no contact for it.

This is not a contradiction, and it is not evidence of bad faith. Both documents can be entirely accurate. It is the clearest possible demonstration of the argument this article is making: the governance may well exist, and the citizen still cannot see it. An insurer performing due diligence gets a structured account of GSTN's privacy governance, including confirmation that someone holds the data protection function. A taxpayer gets a paragraph.

That asymmetry is the thing worth fixing, and it is not expensive to fix. Most of the substance a Rule 3 notice and a Rule 9 contact require appears to exist already, in documents written for a different reader.

Yet the contrast between the short GSTN corporate notice, the NIC portal policy and the detailed IRP policy exposes the real problem: a taxpayer may experience GST as one service journey even though different processing activities may involve different Data Fiduciaries, Data Processors or independently operated systems. On the reviewed material alone, a single compliance journey may pass through infrastructure operated by government, an authorised private operator that discloses paid service tiers and their own payment information, and integrations that the IRP policy itself says may view, store or modify account data.⁷ Some recipients may be processors; some may be separate fiduciaries; some may be acting under statutory authority. The taxpayer needs to know which is which, and the public material does not say.

A contract, a privacy policy and a technical architecture must tell the same story about those roles, and at present the citizen cannot check whether they do.

The retention question is acute. Tax administration often requires long records, audit trails and legal preservation. DPDP does not mean that every taxpayer record must be erased immediately after filing. It does require the organisation to know why information is retained and to distinguish retention required by law from retention for convenience, analytics or commercial reuse. A GST portal must be able to maintain an immutable tax record where tax law requires it while deleting or separating data that is no longer needed for the specified purpose. A generic sentence about using information only for the purpose provided does not demonstrate that this has happened.

The question of rights is equally difficult. A taxpayer may request correction of a contact detail, but changing a tax record is not the same as erasing an identity trail. One person's rights may intersect with another business's invoice, an employee's personal information, a fraud investigation, a statutory audit or a court proceeding. The system needs rules for verifying identity, correcting records, refusing requests, escalating them, auditing decisions and communicating outcomes. It cannot simply add a "delete my data" button to a tax database.

The GST ecosystem should therefore be judged on its governance map, not on the quality of a single page. The public evidence shows pieces of readiness: clear website policies at certain nodes, and disclosures at an authorised IRP that extend to retention, rights and its own role split. What it does not show is those pieces connected into one accountability map a taxpayer could actually read. On the evidence reviewed, GST presents the greatest apparent challenge of public facing governance transparency among the three, not because its security is weakest, but because its processing relationships are the hardest for a taxpayer to follow.

6. EPFO: the quiet gap between the website and the account

EPFO's official privacy policy is notably explicit about the difference between visiting a public website and completing a transaction that involves personal information. It says the website collects no personal information such as names or addresses merely from a visit. It says that technical information is automatically gathered, including the domain and IP address of the service provider, browser, operating system, date and time, pages or URLs visited, and referring website.⁸

EPFO says it uses cookies that are not persistent and last only for a session, for technical navigation. It says these cookies do not collect personal information, are held in memory during the active session and disappear when the browser closes.⁸ If a user submits personal information through a contact form, EPFO says it uses the information to respond or provide a requested service, and shares it with another government agency if the query relates to that agency or where required by law. It recommends that users not include other personal information in a message.⁸

This is relatively clear hygiene for a public site. The policy tells a visitor what technical data is collected and gives a narrow purpose for information submitted through a contact form. It adds that the site never collects information or creates individual profiles for commercial marketing, and that it never tracks or records information about individuals and their visits.⁸ The footer links to EPFiGMS, the grievance system.⁸

Two things about the page matter more than its contents. The first is its date: the reviewed policy carries a last updated date of 18 August 2026, so this is a current document, maintained well after the Rules were notified, that still describes only a website visit. The second is what sits directly above it. The same site presents Employee Login and Employer Login in its header.^{8 9} The authenticated surfaces where the consequential processing happens are one click from the page that says no personal information is collected.

The strength of the policy is therefore also its limitation. EPFO's difficulty is not that its website privacy policy is unclear. It is that the policy is clear about a comparatively low risk surface while the member's consequential processing happens behind the login. The reviewed EPFO privacy policy does not visibly provide a comparable privacy description for the processing of personal data associated with member and employer services such as UAN activation, profile changes, claim submission, KYC updates, passbook access and pension service requests. Those authenticated services can involve categories of personal data far more consequential than a page visit, including employment, identity, bank, nominee, pension and benefit information.

This is a finding about the reviewed public material, not a claim that EPFO holds no documentation for those services elsewhere. The narrower point is that the reviewed privacy material does not explain how the authenticated services relate to it from the perspective of governing personal data, whether a connected service acts as a processor or as an independent fiduciary, or how a member corrects an error that appears in one system but originates in another. The terms of use page confirms that the site links out to material created and maintained by non government and private organisations, and tells the user that on following such a link they are leaving the EPFO website and become subject to the policies of its owner.⁹

That gap matters because provident fund data is not administrative trivia. A wrong bank account can delay a claim; a wrong date of birth can affect eligibility; a mismatched Aadhaar or KYC record can block a service; and a compromised account can expose identity and financial information. The privacy notice must therefore function as a service map, not only as a statement that the main website uses session cookies.

EPFiGMS provides a visible grievance route and could become the front door for rights requests if EPFO defines categories, response times, identity checks, escalation and record keeping.⁸ Rule 14 gives that work a shape: the means for making a rights request and the particulars required to identify the requester must be published prominently, and the period for the grievance redressal system to respond to grievances, which must not exceed ninety days, must also be published, with technical and organisational measures in place to make that period effective.² The evidence from EPFO's public site is moderate; readiness across the member and employer ecosystem is not demonstrable from the material reviewed.

7. The most important missing page is not a privacy policy

One of the most useful internal governance artefacts these systems could build may be a processing register that the public never sees in full but that drives everything the public does see. The register should identify each processing activity, the data fields involved, the purpose, the statutory basis or other lawful route for the processing, the responsible fiduciary, the processors, the recipients, the retention position, the security classification, the rights pathway and the incident owner.

This is a recommendation about good governance rather than a claim that the Act expressly mandates a register in that form. The point is practical: every obligation that does exist, from itemised notice under Rule 3 to breach intimation under Rule 7 to the rights machinery under Rule 14, requires the institution to already know these facts about itself. A register is a practical way to make those facts explicit and to keep them connected across notices, rights workflows, retention schedules and incident response.

Consider a railway booking. A simple register would distinguish account creation, passenger identity, communication with passengers, payment, fulfilment of the reservation, fraud detection, customer support, marketing, reviews, cookies and travel services provided by others. Each activity may have different data, different recipients and different retention. Without that separation, a privacy policy becomes a list of possibilities rather than an explanation of actual processing.

The same exercise for GST shows why one generic notice cannot work. Registration, return filing, invoice processing, API access, audit and fraud detection do not share a purpose, an operator or a statutory retention period, and a single GSTIN may sit alongside a proprietor's mobile number, an employee's contact details and a vendor's bank information. The data map must follow the record, not the brand.

An EPFO register would need separate entries for the member and employer processing that sits behind the two login doors on its own homepage: UAN and member profile, employer contribution, claims, bank validation, KYC, nominee details, pension records and grievance records. The citizen should not have to infer these flows from a policy that describes the front page.

The security requirements in the Rules point the same way. A database can be encrypted at rest and still be overexposed to an administrator. A portal can require multifactor authentication and still retain unnecessary data indefinitely. A log can detect access and still be useless if no one reviews it. A backup can preserve continuity and still multiply the copies that must eventually be deleted or protected.²

Six questions every government processing activity should answer

1. Where was it collected?
2. Why was it collected?
3. Under what lawful route is it processed?
4. Where did it go?
5. Who accessed it?
6. What happens to it when its purpose ends?

If an institution cannot answer these six questions internally, for every material processing activity and the personal data associated with it, it cannot answer them in a citizen notice either.

The third question is the one most often skipped, and it is the one that decides the shape of everything else: consent and the State route under Section 7(b) lead to different notice, rights and retention consequences for the same field. The first practical task for government systems is therefore an exercise in data lineage built around those six questions. It is unglamorous work, and it is the work on which everything else depends.

The second task is a rights workflow, not a PDF. Rights requests need an entry point, verification of identity that does not create excessive new data, routing to the correct system owner, a decision framework for correction or erasure, communication with the citizen, and an audit trail. Rule 14 sets the visible edges of this: the means of making a request must be published prominently, together with the identifying particulars a requester must supply. Note carefully what the ninety day figure in Rule 14(3) does and does not cover. It is the published period for the grievance redressal system to respond to grievances, not a general statutory deadline for answering every rights request. Reading it as an omnibus ninety day clock for access or correction requests is a common misreading, and a service that quietly adopts ninety days as its answer to everything would be using a grievance backstop as a service standard.² Public services will need exceptions where records must be retained for law, tax, benefit administration, fraud investigation or another legitimate purpose. Those exceptions should be explained rather than hidden behind a support form that leads nowhere.

The third task is governance of processors. Contracts with cloud providers, hosting companies, call centres, payment processors, messaging vendors, analytics providers, identity services and app developers should specify permitted purposes, security controls, escalation of breaches, deletion or return of data, audit rights and rules for engaging further processors down the chain. Rule 6 already requires appropriate provision in the contract with a processor for taking reasonable security safeguards.² A policy statement that a supplier is "beyond our control" is not a substitute for a governance model.

The fourth task is rehearsal of incidents. Rule 7 creates the future operational framework for notifying breaches, and it is scheduled to commence in May 2027, so the present task is to build and test the capability rather than to assume the statutory clock has already begun.² A government service should rehearse a scenario in which a vendor reports unauthorised access to a passenger database, an invoice platform, or an export of pension accounts. Who decides whether the event is a personal data breach? Who informs the Board? Who informs affected people? What if the contact details in the compromised database are themselves unreliable? What if the breach crosses three portals? These are operational questions, and a transition period is the right time to test them.

8. State processing is a different route, not an exemption from accountability

The State processing provisions should not be read as a general exemption from accountability. The Act contains provisions allowing processing for certain legitimate uses, including situations connected with the State's provision of subsidies, benefits, services, certificates, licences and permits. The Rules specify standards for State processing in those contexts.^{1 2}

That architecture recognises a practical reality. Government processing for statutory functions will not necessarily depend on consent, because the Act provides specific routes for certain State functions, such as checking eligibility, preventing fraud, processing a pension or issuing a certificate. It also recognises that a person may not have a meaningful choice about whether to provide information for a lawful public service.

But a route that does not rely on consent is not a route that avoids accountability. If anything, public power makes clarity more important, and the Rules say so in terms.

The Second Schedule is explicit about what the standards for State processing under Section 7(b) require. Processing must be carried out lawfully. It must be limited to the personal data necessary for the specified use. It must be done while making reasonable efforts to ensure the completeness, accuracy and consistency of the data. The data must be retained only while required for that use or for compliance with law. Reasonable security safeguards must protect the data, including where a processor handles it. Critically, the processing must be undertaken while giving the Data Principal an intimation of it, together with the business contact information of a person who can answer questions about the processing on behalf of the Data Fiduciary, and the particular communication link, and description of any other means, through which the Data Principal may exercise rights under the Act. The Schedule closes with accountability: the person who determines the purpose and means of processing, alone or with others, is answerable for the effective observance of these standards.²

Read together, that is not an exemption from transparency. It is a transparency duty routed differently. The absence of a consent banner does not remove the need to tell people what is happening and to give them somebody to ask.

Rights are a different matter, and here the article should be exact rather than encouraging. Section 17(4) provides that in respect of processing by the State or any instrumentality of the State, Section 8(7) and Section 12(3) do not apply, and Section 12(2) does not apply where the processing is for a purpose that does not include making a decision that affects the Data Principal.¹ In plain terms: the erasure duty on the fiduciary and the Data Principal's right to erasure are disapplied for State processing, and the right to correction, completion and updating is disapplied unless the processing feeds a decision about that person.

This cuts both ways, and an institution should understand both. It means a government service cannot be criticised for declining to erase a record it processes as the State. It also means transparency carries more weight, not less, because the citizen has fewer levers to correct the picture afterwards. A service that knows Section 17(4) applies to a given activity should be able to say so, and to say which of its activities it does not apply to, rather than leaving a member to discover the limit by making a request that goes nowhere.

A service whose position is that by browsing the portal the user accepts the current terms, and should re check them on each visit, may be familiar, but it does not demonstrate the kind of specific, purpose organised communication the framework contemplates, on either route.

Nor should privacy be reduced to secrecy. Public administration often requires controlled sharing. Railways must fulfil a booking. Tax systems must exchange records for lawful administration. EPFO may need to work with authentication and benefit platforms. The question is not whether data ever moves. The question is whether movement is bounded, recorded and intelligible.

9. A recommended transition programme before May 2027

The remaining runway should be treated as a sequence of measurable releases rather than a single legal deadline. The steps below combine scheduled obligations with recommended governance practice; they should not be read as a claim that every recommendation is itself a present statutory requirement.

By the first milestone on 13 November 2026, each service should have completed and internally signed off its data inventory, role map and register of processing purposes. It should know which obligations are already live, which fall in the eighteen month tranche scheduled for 13 May 2027, and which rules or sectoral laws impose stricter duties of retention or security.

Rule 9 belongs in the May 2027 plan, not the November 2026 one: it sits in the eighteen month tranche, alongside Rule 3 on notice, Rule 6 on security, Rule 7 on breach intimation, Rule 8 on retention and Rule 14 on rights.² Publishing a privacy contact earlier is an interim practice worth adopting anyway. Treating those six as one programme rather than five projects is the sensible approach, because they all draw on the same inventory.

The next stage converts the register into notices. IRCTC should publish an explanation separating account, booking, passenger, payment, fraud prevention, support, marketing and partner processing. GST should publish an ecosystem map distinguishing GSTN, NIC, authorised IRPs, GSPs and integrations built by others. EPFO should publish a notice for the services behind the login.

The services should then launch rights mechanisms in controlled form. That could begin with requests for access and correction, followed by routes for erasure where legally possible. Where an institution chooses to offer further controls, such as temporarily suspending a use, those should be described as organisational mechanisms rather than presented as statutory rights, because the Act does not create a general right to restriction of processing. The goal is not to promise that every record can be erased. The goal is to tell people what can be changed, what must be retained, why a request may be refused, how quickly they will hear back, and how the decision can be challenged.

Security work should be measured by evidence rather than slogans. Institutions should test privileged access, review logs, verify recovery from backups, rotate credentials, map the processors engaged further down the chain, test tokenisation or masking, and conduct tabletop exercises for breaches. A privacy policy that promises appropriate physical, technical and organisational measures, as the IRIS IRP policy does, is an assurance rather than evidence, and the transition period is for producing the evidence.⁷

Retention should be broken into schedules. A tax record retained under tax law is not the same as an abandoned record of a web session. A ticket needed for accounting may have a different period from a marketing profile. A pension claim file may require preservation, but an old duplicate upload may not. Each schedule should specify the system of record, the legal authority, the method of deletion and the treatment of backups, and it should say which of the retention mechanisms in the Rules applies, since a floor under Rule 6 or Rule 8(3) is not a deadline and does not license keeping everything.

Recommended transparency practice

As a recommended transparency practice, and not as a claim that the Rules expressly require an annual report, each service should publish an annual privacy transparency report in plain language. It could disclose the number and type of rights requests, average response times, complaints, material incidents, audits of processors, significant changes to data use and the number of notices available in Indian languages. Public reporting would help turn compliance from a hidden legal exercise into a service standard that builds trust.

10. The verdict: not late, but not ready enough

So, are India's government websites ready from a DPDP perspective?

Not demonstrably ready, on the public evidence reviewed. That phrasing is deliberately narrower than saying these institutions are not compliant or are technically unprepared, and the difference is the whole point. Nothing reviewed here supports a conclusion about the state of anyone's internal controls. The finding is that the privacy architecture a citizen can see does not yet demonstrate the maturity the framework will demand.

Of the three policies reviewed, IRCTC gives the most detailed account of the data categories involved in a transaction, naming passenger, account, transaction, session, communications, survey and marketing categories. Its weaknesses are the breadth of its sharing language, a retention formula with no stated end, and a disclaimer of accountability where a responsibility map should be. It should convert a broad privacy policy into notices and controls tied to specific purposes.

GST has some visible operational signals, including privacy language at an authorised IRP detailed enough to cover retention and rights. But the system is a network of portals and providers, and the public evidence does not yet show a unified map of accountability. GST presents the greatest apparent challenge of public facing governance transparency among the three systems reviewed. That is a relative ranking within this sample of three, not a sector wide assessment of government systems. Its transition programme should begin with data lineage and allocation of roles across the whole system, not merely a revised corporate privacy page for GSTN.

The reviewed EPFO notice is clear about technical data and session cookies, and EPFiGMS provides a foundation. But a policy maintained into August 2026 still describes only the front page, while two login doors sit above it. EPFO is moderately mature at the brochure layer, and readiness at the account layer is not demonstrable from the material reviewed. It needs a privacy notice for the services behind the login, and a rights workflow integrated with EPFiGMS.

One gap recurs across all three, and it may be the least expensive to close. Section 8(9) requires a Data Fiduciary to publish business contact information capable of answering questions about the processing, and the Rules ask for the same kind of contact again in a breach intimation and in State processing under Section 7(b). None of the reviewed material prominently identifies one. That does not establish that no internal owner exists; in GSTN's case a published procurement document indicates that someone holds the function.¹⁰ It establishes that the citizen cannot reach them, which is a different problem with a much shorter fix.

Procurement cycles, legacy databases, vendor contracts, review of language, verification of identity, rules for archival and coordination across departments all take time. The clock is also an opportunity. The Rules have supplied a set of operational requirements from which that map can be built. The public websites have supplied a visible starting point. The institutions now need to connect the two.

The final measure of readiness will not be whether a ministry can produce a policy PDF after a breach. It will be whether a passenger, taxpayer or provident fund member can ask a simple question and receive a precise answer: What do you know about me, why do you need it, who else has it, and what can I do about it?

That is the privacy notice India's digital State must learn to write, and, more importantly, learn to live by.

Source note

The statutory analysis in this article was taken from the text of the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 themselves. Every rule, schedule and section referred to was read in that text rather than in a secondary summary.

The service material at references 4 to 9, covering IRCTC, GSTN, the NIC operated e-Invoice 1 portal, IRIS IRP and EPFO, was verified against full page captures taken at the research cutoff. The descriptions and quoted phrases in sections 4, 5 and 6 are drawn from those captures. Live pages may change after publication; where they do, this assessment reflects the dated capture retained at the cutoff rather than any later version. The GSTN procurement document at reference 10 was read in the copy published on GSTN's own tenders page, and the answers quoted are GSTN's own responses to the insurer's questionnaire.

One distinction is worth making explicit, because this article asks institutions to be precise about their evidence and should hold itself to the same standard. The GSTN, NIC and EPFO pages, and the GSTN procurement document, were read in full. For the IRCTC and IRIS IRP policies, the capture was read in full for the passages quoted or characterised in detail, and at the level of section headings elsewhere. Where this article describes those two documents by their structure rather than quoting them, that is why, and no claim is made here about body text that was not read. Note that EPFO's material was read on epfo.gov.in, which now carries the pages formerly served from epfindia.gov.in.

The commencement notification for the Act, G.S.R. 843(E), was read in the Gazette copy itself. The section lists and the commencement dates in section 2 are taken from that copy, as is the Gazette issue date of 13 November 2025. The electronic copy carries a Controller of Publications digital signature dated 14 November 2025, but that signature timestamp is not treated in this article as the Gazette publication date. The commencement calculations therefore run from 13 November 2025.

This article makes no claim about the Data Protection Board's current composition or staffing, because the relevant notifications and appointment notices were not available for verification at the cutoff.

References

References

1. The Digital Personal Data Protection Act, 2023 — MeitY / Gazette of India
2. Digital Personal Data Protection Rules, 2025, G.S.R. 846(E), 13 November 2025 — MeitY / Gazette of India
3. Commencement notification for the Digital Personal Data Protection Act, 2023 — G.S.R. 843(E), Gazette issue dated 13 November 2025
4. IRCTC Privacy Policy
5. GSTN Privacy Policy
6. NIC e-Invoice Portal Website Policies
7. IRIS IRP 6 Privacy Policy, an Invoice Registration Portal authorised by GSTN
8. EPFO Privacy Policy, last updated 18 August 2026
9. EPFO Terms of Use
10. Request for Proposal for Renewal of Cyber Risk Insurance Policy of GSTN, RFP Ref. No. GSTN/P&C/CISO/C1/08-2025/P-12, 4 September 2025

#DPDP #DataProtection #Privacy #IRCTC #GSTN #EPFO #GovTech #DigitalIndia

General information about the DPDP Act 2023 and the DPDP Rules 2025, not legal advice. This is a public evidence assessment, not an audit finding.