On this page
These guidelines are for
1. What we can and cannot provide
OffshoreServ is built to minimize data, so most requests can only ever return a small amount.
What we may hold for an account:
- the account email address (which may be private or disposable);
- payment transaction IDs and hashes, and the account's balance ledger;
- sessions and a security log that record the browser and the country, never an IP address; and
- service records: plans, IP addresses assigned, and renewals.
What we do not have:
- No traffic logs. We do not log or inspect customer server traffic, run deep packet inspection, or record what a server sends or receives.
- No content access for running servers. Customer servers are under the customer's control; we do not have their keys and we do not look inside them.
- No identity documents. We run
no KYC , so we have no name, address, phone, or ID to disclose. - No IP addresses for accounts.
Sign-ins are recorded with the browser and the country only.
2. What a valid request looks like
To be actionable, a request must:
- come through a court or authority competent in the jurisdiction where the server is located (Iceland, Switzerland, Moldova, Romania, the Netherlands, Bulgaria, or Malaysia);
- identify the account or service precisely (email, service ID, or IP address, with the relevant time frame);
- state the legal basis and specify what data is sought; and
- be properly issued and served on the operating entity stated in our Terms of Service.
Foreign authorities. An authority outside the server's country should proceed through the appropriate mutual legal assistance channel so the request is validated under the law of the location where the server runs. We are not bound by orders from jurisdictions that have no authority over that location, and a request under a law that does not apply, such as a
We review each request for validity and scope and respond only to the extent the law requires. Overbroad requests are narrowed or challenged. We also confirm that a request is genuine before acting, so send it through official channels and identify the issuing officer; we may decline to act on a request we cannot authenticate.
3. Emergency requests
Where there is an imminent threat to life, or a report of child sexual abuse material, we act immediately. In a genuine emergency we can respond to a request from a competent authority without waiting for the usual process, and we may act on our own initiative to remove CSAM and report it to the competent authorities. Emergency requests should be clearly marked as such, with a description of the threat and the time frame involved.
4. Preservation requests
A competent authority can ask us to preserve the limited records we already hold for a specific account while it obtains a proper order for disclosure. We honor valid preservation requests for a reasonable period. Preservation freezes existing data; it does not create new data, and it is not by itself an order to disclose. Several of our locations have specific preservation regimes, such as Moldova's
5. Customer notification
We believe customers should know when their data is sought. We notify the affected customer of a request, in their client area, unless we are legally prohibited from doing so, for example by a
6. How requests appear in the transparency report
We publish the number of
7. How to send a request
We have no email address for
Customers with an active dedicated or GPU server can ask us by ticket from the client area. To send something sensitive, encrypt it with our PGP key first.