Preparing for ICANN Audits Under the New RDAP Specification

As ICANN prepares for a new round of generic top-level domains (gTLDs), the transition from the legacy WHOIS protocol to the Registration Data Access Protocol (RDAP) is emerging as a critical focal point for both compliance and technical readiness. RDAP, developed by the Internet Engineering Task Force (IETF), is intended to modernize domain registration data access, providing structured, machine-readable, and secure data exchanges. For registries and registrars, the implications go beyond technical implementation; RDAP now plays a central role in ICANN’s audit and compliance frameworks. Preparing for these audits under the RDAP specification demands a meticulous understanding of operational standards, data handling obligations, and the audit-readiness posture required to meet the expectations of ICANN’s Contractual Compliance team.

The shift to RDAP is not merely a protocol upgrade—it represents a philosophical and architectural departure from WHOIS. Unlike WHOIS, which returns unstructured plain text and is typically queried through simple port-43 requests, RDAP operates over HTTPS and uses standardized JSON responses that can be parsed, validated, and integrated into automated compliance tools. This change allows ICANN to conduct audits with far greater granularity, verifying compliance with contractual requirements in a programmatic fashion. It also opens the door to more frequent and targeted audits, as non-compliant patterns can be algorithmically identified across large data sets without the need for manual sampling.

One of the core features of RDAP is the ability to tailor output based on authentication and authorization levels. Under ICANN’s current RDAP profile, registries and registrars must implement differentiated access models that restrict sensitive data, such as registrant contact details, unless specific legal grounds or authentication credentials are provided. For audit purposes, this means operators must maintain detailed access control logs, authentication records, and documentation of their data disclosure policies. ICANN’s audits will likely examine whether RDAP services are properly enforcing these restrictions and whether the returned responses comply with the defined profile for both public and gated queries.

To prepare, registry and registrar operators must ensure their RDAP services are not only technically compliant but also auditable. This includes deploying full support for standard error codes, such as HTTP 403 for unauthorized access or HTTP 429 for rate-limited queries. Logs must accurately reflect timestamps, IP addresses, query patterns, and access decision rationales. Operators should also implement version control for their RDAP configurations and maintain up-to-date documentation that maps system behavior to ICANN’s expectations. In many cases, compliance teams will need to collaborate with engineering teams to cross-verify that business logic, authentication workflows, and data redaction layers align with RDAP output.

Another significant component of ICANN audits under RDAP is accuracy verification. RDAP facilitates validation of structured data fields such as email addresses, domain statuses, registrar IDs, and registration dates. This allows ICANN to perform cross-checks against registry zone files, registrar accreditation data, and escrow deposits to ensure consistency across systems. Registries and registrars must therefore ensure that the data served by their RDAP endpoints precisely matches what is maintained in their authoritative databases. Discrepancies—such as an expired domain showing as active, or missing registrar details—could trigger further scrutiny or enforcement actions.

Moreover, ICANN has made clear that future audits will assess RDAP compliance in the context of privacy regulations, particularly the GDPR. Operators must be able to demonstrate lawful bases for disclosing personal data and ensure that redacted fields are consistent with stated legal policies. RDAP makes this process more transparent, as each field is separately encoded and can include remarks or notices indicating the reason for redaction. During audits, ICANN may request logs or attestations showing how decisions to redact or disclose data were made, along with evidence of the legal rationale—whether it’s based on consent, contractual necessity, or legitimate interest.

Beyond the technical and legal aspects, audit readiness under RDAP requires a shift in internal compliance culture. In the WHOIS era, many registrars treated compliance as an episodic activity—reacting to annual reviews or specific complaints. Under RDAP, the precision and visibility of data interactions demand a more proactive and continuous compliance model. Operators must conduct internal RDAP health checks, simulate ICANN-style audit queries, and implement automated monitoring for anomalies. This could involve nightly scans of RDAP output, validation against registrar records, and alerts for discrepancies in registration status or contact formatting.

ICANN’s Contractual Compliance department is also likely to incorporate RDAP audit findings into broader evaluations of registry and registrar performance. An operator that consistently returns malformed responses, fails to honor differentiated access, or provides inconsistent data may be flagged for closer scrutiny in other areas, such as data escrow compliance, abuse mitigation, or registration lifecycle handling. Conversely, those who demonstrate robust RDAP governance may benefit from reduced audit friction or eligibility for streamlined compliance reviews.

For new gTLD applicants, the stakes are even higher. Demonstrating RDAP readiness as part of the application process—especially for back-end registry providers—could become a key differentiator. Applicants must be able to show not just theoretical support for RDAP, but real-world deployment, validated schemas, and documented audit processes. The Application Guidebook may evolve to require explicit RDAP conformance declarations, and ICANN evaluators may seek to confirm these capabilities through pre-delegation testing or third-party assessments.

Ultimately, preparing for ICANN audits under the new RDAP specification is not about checking a box. It is about building a verifiable, transparent, and privacy-respecting data infrastructure that supports both operational excellence and public trust in the DNS. As RDAP becomes the foundation for how registration data is accessed and assessed, every registrar and registry must take proactive steps to ensure their systems, policies, and teams are aligned. The next generation of domain governance will depend on this alignment—shaped not just by protocol design, but by a shared commitment to accountability, accuracy, and lawful data stewardship.

As ICANN prepares for a new round of generic top-level domains (gTLDs), the transition from the legacy WHOIS protocol to the Registration Data Access Protocol (RDAP) is emerging as a critical focal point for both compliance and technical readiness. RDAP, developed by the Internet Engineering Task Force (IETF), is intended to modernize domain registration data…