Request for Disclosure of Non-Public Registrant Data

Request for Disclosure of Non-Public Registrant Data
For privacy and data protection reasons, personal information contained in domain registration data is no longer fully displayed in public WHOIS results.
As an ICANN-accredited registrar, NiceNIC provides a process for eligible third parties to request access to non-public registration data for generic top-level domain names, also known as gTLDs.
This policy explains how third parties may request access to non-public registration data, what information must be included, how requests are reviewed, and what types of data are outside the scope of this process.
All requests are reviewed in accordance with ICANN policy, applicable law, privacy requirements, data protection principles, and data minimization standards.
Submitting a request does not guarantee disclosure.

Scope of This Policy
This policy applies only to requests for non-public registration data associated with gTLD domain names sponsored by NiceNIC.
Examples of gTLDs include:
.com
.net
.org
.info
.biz
.xyz
.shop
.online
.site
.top
This policy does not apply to ccTLD domain names, such as .rs, .de, .uk, .cn, .io, .me, or other country-code domain names.
ccTLD-related requests are subject to the applicable registry rules, local legal requirements, upstream provider policies, and NiceNIC’s internal compliance review.

What Data May Be Requested
This process may be used to request limited non-public domain registration data, such as:
Registrant name
Registrant organization
Registrant email address
Registrant phone number
Registrant postal address
Administrative contact data
Technical contact data
NiceNIC reviews each request on a per-domain basis.
NiceNIC does not provide bulk search results, partial-match results, speculative data, or registration data across multiple related domains through this process.

What Data Is Not Covered by This Process
This process is limited to non-public domain registration data only.
It does not cover:
Payment records
Cryptocurrency transaction details
Credit card, PayPal, bank, or wallet information
Account login history
IP logs
Customer support communications
Email correspondence
Hosting data
Server logs
Associated account records
Historical or archived registration data
Internal compliance records
Law enforcement correspondence or investigative materials
Requests for these types of records may require separate legal process, additional verification, or review under a different compliance procedure.

Key Considerations

1. Legitimate Interest
A requester must demonstrate a legitimate interest in the non-public registration data requested.
The request must clearly explain:
Who is requesting the data
What specific data is requested
Why the data is needed
The legal basis or specific rationale for the request
How the requested data will be used
Why less-intrusive methods are not sufficient
How the requester will protect and process any data received
NiceNIC will review the requester’s stated interest against the rights, freedoms, privacy interests, and legitimate expectations of the data subject.

2. Less-Intrusive Mechanisms
Before requesting non-public registration data, requesters should first consider whether a less-intrusive method is available.
Depending on the situation, alternatives may include:
Using public WHOIS or RDAP results
Using ICANN Lookup
Using a domain holder contact form, where available
Submitting an abuse report
Submitting a trademark or copyright complaint
Using UDRP, URS, court, or other dispute resolution procedures
Contacting the website operator, hosting provider, or DNS provider where appropriate
NiceNIC may deny or limit a request if a reasonable and less-intrusive method is available.

3. Data Protection
Requesters must confirm that they will handle any disclosed personal data lawfully and securely.
This includes maintaining appropriate technical and organizational safeguards, limiting use of the data to the stated purpose, preventing unauthorized disclosure, and complying with applicable privacy and data protection laws.
NiceNIC may request additional information if the requester’s data protection safeguards are unclear or insufficient.

4. Data Minimization
NiceNIC applies a data minimization approach.
This means NiceNIC may approve only part of a request, provide only the data elements necessary for the stated purpose, or deny data elements that are excessive, unsupported, or outside the scope of registration data disclosure.

5. Case-by-Case Review
Each request is reviewed on its own merits.
NiceNIC may approve, partially approve, deny, or request additional information.
A prior decision does not guarantee the same result for future requests.

How to Submit a Request
For requests seeking disclosure of non-public gTLD registration data, NiceNIC requires requestors to submit their requests through ICANN's Registration Data Request Service, also known as RDRS, where RDRS is available and applicable.
RDRS is a centralized ICANN service that enables law enforcement agencies, government authorities, cybersecurity professionals, consumer protection organizations, intellectual property professionals, legal representatives, and other parties with a legitimate interest to submit standardized requests for access to non-public gTLD registration data.
Before submitting a request through RDRS, requestors should first check whether the requested registration data is already publicly available through ICANN Lookup.

When submitting a request through RDRS, requestors must include:
  • The exact domain name.
  • The requestor's identity and contact information.
  • The nature and type of the requestor, including whether the requestor is an individual, legal entity, law enforcement agency, government authority, intellectual property representative, cybersecurity professional, consumer protection organization, or another type of organization.
  • Where the request is submitted by a representative acting on behalf of another person or entity, a Power of Attorney statement or similar documentation evidencing the representative's authorization to act on the requestor's behalf, where applicable and relevant.
  • A list of the specific registration data elements requested.
  • The purpose of the request.
  • Information about the legal rights of the requestor and the specific rationale and basis for the request.
  • Whether confidentiality is requested.
  • Any supporting legal process, court order, subpoena, authorization, or other relevant documentation.
  • An affirmation that the request is being made in good faith.
  • An agreement that any registration data disclosed in response to the request will be processed lawfully.

NiceNIC does not treat ordinary email communications as formally submitted gTLD non-public registration data disclosure requests where RDRS is available and applicable.

A person who sends an ordinary email requesting non-public gTLD registration data may be directed to submit a properly formed request through RDRS.

Requests that are incomplete, unclear, overly broad, unsupported, outside the scope of registration data, or not submitted through the required channel may be returned for clarification or additional information. A request may be denied in whole or in part where NiceNIC determines, after considering the request on its merits, that disclosure is not justified or permitted under applicable law or ICANN policy.

Law Enforcement and Government Requests
Law enforcement or government agency requests for gTLD non-public registration data should be submitted through ICANN RDRS where applicable.
Direct emails from law enforcement, government, police, or similar agencies do not automatically authorize disclosure of non-public customer information.
NiceNIC will review such requests based on:
The domain type
The requested data elements
The legal basis provided
The stated purpose
Any supporting legal process
Confidentiality requirements
Applicable ICANN policy
Applicable law
Data minimization principles
Internal compliance approval
Requests for payment records, account logs, IP history, communications, hosting data, server data, or associated account records are outside standard registration data disclosure and may require separate legal process.
NiceNIC does not disclose non-public customer information solely because a request is sent from a government, police, or law enforcement email address.

ccTLD Requests
ICANN RDRS applies to gTLD non-public registration data only. It does not apply to ccTLD domain names.
For ccTLD-related requests, NiceNIC does not disclose non-public customer information through ordinary email requests.
Requesters may be required to provide valid legal process, registry-authorized instruction, or a clearly stated applicable legal basis.
ccTLD requests may also be subject to the rules and policies of the relevant country-code registry.

Response Timeline
For properly submitted gTLD non-public registration data disclosure requests that meet NiceNIC’s required format and are submitted through the required channel, NiceNIC will acknowledge receipt without undue delay and no later than two business days after receipt.
NiceNIC will respond without undue delay and no later than thirty calendar days after acknowledgement, unless exceptional circumstances apply.
A response may:
Approve the request
Partially approve the request
Deny the request
Request additional information
Explain that the requested data is publicly available
Explain that the request is outside the scope of this process
Explain that the request was not submitted through the required channel
Explain that separate legal process is required

Means of Providing Responses
NiceNIC will send the acknowledgement of receipt, any request for additional information, and the final response to the requestor using the contact information provided with the Disclosure Request, normally by email.
For requests submitted through ICANN's Registration Data Request Service, NiceNIC will also update the request status and outcome in RDRS. Any approved non-public registration data, detailed denial rationale, or other sensitive information will be provided outside RDRS by email or another secure transmission method agreed with the requestor.
If a request is denied in whole or in part, the response will identify the specific reasons for the decision and provide an explanation sufficient for the requestor to understand how the decision was reached. Where applicable, the response will explain how the requestor's legitimate interest was balanced against the rights and freedoms of the data subject.

Reasons a Request May Be Denied
NiceNIC may deny or limit a request if:
The request does not identify an exact domain name
The domain is not sponsored by NiceNIC
The domain is a ccTLD and the request is not supported by an applicable legal or registry basis
The requested data is outside the scope of registration data
The request was not submitted through the required channel
The request is incomplete or unclear
The requester does not provide a sufficient legal basis or specific rationale
The request is overly broad or speculative
The requester has not shown a legitimate interest
The request may prejudice the rights, freedoms, or privacy interests of the data subject
A less-intrusive method is available
The requester fails to confirm lawful data handling
The request seeks historical, archived, bulk, or unrelated account data
The request appears abusive, repetitive, misleading, or unsupported

Disclosure Decision
If NiceNIC determines that disclosure is appropriate, NiceNIC may provide limited registration data necessary for the stated purpose.
If NiceNIC determines that only part of the request is justified, NiceNIC may provide a partial disclosure.
If NiceNIC determines that the request is not sufficiently supported, no non-public registration data will be provided.
NiceNIC may require additional verification, documentation, or agreement terms before any disclosure is made.

Abuse Reports Are Separate From Data Disclosure Requests
A request for non-public registration data is not the same as an abuse complaint.
If a requester wants to report DNS abuse, phishing, malware, botnet activity, spam as a delivery mechanism, or other abuse involving a domain name, the requester should submit an abuse report through NiceNIC’s abuse reporting channel.
NiceNIC reviews abuse reports separately from registration data disclosure requests.
A request for information does not automatically result in domain suspension, clientHold, serverHold, or other domain-level action.
Domain restrictions are reviewed separately based on applicable evidence, registry requirements, ICANN obligations, and NiceNIC’s abuse handling procedures.

Important Notice
NiceNIC is committed to protecting customer privacy while also supporting legitimate and properly documented requests for non-public registration data.
This policy does not create an automatic right to access non-public registration data.
All requests are subject to review, applicable law, ICANN policy, registry requirements, data protection principles, and NiceNIC’s internal compliance procedures.