Summary

  • The Registration Data Policy published on 12 May 2026 gives an authenticated urgent requester a two-hour acknowledgement and a response within 24 hours, with a reasoned extension capped at 72 hours for exceptional circumstances.
  • The response may disclose the requested nonpublic registration data or deny all or part of the request with reasons. The clock does not replace the merits analysis, override applicable law or begin to bind contracted parties before the authentication mechanism becomes effective.

Imagine that a properly formed request arrives at 14:00. By 16:00, the receiving registrar or registry operator must acknowledge it. By 14:00 the next day, the requester must normally have a response. If exceptional circumstances genuinely require more time, the recipient must say so within that same 24-hour window, explain why and state when it will answer. The new outer limit is 72 hours from receipt.

That sequence sounds like an emergency disclosure order. It is not. Each timestamp controls a step in a process, and the product of that process can still be either data or a reasoned refusal.

The narrow doorway comes first. Section 3.8 of ICANN’s Registration Data Policy defines an Urgent Request as a subset of lawful-disclosure requests. It must come from an Authenticated Requestor and concern an imminent threat to life, serious bodily injury, critical infrastructure or child exploitation. Disclosure must be necessary to combat or address that threat. A requester does not enter the urgent channel merely by writing “urgent” in a subject line.

Authentication is also more than self-identification. Section 3.9 limits the class to a law-enforcement requester or trusted or competent authority authenticated through a mechanism implemented under ICANN Consensus Policy. The amendment therefore separates two controls that are often collapsed in public debate: whether the requester is who it claims to be, and whether this particular request is sufficiently necessary and lawful.

The underlying disclosure rules still apply. The required submission must identify the requester, list the data elements sought, explain the requester’s legal rights and specific rationale, affirm good faith and promise lawful processing of any data received. A registrar or registry operator must consider every properly formed request on its own merits.

The clock changes how long that consideration may sit unresolved. For an ordinary disclosure request, Section 10.5 allows up to two business days for acknowledgement and, absent exceptional circumstances, up to 30 calendar days after acknowledgement for a response. Section 10.7 replaces that pace for a qualifying urgent request: acknowledgement within two hours and response without undue delay, no later than 24 hours unless a stated exception applies.

The extension lane is deliberately narrow. Force majeure affecting infrastructure and complexity such as an unusually large number of domain names are given as examples. Calendar holidays, planned leave and planned travel are expressly excluded. An operator cannot convert a round-the-clock emergency standard back into a business-hours queue by staffing choice.

Yet “response” is not a synonym for “release”. Section 10.6 preserves two compliant outcomes. The operator may provide the requested data. Or it may deny the request in whole or in part, identify the specific reasons and explain the route to its decision. Where applicable, that explanation must show how the data subject’s fundamental rights and freedoms were weighed against the requester’s legitimate interest.

This boundary matters because the information at issue is nonpublic registration data. A rapid process can reduce the cost of delay in a genuine emergency. It cannot make the same legal basis valid in every jurisdiction, prove that every requested field is necessary, restore public WHOIS, or transform ICANN into the authority deciding a police investigation. The registrar or registry operator remains the substantive decision-maker for the request it receives.

The policy also leaves an important switch open. Implementation Note 11 says the Section 10.7 obligations take effect only when ICANN fully implements a Consensus Policy establishing requester authentication. ICANN’s 12 May announcement said the urgent language would not become effective until the law-enforcement authentication mechanism is implemented. Its GAC-advice status record, updated on 23 July, likewise says enforcement of the 24-hour timeline is pending that mechanism.

The amendment is therefore published policy with a deferred operational trigger. That is not a drafting curiosity. Without credible authentication, a faster channel could reward impersonation or force operators to spend the first hours proving who is asking. Without a response clock, authentication alone would create a trusted queue with no emergency speed. The public-comment history records the two-track solution: develop authentication separately while setting the response time on the assumption that a qualifying requester has already been authenticated.

When the switch is activated, accountability should be visible in records, not inferred from assurances. Section 11.2 requires registrars and registry operators to retain logs of disclosure requests, acknowledgements and responses for standard business recordkeeping and possible ICANN audit. Those records can prove whether the two-, 24- and 72-hour duties were met. They cannot by themselves prove that a disclosure or denial was legally correct, but they make silence measurable.

The new clock is strongest when described precisely. It authorizes speed, structure and an auditable decision. It does not authorize automatic disclosure.

Sources