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 gTLD non-public registration data requests, NiceNIC requires requesters to submit their requests through ICANN’s Registration Data Request Service, also known as RDRS, where applicable.
RDRS is a centralized ICANN system that allows eligible requesters, including law enforcement personnel, government officials, cybersecurity specialists, consumer protection advocates, intellectual property professionals, and other parties with a legitimate interest, to submit standardized requests for gTLD non-public registration data.
Before submitting a request through RDRS, requesters should first check whether the requested data is already publicly available through ICANN Lookup.
When submitting a request through RDRS, requesters must include:
The exact domain name
The requester’s identity and contact information
The requester category, such as law enforcement, cybersecurity, intellectual property, consumer protection, or other
The specific registration data elements requested
The purpose of the request
The legal basis or specific rationale for the request
Whether confidentiality is requested
Any supporting legal process or documentation
A good-faith statement
Confirmation that any disclosed data will be processed lawfully
NiceNIC does not process ordinary email requests as formal gTLD non-public registration data disclosure requests where RDRS is available.
Ordinary emails requesting non-public gTLD registration data may be answered by directing the requester to submit the 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 denied or returned without disclosure.

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

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.