How Does the ICANN Policy Development Process Work in Internet Governance?

From Community Idea to Global Internet Policy — The Step-by-Step Guide to How the Internet Governs Itself
A Plain-English Breakdown of ICANN's Most Important Governance Mechanism — and How You Can Be Part of It

Billions of people use domain names every day — to access websites, send emails, run businesses, and connect with each other. Most of them have never thought about who decides the rules that govern those domain names. The answer might surprise you.

The rules that govern domain name registration, transfer, dispute resolution, WHOIS data privacy, DNS security standards, and how new internet extensions are created are not written by governments in closed negotiations or by corporations in boardrooms. They are developed through a structured, open, and participatory process called the ICANN Policy Development Process — a mechanism that, by design and by rule, allows anyone in the world to participate.

The ICANN Policy Development Process — commonly referred to as the PDP — is at the heart of how internet governance works in practice. It is where the multi-stakeholder model becomes real. It is where policy ideas become binding agreements. And it is where individual voices, when they show up consistently and argue clearly, genuinely change outcomes that affect the global internet.

💡  The One-Line Definition:  The ICANN Policy Development Process (PDP) is the structured, multi-stakeholder mechanism through which ICANN’s supporting organizations — primarily the GNSO for generic domain names — develop consensus-based policy recommendations that, once adopted by ICANN’s Board, become binding on all contracted registry operators and accredited registrars worldwide.

Why Does ICANN Need a Policy Development Process?

ICANN does not make policy by executive decision. This is not accidental — it is the defining feature of how ICANN operates and why the internet governance community trusts ICANN’s policies as legitimate.

ICANN’s mandate is to coordinate the internet’s unique identifier systems — domain names, IP addresses, and protocol parameters — for the stability and security of the global internet. But coordination requires rules. Rules about who can register which domain names, what information must be collected and how it can be accessed, what happens when trademark owners dispute a domain name, how new domain extensions are approved, and dozens of other technical and policy questions.

In a traditional regulatory model, a government agency would promulgate these rules after internal deliberation. In ICANN’s multi-stakeholder model, the community that is affected by the rules helps develop them. This is the foundational principle behind the PDP: the people and organizations who will be subject to ICANN’s policies — registrars, registry operators, trademark owners, civil society advocates, individual domain name registrants — participate directly in shaping them.

The practical implication of this principle is that ICANN policy carries legitimacy that few other governance institutions can claim. When a policy emerges from the ICANN PDP, it has been exposed to every relevant perspective, every technical consideration, every public interest argument, and every commercial concern — and the resulting consensus represents a genuine balancing of those interests, not a unilateral decision by any single actor.

⚖️  The Legitimacy Equation:  ICANN policy’s legitimacy comes not from legal authority — ICANN is not a government and has no sovereign power — but from the quality and openness of the process that produces it. When a policy survives the scrutiny of the GNSO’s multi-stakeholder working groups and is adopted by the ICANN Board, its legitimacy rests on the community participation that shaped it.

The GNSO: Where the Policy Development Process Lives

The ICANN Policy Development Process for generic Top-Level Domains happens within the Generic Names Supporting Organization — the GNSO. The GNSO is the community body responsible for developing and recommending consensus policies for generic domain names (gTLDs). It is made up of two main houses — the Contracted Parties House and the Non-Contracted Parties House — which represent, respectively, registry operators and registrars who have contracts with ICANN, and the broader community of commercial users, intellectual property interests, Internet Service Providers, non-commercial organizations, and civil society groups.

This two-house structure is deliberate. It ensures that the businesses whose operations are directly governed by ICANN policies are represented alongside the businesses and individuals who are affected by those policies as users, advocates, and concerned citizens. Neither house can dominate the process — the PDP is designed to require support across both houses before a policy recommendation goes to the ICANN Board.

The GNSO Council is the governing body of the GNSO — a group of elected and appointed representatives from each of the GNSO’s constituent communities who vote on whether to initiate PDPs, review working group progress, and vote on final policy recommendations. The GNSO Council is the gatekeeper of the PDP: it decides what goes in and what comes out, subject to the community deliberation that happens in between.

The ICANN Policy Development Process: Seven Stages Explained

The PDP is not a single event — it is a structured journey that takes a policy issue from initial identification through community deliberation to a final Board decision. Here is how each stage works.

Stage 1: Issue Identification and the Call for Community Input

Every PDP begins with the identification of a policy issue that requires community attention. Issues can be raised in several ways: a Stakeholder Group or Constituency may submit a formal request to the GNSO Council; the ICANN Board or staff may identify a gap or conflict in existing policy; external developments like new legislation or security incidents may create policy needs; or the community itself may surface issues through public forums and mailing list discussions.

Once an issue is identified, the GNSO Secretariat prepares a Staff Issue Report — a document that defines the scope of the issue, summarizes the existing policy landscape, identifies the stakeholders affected, and outlines the policy questions that need to be answered. This Issue Report is published for community comment, giving anyone interested in the issue an early opportunity to share their perspective before the formal PDP begins.

Stage 2: GNSO Council Initiates the PDP

After considering the Issue Report and community input, the GNSO Council votes on whether to initiate a formal PDP. If the Council votes to proceed, it also adopts a PDP Charter — a foundational document that defines the scope of the PDP, the specific questions the working group must address, the timeline, the composition of the working group, and any special requirements for the process.

The Charter is a crucial governance document. It prevents scope creep — a common risk in complex policy deliberations — by clearly defining what is in scope and what is not. It also establishes the accountability framework: working group members know from the outset what they are expected to deliver, by when, and under what standards of consensus.

Stage 3: Working Group Formation — The Open Heart of the PDP

The working group is where the real work of the ICANN Policy Development Process happens — and it is the most accessible stage for community participation. Working groups are formed with open membership: anyone with a genuine interest in the policy issue can join. There is no application fee, no organizational affiliation requirement, and no technical prerequisite. You send an email expressing your interest to the working group’s mailing list or the GNSO Secretariat, and you are in.

Working groups are chaired by one or more volunteer chairs selected from the community, with support from the GNSO Secretariat. They meet regularly — typically weekly or bi-weekly via video conference — and conduct the majority of their ongoing deliberation through publicly archived email mailing lists. All working group meetings are recorded and the recordings are published. All working group outputs — internal reports, expert consultations, draft recommendations — are publicly accessible. The transparency requirements are among the most stringent of any governance process in the world.

The working group deliberates over months or years — the duration depends on the complexity of the issue and the degree of community consensus. It hears from subject matter experts. It commissions research. It engages in structured dialogue across stakeholder perspectives. And through this sustained engagement, it works toward consensus positions that reflect the genuine balancing of legitimate interests rather than the victory of any single faction.

Stage 4: Public Comment Periods — Where the Wider Community Speaks

At key points in the PDP — typically on the Initial Report (which presents preliminary findings and options) and the Final Report (which presents the working group’s consensus recommendations) — the working group’s outputs are published for formal public comment periods, usually running 30 to 60 days.

Public comment periods are the broadest and most accessible participation channel in the entire PDP. Anyone — a domain name registrant, a small business owner, a digital rights advocate, a network engineer, an academic, a government official, or a concerned citizen — can submit a written comment through ICANN’s online system at icann.org/public-comments. Comments are not advisory suggestions that can be ignored. The working group is required to read every comment, document every substantive point raised, and state explicitly in a Comment Summary and Analysis document how each point was considered and responded to.

This requirement to formally respond to every substantive public comment is one of the PDP’s most powerful accountability mechanisms. It means that well-reasoned public comments from individuals who are not formal working group members genuinely influence policy outcomes. Working groups have changed their recommendations because of public comments from people who were never in a working group call.

Stage 5: GNSO Council Review and Vote

When the working group’s Final Report is complete, it goes to the GNSO Council for review. The Council evaluates whether the report meets the PDP Charter’s requirements, whether the process was conducted appropriately, and whether the policy recommendations are properly supported by the deliberation documented in the report. If the Council finds procedural deficiencies, it can send the report back to the working group for additional work.

If the report is accepted, the GNSO Council votes on the policy recommendations. The voting thresholds are deliberately designed to require cross-constituency support: a simple majority is not sufficient for full consensus, and super-majority thresholds are required for recommendations to be treated as GNSO consensus positions. This design prevents any single stakeholder group from pushing through policies that lack broad community support.

Stage 6: ICANN Board Adoption

Policy recommendations adopted by the GNSO Council go to the ICANN Board for final action. The Board is required to formally respond to all GNSO policy recommendations within a reasonable timeframe. It has three options: adopt the recommendations as ICANN policy, reject them with a detailed explanation of why, or send them back to the GNSO for additional community work.

In practice, the vast majority of GNSO policy recommendations that reach the Board are adopted — because they have already survived the scrutiny of the community’s multi-stakeholder deliberation process. When the Board does reject or remand a recommendation, it must provide a comprehensive explanation, and the GNSO community has the opportunity to respond. Once adopted by the Board, GNSO policy recommendations become binding on all ICANN-contracted parties through Registry Agreements and Registrar Accreditation Agreements.

Stage 7: Implementation and Compliance

Policy adoption by the Board is not the end of the PDP journey — it is the beginning of implementation. ICANN staff develop implementation guidance, update contracts and consensus policies, and communicate changes to registries and registrars. ICANN’s Contractual Compliance team monitors adherence to new policies and investigates complaints about non-compliance. Implementation reports are published publicly, maintaining the transparency that characterizes the entire PDP.

Why the ICANN Policy Development Process Matters — For Everyone

The ICANN Policy Development Process is not a bureaucratic formality. It is the mechanism through which policies that affect hundreds of millions of domain names and billions of internet users are developed — and it is open to your participation. Here is why this matters, specifically.

It Produces Policies That Actually Work Policies developed through the PDP reflect the full range of technical, commercial, legal, and public interest considerations because all of those perspectives participate in developing them. This multi-perspective scrutiny catches practical problems before policies are implemented, produces rules that are technically feasible, legally coherent, and commercially viable, and generates outcomes that the community understands and accepts because they helped shape them.

It Gives Individual Users a Formal Voice in Rules That Govern Them Domain name registrants — individual people and small businesses who register domain names — are directly governed by the policies that emerge from the PDP. Through public comment periods, through non-commercial civil society participation in GNSO working groups, and through At-Large community representation, individual users have formal channels to ensure their interests are represented in the policies that govern their digital presence.

It Has Produced Real Policy Outcomes That Changed the Internet The UDRP — the Uniform Domain-Name Dispute-Resolution Policy that allows trademark owners to challenge bad-faith domain registrations worldwide — emerged from the PDP. The WHOIS/RDAP policy framework that balances registration data transparency against GDPR privacy protections emerged from the Expedited PDP. The DNS Abuse Framework, the new gTLD program policies, the domain name transfer policies — all are PDP outputs. These are not obscure technical rules: they are the governance architecture that shapes how hundreds of millions of domain names are managed globally.

It Is the Model for Democratic Digital Governance The ICANN Policy Development Process is increasingly cited as a template for how technical and policy standards for the internet should be developed — not by governments acting alone, not by corporations setting their own rules, but by communities of affected parties deliberating transparently toward consensus. As internet governance debates expand to cover AI, data, platform regulation, and cybersecurity, the PDP’s model of structured, open, multi-stakeholder deliberation is the most viable alternative to both governmental overreach and corporate self-regulation.

How to Participate in the ICANN Policy Development Process?

The PDP is genuinely open to anyone — and your participation can be as light-touch or as deep as your interests and capacity allow. Here is a practical progression from first engagement to active contribution.

The easiest starting point is submitting a public comment. Visit icann.org/public-comments and browse the open consultations. Find one on a topic relevant to your expertise or interests — whether you are a domain name registrant concerned about WHOIS privacy, a trademark professional interested in dispute resolution, or a cybersecurity researcher with views on DNS abuse policy. Write a clear, reasoned comment of any length and submit it through ICANN’s online form. Your comment will be formally acknowledged, read, and responded to by the relevant working group.

A deeper level of engagement is joining a GNSO working group as a formal member. Browse active PDPs at gnso.icann.org and identify a working group relevant to your interests. Email the working group’s mailing list or the GNSO Secretariat expressing your interest in joining. You will be added to the mailing list, given access to the working group’s document archive, and invited to participate in weekly video conference calls. You can contribute as much or as little as your time allows — reading the email list and occasionally sharing a perspective is valuable participation even if you cannot attend every call.

For those who want to engage at the deepest level, representing a Stakeholder Group or Constituency in the GNSO is the most formal and influential participation channel. Each of the GNSO’s constituent bodies has its own membership process. Non-commercial civil society organizations can join the Non-Commercial Stakeholder Group (NCSG). Commercial users can join the Commercial Stakeholder Group (CSG). Intellectual property interests can join the Intellectual Property Constituency (IPC). Joining one of these bodies as a member gives you the ability to formally represent your organization’s interests in the GNSO’s deliberative processes, including voting rights at the Stakeholder Group level.

🎯  Quick Start:  Go to icann.org/public-comments right now. Find one open consultation. Spend 30 minutes reading the issue summary. Write one paragraph sharing your perspective. Submit it. You have just participated in the ICANN Policy Development Process — and your comment will be formally read and responded to by a global community of internet governance professionals.

ICANN Policy Development Process: Key Facts

PDP Fact	Detail
Primary PDP body	GNSO (Generic Names Supporting Organization) — for gTLD domain name policies
Working group membership	Open to anyone — no fee, no application, no organizational requirement
PDP Charter requirement	Every PDP must have a Charter defining scope, questions, timeline, and deliverables
Public comment periods	Minimum 30 days for Initial Report; 45-60 days for Final Report — mandatory
Comment response requirement	Working groups must formally respond to every substantive public comment received
Typical PDP duration	18 months to 3+ years from initiation to Board adoption, depending on complexity
GNSO Council vote threshold	Super-majority required for full consensus — prevents any single group from dominating
Notable PDP outputs	UDRP, WHOIS/RDAP policy, DNS Abuse Framework, new gTLD program policies, transfer policies
ICANN Fellowship access	Fellowships fund attendance at ICANN meetings where PDP working groups meet in person
Policy accountability	Adopted policies become binding on registrars and registries through ICANN contracts

UNIQUE FEATURE:  The Expedited PDP — When the Internet Cannot Wait

The Expedited PDP: ICANN’s Fast-Track Policy Mechanism

The standard ICANN Policy Development Process is thorough, but it is not fast. When urgent policy issues arise — particularly those with legal deadlines or significant operational implications — ICANN’s community can invoke the Expedited Policy Development Process (EPDP), a modified version of the PDP designed to move more quickly while maintaining the core multi-stakeholder character of the standard process.

The EPDP was most prominently used in response to the European Union’s General Data Protection Regulation (GDPR), which came into force in May 2018 and created immediate legal uncertainty about ICANN’s WHOIS policy. WHOIS — the database of domain name registrant information — had historically been publicly accessible, but GDPR’s data protection requirements conflicted with this open access model for European registrants. ICANN needed a new policy framework quickly, and the standard PDP timeline of years was not compatible with the legal urgency.

The EPDP on WHOIS, which ran in two phases from 2018 to 2021, demonstrated both the strengths and the challenges of the fast-track approach. It successfully produced a new Registration Data Policy framework that balances data privacy with legitimate access needs — an outcome that a years-long standard PDP would have delivered too late. But it also showed that even expedited multi-stakeholder deliberation takes time: the two-phase EPDP ran for over two years and generated thousands of pages of deliberation records. Speed in the PDP is relative — the commitment to transparency and community input imposes a minimum floor on how quickly consensus can legitimately be reached.

The EPDP experience has informed ongoing discussions about how to make ICANN’s policy development more agile without sacrificing the legitimacy that comes from genuine community deliberation. This balance — between speed and legitimacy, between efficiency and inclusiveness — is one of the central governance design challenges facing ICANN as the internet’s policy agenda continues to grow in complexity and urgency.

🔄  EPDP Lesson:  The Expedited PDP shows that when the community has genuine urgency and genuine will, ICANN’s policy development can move faster than its standard timeline suggests. But it also confirms that there is no shortcut to the legitimacy that comes from transparent, multi-stakeholder deliberation — the community will not accept policies that bypass that process, regardless of the urgency.

Frequently Asked Questions

Q1: What is the ICANN Policy Development Process and who participates in it?

The ICANN Policy Development Process (PDP) is the structured, multi-stakeholder mechanism through which ICANN’s Generic Names Supporting Organization (GNSO) develops consensus policy recommendations for generic domain names. Participants include registry operators (companies that run TLD databases like Verisign for .com), registrars (companies that sell domain names like GoDaddy), intellectual property interests, commercial users, Internet Service Providers, non-commercial civil society organizations, and any interested individual who chooses to engage through public comments or working group participation. The process is open to everyone — no fee, no organizational affiliation, no technical prerequisite is required to participate.

Q2: How long does the ICANN Policy Development Process typically take?

The standard PDP typically takes between 18 months and 3 or more years from formal initiation to Board adoption, depending on the complexity of the issue and the degree of consensus in the community. The WHOIS Expedited PDP, which was designed to move faster, still ran for over two years in two phases. The time commitment reflects the thoroughness of the process: working groups must hear from all relevant stakeholders, consult experts, consider public comments, document their deliberations transparently, and reach genuine consensus rather than simply taking a majority vote. ICANN has ongoing initiatives to improve PDP efficiency, but the community is resistant to reforms that would sacrifice thoroughness for speed.

Q3: What is the difference between a PDP and a public comment period?

A public comment period is one component of the broader PDP — it is a specific window during which ICANN publishes a document for written community input. Public comments can be submitted by anyone through ICANN’s online system, and working groups must formally respond to every substantive comment. A PDP, by contrast, is the complete policy development journey: from issue identification through Issue Report, GNSO Council initiation, Charter development, working group formation, deliberation, public comment periods, GNSO Council vote, and Board adoption. A public comment period is the broadest participation channel; full working group membership is the deepest. Both are valuable, and they serve different roles in the overall process.

Q4: How do ICANN policies affect me as an individual domain name registrant?

ICANN policies directly govern the terms under which you own and use your domain name. The Registrar Accreditation Agreement (RAA) sets the standards your registrar must meet in how it manages your registration, handles your personal data, and processes domain transfers. The UDRP governs how your domain can be challenged by trademark owners and what rights you have in that dispute. The WHOIS/RDAP Registration Data Policy determines what information about you is collected and who can access it. New gTLD policies determined whether new domain extensions like .shop or .africa exist for you to register under. None of these policies were written by a government acting alone — they emerged from the PDP, where civil society participation specifically representing user interests can and does influence outcomes.

Q5: Are ICANN policies legally binding, and what happens if a registrar or registry violates them?

ICANN policies are legally binding on all contracted parties — the registrars and registry operators who have signed ICANN’s contracts. They are binding not through sovereign legal authority (ICANN is not a government) but through contract: registrars sign the Registrar Accreditation Agreement and registries sign Registry Agreements, both of which incorporate ICANN consensus policies as binding contractual obligations. Violations are handled by ICANN’s Contractual Compliance team, which investigates complaints, issues formal breach notices, requires corrective action plans, and can impose sanctions up to and including termination of accreditation. Domain name registrants who experience violations can report them directly to ICANN’s compliance team at icann.org/resources/compliance.

The Internet’s Policy Is Written by the People Who Show Up. The ICANN Policy Development Process is one of the most consequential and least-known governance mechanisms in the digital world. The policies it produces govern hundreds of millions of domain names and shape the digital environment for billions of people. And it is genuinely, structurally open to your participation — not as a courtesy, but as a design requirement. Whether you submit one public comment or join a working group for three years, your engagement makes the process more representative — and the resulting policies more legitimate. Start Participating Today Submit a public comment at icann.org/public-comments — open to everyone, right now Browse active working groups at gnso.icann.org — join one on a topic you care about Learn ICANN policy fundamentals free at learn.icann.org — Introduction to ICANN Apply for ICANN Fellowship at icann.org/fellowships — attend meetings in person, funded Join the GNSO’s Non-Commercial Stakeholder Group at gnso.icann.org/en/about/stakeholders-constituencies/ncsg Attend the next ICANN Public Meeting virtually — free at icann.org/meetings The PDP is where internet governance becomes real. Your voice belongs in that conversation. Go put it there.

© 2026 Internet Governance Expert Blog. Published for educational purposes only.