Across the Asia Pacific region, a wave of GDPR-style data protection laws has moved from legislation to enforcement.
Indonesia’s Personal Data Protection Law No. 27 of 2022 is now fully in force, with its two-year transition period ending in October 2024. India published its Digital Personal Data Protection Rules in November 2025, beginning a phased rollout of the 2023 Act, with compliance obligations taking effect in stages through May 2027. Sri Lanka’s Personal Data Protection Act No. 9 of 2022 (PDF), South Asia’s first standalone data protection regime, sits between the two. The regulator is operational, and a 2025 amendment (PDF) removed the grace periods that had postponed substantive compliance obligations.
This is no longer a future challenge. For most sectors, the implications have been debated and analysed extensively. However, National Research and Education Networks (NRENs) have not. The reason is a blind spot that needs to be addressed.
An NREN’s potential response is that these laws are somebody else’s problem. We are not banks, telcos, or platforms. We provide open connectivity; we do not filter traffic, sell subscriptions, or profile users. That instinct is half right, and the wrong half is where the risk lives.
Importantly, the obligations discussed here vary by jurisdiction. While many Asia Pacific privacy laws share concepts found in the GDPR, they are not the GDPR, and the terminology, thresholds, transfer rules, regulatory expectations, and compliance timelines differ from economy to economy.
This is a practitioner’s operational view, not legal advice. Privacy obligations, organizational roles, and compliance requirements vary significantly between jurisdictions. Specific obligations should be confirmed with counsel qualified in the relevant jurisdiction.
Looking beyond the network core
The core network is genuinely low exposure. The transit of member-institution traffic across an open backbone involves little that a regulator would classify as personal data. If an NREN were only a backbone, this article would be short.
But no NREN is only a backbone. Around the core sits a service portfolio, and almost every service within it processes personal data, often as the whole point of the service. Walk through your own catalogue and the picture emerges quickly:
Identity and federation. An eduID service, or any identity provider feeding an access federation, will often act as a controller (or the equivalent concept under local law) for at least some of the personal data it handles, although the exact allocation of responsibilities depends on the service design, governance arrangements, and applicable legal framework. It holds names, institutional email addresses, affiliations, and identity attributes for staff and students across every member institution. Through eduGAIN interfederation, those attributes are released to service providers in other economies, making cross-border transfers of personal data part of the federation’s trust fabric. This is exactly the problem GÉANT’s Data Protection Code of Conduct and the REFEDS Research & Scholarship entity category were designed to address. Start with those frameworks before building your own assessment.
eduroam. Every eduroam deployment proxies authentication across institutions and, through the confederation, across borders. RADIUS logs carry realm-bearing usernames, device identifiers, access point-level location data, and timestamps. The roaming architecture means personal data routinely leaves the home institution’s control as a matter of normal operation, not exception.
Operational telemetry. Many modern privacy laws, including those inspired by the GDPR, treat IP addresses and similar identifiers as personal data, or regulate them in substantially similar ways where they can be linked to an identifiable individual. That single point reclassifies much of what a Network Operations Centre (NOC) collects without a second thought: DNS resolver query logs, NetFlow/IPFIX records, DHCP and RADIUS accounting data, and mail relay logs. None of it was collected to identify people. All of it can.
Security and abuse handling. A Computer Security Incident Response Team’s (CSIRT’s) incident records inevitably contain IP addresses and often user identifiers. Depending on the jurisdiction, legitimate interests, statutory functions, public-interest purposes, or comparable legal bases may support this processing. A lawful basis, however, is not an exemption. Purpose limitation, retention controls, and rules governing information sharing with other CSIRTs, often across borders through FIRST or regional trust groups, still apply.
Registry data. An NREN that operates a ccTLD or academic sub-domain registry may have responsibilities comparable to those of a controller, depending on the role it plays in determining how registrant data is collected and used. This is the same personal-data-in-registration-records problem that reshaped Whois and drove the move to RDAP, now appearing at national research-domain scale.
Operational compliance considerations
None of the above is abstract. Each service creates specific compliance obligations for whoever runs it: Documenting a lawful basis for processing, appointing a Data Protection Officer or equivalent where required, notifying regulators of personal-data breaches within statutory deadlines, enforcing retention limits on logs and records, and conducting impact or risk assessments for high-risk processing. In some jurisdictions, backbone-scale traffic monitoring may itself be enough to trigger those assessment requirements.
Cross-border data transfers deserve particular attention because they are where NREN architecture and privacy law intersect most directly, and because the regulatory landscape is still evolving. Sri Lanka’s Personal Data Protection (Amendment) Act No. 22 of 2025, gazetted on 31 October 2025, revised the original Act’s cross-border transfer provisions and removed the fixed grace periods that had governed the commencement of substantive obligations.
For operators, the practical implications are straightforward. First, understanding where federated identity attributes, eduroam authentication data, and CSIRT information exchanges flow is now an immediate compliance requirement, not a future one. Second, the commencement of those obligations now depends on ministerial gazette orders rather than a long-published statutory timetable. Waiting for the relevant gazette notice before preparing is, in practice, waiting too long.
Building a service and data inventory
The single most useful thing an operator can do before enforcement begins is stop assuming and build an inventory. Map each service, one by one, to the NREN’s role in the processing, whether as a controller, processor, joint controller, or the equivalent concept under the applicable legal framework.
The instructive part of this work is not the legal text, which lawyers handle better than engineers do. At a small NREN without in-house counsel which describes most of them it is the engineers who do it anyway. What you see once you start is how much regulated personal data a research network already holds without ever having filed it under that name. The identity service, the federation, the resolver logs, the CSIRT case records, the domain registry none were built as ‘personal data processing’, and all of them are.
For NRENs elsewhere in the region facing the same wave, a workable first pass is straightforward:
- Inventory every service that processes personal data and document the NREN’s role in each case, whether as a controller, processor, joint controller, or the equivalent concept under local law.
- Map every cross-border data flow, including eduGAIN attribute releases, eduroam roaming, and CSIRT information sharing, against the transfer requirements in your jurisdiction.
- Set retention periods deliberately, based on operational need and legal requirements, not available disk capacity.
- Determine whether your organisation is required to appoint a Data Protection Officer or equivalent responsible officer and, if so, who will fulfil that role.
- Establish a breach-notification process before you need it, including clear paths for escalation, decision-making, and regulatory reporting.
None of this requires waiting for a legal department. It requires an engineer willing to walk the service catalogue with a privacy lens, and a leadership willing to sponsor the review.
The privacy wave reaching the Asia Pacific region is not a threat to NRENs, it is a prompt to formalize what we already do. But the window to do it calmly before a gazette order, before a first complaint, is open now and will not stay open. Start with the inventory.
Tuwan Azgar Jaleel is a Senior Network and Systems Engineer at the Lanka Education and Research Network (LEARN), Sri Lanka’s national research and education network, where he manages the campus backbone network and institutional connectivity services. He is also an APNIC Community Trainer and an active member of LKNOG.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.