Law Enforcement Guidelines

In short. We respond to valid legal orders. We can produce account, billing and technical information and your stored data as encrypted data. We hold no decryption keys, so no order can make us hand over the readable contents of a customer's files. That data does not exist in readable form on our side.

How to serve a request

Send legal orders and requests to abuse@hoodik.io. Hudik d.o.o. is established in Croatia, and its courts and authorities are the proper channel. Authorities in other EU member states may use the European Production and Preservation Order procedure through our designated establishment in Croatia. Authorities outside the EU should use a mutual legal assistance (MLAT) request or an equivalent recognised channel.

We do not act on informal requests. A valid order must identify the issuing authority and its legal basis, state its reasons, identify precisely the data or content it concerns, and be limited to what is necessary and proportionate. We review every order for validity and scope, and we will push back on, or challenge, orders that are overbroad or defective.

For Instances running in the US region, we respond to valid US legal process through the appropriate channels, while remaining limited to the same categories of data described below: account metadata, logs, and encrypted exports only.

What we can produce

The information that exists on our side for us to produce is:

• Account data: the account holder's email address, chosen region, plan and subscription status.
• Billing references: payment and invoice references. Card and payment details are held by our payment provider, not by us (see the note below).
• Instance information: the region an Instance runs in, its storage usage, and its running state.
• Access logs: IP addresses, timestamps and basic request metadata, for as long as we retain them (30 days).
• Stored data, as encrypted data: the same encrypted export the customer can download themselves.

We hold no decryption keys, so no order can yield the readable contents of a customer's files, not because we refuse, but because that data does not exist in readable form on our side. Separately, and honestly: the law can require technical assistance that we cannot refuse on the grounds that it is impossible (for example, producing the technical metadata above). What no amount of assistance can produce is a decryption key we do not have. We hold operational credentials necessary to provision, monitor, back up and recover the encrypted Instance; these do not give us access to decryption keys or plaintext content, and we store only ciphertext.

What different orders can and cannot achieve

• An order to produce data is satisfied by the categories above. For stored data, producing the encrypted export is full compliance; encrypted data can be produced whether or not it is readable, and there is no obligation on us to decrypt it.
• An order to remove or disable content is met by the most precise action available to us: revoking a specific public link, disabling the specific stored objects behind it, or, where necessary, suspending the Instance.
• An order to preserve data is met by holding the relevant encrypted data and logs for the period the order requires; during a preservation order we do not delete the data on our normal schedule. A preservation order can only require us to retain data that already exists in our systems (encrypted Content and metadata); it cannot require us to create plaintext or to obtain keys we do not hold.

Requests to our providers

Our payment provider and other sub-processors are separate companies in their own countries. An authority can require information (for example a customer's billing identity) directly from them under their own laws, independently of us and possibly without our knowledge. Our commitment to notify affected customers cannot extend to requests made directly to those companies.

A note on encryption and the account holder

The readable contents of a customer's files can only be unlocked with the customer's own password, which we do not hold. In some countries an authority may be able to require a person to hand over their password or to unlock their own device. That is a matter between the authority and the individual; it is not something we can do or assist with, because the password never reaches us.

Notifying customers

Where the law allows, we tell an affected customer about a request concerning their account, so they can seek their own legal advice. Where an order lawfully prohibits us from doing so, we comply with that requirement. We will not mislead a customer, but we will keep the secrecy the law requires. Our transparency statement below is the safeguard that remains when an order is secret.

Transparency statement

We publish aggregate figures for the legal orders we receive, and update them at least once a year. For the period from launch to 8 July 2026:

As of 8 July 2026, Hudik d.o.o. has never received a secret or gagged order, has never been required to weaken, bypass or backdoor the encryption in Hoodik Cloud, and has never built or deployed any capability to read customer content. We intend to keep this statement current. If it is not renewed on schedule, or if it is removed, that should be treated as meaningful.

Contact

abuse@hoodik.io · Hudik d.o.o., Kapelska 6, 31000 Osijek, Croatia.