Step-by-step: enforce a UDRP decision a registrar will not i… (.org 2)

Step-by-step: enforce a UDRP decision a registrar will not i… (.org 2). UDRP and ccTLD domain recovery and defense across .org. Email the firm to assess your c…

A WIPO panel has ordered the transfer of a .org domain. You have the decision in hand. Then nothing happens. The registrar — for any number of reasons — has not moved the domain to your account, days have turned to weeks, and the registrant is still listed in the RDDS. This situation is rarer than it should be, but it happens. And when it does, the winning complainant discovers that a UDRP transfer order is not self-executing.

When you need to enforce a UDRP decision a registrar will not implement for a .org domain, the path runs through ICANN's compliance machinery first, then — if that fails — through court action or registrar escalation backed by the policy contract. ICANN policy requires accredited registrars to implement UDRP decisions within 10 business days of transmission, absent a court filing by the losing registrant. The remedy for non-implementation sits partly with ICANN, partly with the courts, and partly with the complainant's own escalation steps — each carrying a trap the unwary miss.

This guide walks every step in sequence, names the decision the reader faces at each one, and flags what goes wrong when that decision is handled carelessly.

Why would a registrar refuse to implement a .org UDRP transfer order?

Non-implementation is almost never an outright refusal: it is delay, silence, or a procedural position — and each has a different fix. A registrar may claim the order was not formally transmitted to it by WIPO, cite an outstanding court filing by the registrant, report a technical lock on the account, or — in the most problematic cases — have received a third-party court order in a foreign jurisdiction that it reads as conflicting with the UDRP decision.

Public Interest Registry (PIR) administers the .org zone and requires its registrars to be ICANN-accredited. That accreditation carries an obligation: the Registrar Accreditation Agreement (RAA) and the UDRP implementation procedures mean a registrar that ignores a final, transmitted decision is in breach of its ICANN obligations. Knowing this matters because it gives you a lever — ICANN compliance — that operates independently of the courts.

In our practice, the most common causes of stall on .org decisions are: (1) the registrar has not yet received formal notification from WIPO and is waiting; (2) the registrant filed a court proceeding within the 10-business-day window and notified the registrar; (3) an automated lock triggered by a prior dispute flag is holding the domain; (4) the registrar is headquartered outside the United States and has uncertain exposure to US court enforcement.

Identifying which cause applies is the first decision point. The wrong diagnosis wastes weeks.

Step 1: Confirm the decision was formally transmitted to the registrar

WIPO transmits the decision to the registrar of record — not to you directly — and that transmission is the clock-start for the 10-business-day implementation window. Before escalating, confirm transmission has occurred and document when. The WIPO online case-file system shows transmission status. If transmission is delayed on the WIPO side (uncommon but possible in high-volume periods), the registrar's obligation has not yet begun.

The trap in Step 1 is assuming WIPO has transmitted because you received your copy. Those are separate events. Request a written confirmation from WIPO — typically a brief message from case administration — stating the date the decision was sent to the registrar. That date is your baseline for every subsequent deadline calculation.

If the decision was transmitted and 10 business days have passed without implementation, proceed to Step 2. Do not wait longer in the hope the registrar will act on its own.

Step 2: Make formal written demand to the registrar

Send a written demand — email with read-receipt and a contemporaneous letter — addressed to the registrar's abuse-contact address and its legal department, if identifiable. The demand should: cite the WIPO case reference number and the transmission date; state the UDRP implementation obligation by reference to the applicable ICANN registrar accreditation policy; specify the domain in full (.org); demand implementation within a fixed short window (three to five business days is reasonable); and state that ICANN compliance and court remedies will follow if not implemented.

The trap in Step 2 is sending an informal message to the registrar's general support queue. Support teams are not implementation teams. They cannot authorize a transfer order. A demand that does not reach the registrar's legal or compliance function is not a demand in any enforceable sense — it is a support ticket that will be closed without action.

Keep every piece of correspondence. If this proceeds to a court filing or ICANN complaint, the record of your demand and the registrar's response (or non-response) is material evidence of willful non-compliance.

Step 3: File an ICANN registrar compliance complaint

ICANN's Contractual Compliance function exists precisely for this. A registrar that has received a properly transmitted UDRP decision and refuses to implement it — absent a legitimate court stay — is in breach of its RAA. Filing a compliance complaint creates a formal record, triggers ICANN's inquiry process, and in most cases prompts the registrar to act quickly rather than risk a compliance escalation that could affect its accreditation.

The complaint is filed online through ICANN's compliance portal and requires: the domain name, the registrar's name and IANA ID, a description of the breach, and supporting documentation (WIPO decision, evidence of transmission, record of your demand and the registrar's non-response). ICANN will acknowledge and assign a case number.

The trap in Step 3 is treating the ICANN complaint as a substitute for court action. It is not. ICANN cannot order a transfer directly. Its tool is the registrar's accreditation. In practice, the compliance inquiry often resolves the problem — registrars implement quickly once ICANN asks questions — but if the registrar is shielded by a foreign court order or is in genuine financial distress, the ICANN route will stall too. Pursue both tracks in parallel, not sequentially.

At this stage — demand sent, ICANN complaint filed, registrar still silent — the matter has become a court-adjacent problem. For an assessment of whether court action is warranted in your situation, contact info@cognomenlaw.com.

Step 4: Assess whether the registrant filed a court stay

Under ICANN's implementation rules, a registrar is entitled — indeed, required — to withhold implementation if the registrant files a court action challenging the UDRP decision within the 10-business-day window and notifies the registrar. This is the registrant's legitimate route to judicial review. If the registrar cites a court filing, demand to see it.

A court filing must be a bona fide challenge in a court of competent jurisdiction — typically in the country where the complainant is domiciled, where the registrant is domiciled, or where the registrar operates. A vague threat of litigation or a filing in a court with no plausible jurisdiction over the dispute does not automatically excuse the registrar. Panels and courts have occasionally addressed attempts to use nominal court filings as delay tactics.

The trap in Step 4 is accepting the registrar's representation of a court filing without demanding proof. Ask for the case number, the court, and the filing date. Then instruct local litigation counsel in the relevant jurisdiction to verify the filing and assess its jurisdictional basis. A procedurally defective filing, or a filing in a jurisdiction with no real connection to the parties or the domain, may not be sufficient to excuse the registrar from implementing the UDRP order.

If the registrant's court action is legitimate, the dispute is no longer a UDRP enforcement problem — it is a litigation defense problem. We regularly advise complainants who find themselves on the defendant side of exactly this kind of follow-on action, and the factual record built during the UDRP complaint is usually the strongest evidence available.

Step 5: Consider an independent court action to enforce the transfer

If the ICANN complaint is progressing slowly and no bona fide court stay exists, filing an independent action to enforce the UDRP decision may be the fastest resolution. The available routes depend on where the parties sit.

In the United States, a complainant who prevailed in a UDRP proceeding can bring an action under US anticybersquatting legislation — which allows a court to order transfer, and in appropriate cases damages — independently of the UDRP result. The UDRP decision is not binding on the court, but it is strong persuasive evidence of the registrant's bad faith and the complainant's rights. A court order directed at the registrar is enforceable in a way a UDRP decision is not.

For .org registrars operating outside the United States, the complainant may need to proceed in the registrar's home jurisdiction, with local litigation counsel in the relevant jurisdiction. PIR, as the .org registry, is a US-based entity; this can give US courts a basis to assert jurisdiction over the registry itself in appropriate cases, which may be a more direct route to enforcement than suing the registrar abroad.

The trap in Step 5 is waiting too long. Statutes of limitation apply to court anticybersquatting claims regardless of whether you pursued UDRP first. Do not assume the UDRP proceeding tolled any deadline. Instruct counsel to calculate the applicable limitation period from the date of the original harmful registration or use — not from the UDRP decision date.

The decision matrix on the court route: if the registrar is US-based or PIR is a viable defendant, US anticybersquatting litigation is the cleanest enforcement tool, with a genuine prospect of transfer and costs. If the registrar is outside the US and no US hook exists, the litigation must go to the registrar's jurisdiction — longer, more expensive, and uncertain — which shifts the cost-benefit calculus significantly toward ICANN compliance pressure rather than litigation.

If a prior UDRP win has stalled at the registrar stage, a focused analysis of the enforcement options often identifies a step that was missed. To discuss the options for your .org domain, email info@cognomenlaw.com.

Step 6: Address account compromise or domain hijacking — a different but overlapping scenario

Occasionally, what looks like registrar non-implementation is actually a more serious problem: the domain has been transferred away during the UDRP proceedings, or the registrant's account was hijacked and the domain moved to a different registrar before the lock was applied. This changes the analysis completely.

UDRP proceedings require the registrar to lock the domain — preventing transfer or deletion — once the complaint commences. If that lock was not applied or was circumvented, the domain may now sit with a different registrar who was not party to the proceeding. The UDRP decision names the registrar of record at the time of commencement. If the domain has moved, the order may not bind the successor registrar.

The trap in Step 6 is not checking the current RDDS state of the domain at the moment you receive the decision. Run a fresh RDDS query immediately. If the registrant has changed, or if the registrar has changed, document both the current state and the state as of the complaint date. That gap — the unauthorized transfer window — is evidence of bad faith compounding the original cybersquatting, and it may support an injunction application in court.

In a recent matter involving a .org domain (spring 2025), we identified that the domain had been transferred to a privacy service mid-proceeding, circumventing the registrar lock that should have been in place. We escalated the registrar lock failure to ICANN compliance simultaneously with a court filing seeking an injunction against both the original registrant and the acquiring entity. The outcome was eventual transfer — but only because the evidence of the lock failure was documented from the outset.

Where the domain was stolen rather than disputed — meaning your client was the registrant and the domain was taken from them by account compromise — the UDRP is not the right vehicle at all. That scenario calls for registrar escalation, account-compromise documentation, and in serious cases a court order directing the registrar to restore the domain. See our guidance on court-based domain recovery for the mechanics of that distinct path.

What evidence decides the outcome at each stage?

Whether you are pursuing ICANN compliance, court enforcement, or a parallel filing, the evidence package is the same at its core — and gaps in it slow every stage down.

The essential record comprises: the WIPO decision itself (with case reference and date); proof of WIPO's formal transmission to the registrar (date and method); your written demand to the registrar and any response; the current RDDS state of the domain (screenshot with timestamp); any registrant court filing (case number, court, filing date); and the original complaint and supporting trademark evidence from the UDRP proceeding.

In addition, if the scenario involves account compromise or unauthorized transfer, you need: the account compromise timeline (login records, unusual activity notifications, unauthorized transfer confirmations); communications with the registrar's security or abuse team; and any ICANN or registry escalation records.

What courts and ICANN compliance reviewers look for is a clear, timestamped narrative: the decision was made, it was transmitted, the window passed, the registrar was notified, and nothing happened. Gaps in the timeline — missing emails, undated screenshots, unverified transmission dates — create room for the registrar to claim procedural confusion. Fill every gap before you escalate.

We have defended complainants who arrived at the court stage with an incomplete evidence record and had to reconstruct the timeline from WIPO's case-file logs. That reconstruction is possible but time-consuming. Build the record from the moment the decision is issued.

Cross-zone note: how .org enforcement compares to other zones

The .org enforcement problem is a gTLD problem, governed by ICANN policy and US-adjacent registry authority. Compare it to two other zones where the same issue arises differently.

For .uk domains, the Nominet DRS has its own implementation mechanism: Nominet itself implements the decision, not the individual registrar. A winning complainant in a .uk dispute does not chase the registrar — Nominet acts directly on the registration. The enforcement gap that creates the .org problem does not arise in the same form.

For .de domains, there is no equivalent of the UDRP at all. A DENIC DISPUTE entry can block transfer while court proceedings run, but the underlying dispute is resolved by German courts. A .de complainant who wins in court has a court order — inherently more enforceable than a UDRP decision — but gets there only after significantly longer litigation.

The .org scenario sits between these: a UDRP decision exists and carries persuasive weight, but its implementation depends on a private contract between ICANN and the registrar, not on a court order or a registry's direct authority. That gap is what creates the enforcement problem — and why the steps above close it sequentially, using each lever in turn. For a comparative analysis of enforcement across zones, see our analysis of UDRP enforcement in other gTLD zones.

Related at COGNOMEN

• Court-based domain recovery — when arbitration cannot reach the result
• Enforcing a UDRP decision in other gTLD zones — a comparative analysis
• Respondent defense and RDNH findings — protecting a legitimately held domain