The lead-up to ICANN83, which will be held next week in Prague, feels much shorter than usual, as ICANN-accredited registrars and registries just held our Contracted Parties Summit in early May. This was a useful series of working sessions and discussions. Most focused around operational issues—especially addressing DNS Abuse—but another topic came up in conversations with the ICANN Board, CEO, and Board Chair: “urgent” requests for registration data disclosure.

We’re going to explore this topic before we dive into our regular TACO stats.

Looking back: past discussions about “urgent” requests

We wrote about “urgent” requests back in October 2023, just before ICANN78. In that blog, we provided the definition of “urgent disclosure requests” that had been used in both ICANN’s Registration Data Policy (which was a draft at the time) and ICANN Policy work on a Standardized System for Access and Disclosure requests:

‘Urgent Requests for Lawful Disclosure’ are limited to circumstances that pose an imminent threat to life, of serious bodily injury, to critical infrastructure, or of child exploitation in cases where disclosure of the data is necessary in combatting or addressing this threat. Critical infrastructure means the physical and cyber systems that are vital in that their incapacity or destruction would have a debilitating impact on economic security or public safety.

At the time, the Implementation Review Team (IRT) was close to completing a version of the Registration Data Policy (RDP) that included requirements for responding to both standard and “urgent” requests. Unfortunately, the IRT could not come to agreement on the specific timeframe for responding to “urgent” requests and so the Policy was published without it. The issue of “urgent” disclosure requests was put on hold until now.

We reported in our October 2023 post that, out of 83 requests marked “urgent,” only two met the above definition, and in both cases, the law enforcement entity in question was looking for IP address information, not registration data. 

“Urgent” request rates since our last post

Since August 2023 (the latest data we had to report on in our October 2023 blog), we have received 55 requests marked as “urgent.” As this is a topic of concern, we are now tracking this moving forward and have updated our previous records for accuracy and completeness, bringing our previously reported 83 figure to 105 and the total number of “urgent” requests up to 160, as of June 3, 2025.

Of the 55 requests received since we published the above-mentioned blog, five1 requests met the definition of “urgent”; one was abandoned. Part of the reason behind the change in numbers is that we are now counting data requests that aren’t marked as “urgent” but which, nonetheless, met the Policy Definition. For the current period, that brings us to 9 “urgent” requests, noted in the graph below.

Most of the time, when there is a life-and-death scenario, investigators actually need hosting data, a user’s IP address, or the real identity of a person behind a username on a forum; registration data has typically not been found necessary to resolve those situations. Further, in these situations, investigators and law enforcement use every possible contact method, including direct phone calls, rather than submitting requests through our TACO platform or through ICANN’s RDRS2. In every case, our job is to help investigators however we can: usually by pointing in the direction of what they’re looking for.

Revisiting “urgent” requests

Since this topic is now back on the agenda, work on the Registration Data Policy relating to “urgent” requests has actively resumed and, when complete, this work will fulfill the initial EPDP Phase 1 Working Group’s policy recommendation: “a separate timeline of [less than X business days] will be considered” for responding to ”’urgent” requests. This work is progressing along two tracks.

One of those two work tracks is considering how to authenticate law enforcement when they submit an “urgent” request. Confirming the requestor’s identity is a necessary step in responding to any disclosure request but is especially crucial to get right for situations meeting the “urgent” definition—especially when the request is exigent.

A second group will determine what the response timeframe should be when an “urgent” request is submitted by an authenticated user. This work is being completed by the original Phase 1 Implementation Review Team (IRT) and the outcome will be Policy language that becomes part of the RDP.

Based on our experience over the last few years, we’ve arrived at some conclusions about what these requirements should be: 

First, any implemented Policy must adhere to approved Working Group Recommendations; in this case, if further requirements around timing are added, it should be a period measured in business days—not hours. 

Back in July 2023, the Registration Data Policy IRT almost finalized policy language requiring registrars to respond to “urgent” requests within 24 hours, with the option to extend the response time by a few business days if necessary. We’re in favor of this approach only if the requestor is authenticated before the timeline begins to toll and hope to see something similar implemented at this time. 

There’s similar language around timelines in the EPDP Phase 2 Final Report, which recommended that “urgent” requests be addressed within 1 business day and no later than 3 calendar days; that timeframe may also be worth considering.

Second, it’s important that any “urgent” request process be separate from the standard Registration Data Policy disclosure obligations.

Why? The RDP requires registrars to publish details about how to submit requests with the goal of making it easy for any interested party to do so. Truly “urgent” requests, however, should only be submitted by law enforcement; this process should not be open to the public.

As we’ve seen already with RDRS “expedited” requests, an “urgent” request submission process, if available to anyone, will be misused—everyone thinks that their situation is “urgent”. The best approach will be a mechanism where registrars provide reliable emergency contact information that is released only to authenticated members of law enforcement within their jurisdictions. 

Restricting the submission of “urgent” requests to law enforcement and ensuring registrars are given a reasonable response window are both critical. 

A 24-hour response time would put registrar businesses at risk of breaching their contract with ICANN and won’t improve the “urgent” request process: registrars need time to authenticate the requestor, engage external legal counsel if needed (many registrars do not have internal legal departments), determine whether the situation qualifies as “urgent”, and, finally, decide whether data can legally be disclosed to that requestor. All this may happen well within 24 hours, but it’s simply not possible to always meet that deadline. And of course, as we covered above, registration data is almost never what they really need.

We want to help law enforcement in their investigations, but we want to do so within the bounds of the law and with full understanding of due process. Currently, we still have the right to tell law enforcement that they need to get a warrant before we provide them with data. Currently, we still have the right to demand that law enforcement tell us that circumstances are “exigent” before we provide them with data. A required 24-hour turnaround time puts our business at risk if we insist—as we often do!—upon due process for our customers and their data. 

Obviously, when we receive due process or notice of exigency, we comply with those legal obligations—that’s not a matter of ICANN Policy but of the law.

Tiered Access Statistics: 1 January – 30 April 2025

We received 156 requests in this period, bringing the total since we began tracking it up to 6372.

Now that we’re reporting on 2025, we’ve consolidated the three periods of 2024 into one.

Data disclosure request outcomes: new period January – April 2025)

The most frequent outcome for requests continues to be disclosure of data to the requestor:

Requests by requestor category

Requests by category: new period (January – April 2025)

Law Enforcement requests were the most frequent requestor category in this reporting period, overtaking Commercial Litigation, which in the past has often held the position.

Requests by category since 2018

Requests by category (total)

Abandoned requests by requestor category (January – April 2025)

We continue to receive requests which are abandoned when we follow up asking for more information.

LEA request locations

Our map of requestor locations hasn’t changed since the last post, as we did not receive requests from any new countries in this reporting period.

We continue to receive the bulk of our LEA requests from outside our local jurisdictions, both overall and in the new reporting period:

LEA request origin (local vs foreign) – overall

LEA request origin (local vs foreign) – new period

Local LEA request breakdown (overall)

Total requests over time

To read our past Tiered Access blog posts, please see:

Tiered Access update: RDRS participation and updated statistics (September – December 2024)

1Note that, in cases where the law enforcement entity submitting the “urgent” request did not provide enough information for us to confirm whether the request met the ICANN Policy definition of “urgent”, we still considered it “urgent” for the purposes of counting them for this post. Law enforcement is busy doing better things than making sure that their exigent requests conform to an ICANN Policy definition.

2In fact, the ICANN Board determined that the RDRS may not permit submission of “urgent” requests as “this functionality does not reflect the manner in which true emergencies are currently handled” and “if a requestor is facing an emergency […] they should contact the registrar directly for immediate assistance.” (Tripti Sinha to Gregory Dibiase, Proposed Success Criteria Registration Data Request Service (RDRS))