Law Enforcement Guidelines

1. Where to send a request

Direct all requests in writing to legal@ampersand-hosting.test. We do not accept lawful requests by phone, fax, or social media. A courier-delivered original may be required for certain orders; we will confirm a delivery address on request.

For urgent matters where a delay risks loss of life, see §7 Emergency Disclosure.

2. What we require

We respond only to legally valid requests issued by a competent authority and addressed to Ampersand or its Swiss legal entity. Specifically:

• Swiss requests must be issued under the relevant Swiss procedural law — typically BÜPF/SCPT for surveillance, the StPO/CPP for criminal procedure, or applicable administrative law — and bear judicial authorisation where the statute requires it. Real-time interception orders must comply with BÜPF Art. 269 ff CPP.
• Foreign requests must be channelled through the Swiss Federal Office of Justice (FOJ / OFJ / BJ) via mutual legal assistance (MLAT) procedures. We do not act on direct foreign subpoenas, civil discovery orders, or administrative requests issued outside Switzerland's jurisdiction.
• Requests must identify (a) the issuing authority, (b) the legal basis, (c) the user or account by an identifier we can map (registered email, account ID, or secret link), and (d) the specific data sought and time window.

Overbroad or vague requests will be challenged. We will narrow, object, or seek judicial review where appropriate.

3. What we can produce

Subject to a valid order and the user's plan retention period, the following data is producible:

• Account data — registered name, email address, account creation date, last login timestamp, IP at registration. Passwords are stored only as bcrypt hashes and are not producible as plaintext.
• Access logs — for a given secret link, the IP addresses, user-agents, country codes, timestamps, and per-access watermark identifiers that recorded each view or verification attempt.
• Recipient data — when a user sent a secret to named recipients, the recipient email and (if provided) phone, first name, last name, and verification timestamps.
• Document signatures — typed name, email, phone, signature image, IP address, country, the SHA-256 hash of the signed document at signing time, and the verification status (whether email and SMS were verified at signing).
• Encrypted secret content — the ciphertext blob for a specified secret. This is not the plaintext (see §4).

Retention windows depend on the user's plan: 30 days on the Personal tier, 1 year on Team, configurable on Enterprise. Data older than the retention window has been purged and is not recoverable.

4. What we cannot produce

By design, we do not have technical access to the plaintext of any secret. Content is encrypted with a key derived from APP_KEY × team_key × unique_id × (optional user password). We do not store the user's password, we encrypt team_key at rest, and we do not retain combined derivations.

A request that demands plaintext content is a request for something we do not possess and cannot produce. We will respond by confirming this limitation. Where an authority is empowered to do so under BÜPF, a forward-looking interception order may compel us to alter the Service to capture cleartext on future submissions from a specific account; that does not retroactively unlock past secrets.

5. Notification of users

Our default is to notify the affected user of a legal request, including the identity of the requesting authority and a copy of the request, before producing data. We delay or suppress notification only where:

• a non-disclosure order from a competent authority specifically prohibits notification;
• a credible risk to life or physical safety exists; or
• notification would defeat the legitimate investigative purpose of the order, as determined by the issuing authority and confirmed in writing.

Where notification is delayed by a non-disclosure order, we notify the user as soon as that order lapses or is lifted.

6. Preservation requests

We honour preservation requests from competent Swiss authorities for up to 90 days, extendable on a renewed request. A preservation request alone does not authorise production — a separate order issued under the appropriate statute is still required for us to hand over data.

7. Emergency disclosure

Where we have a good-faith belief that an emergency involving imminent risk of death or serious physical harm requires immediate disclosure, we may produce data without prior order. Emergency requests must come from a recognised law-enforcement contact and include enough detail for us to make that good-faith assessment. We document every emergency disclosure and review it with counsel after the fact.

8. Costs

We may, where permitted by law, charge cost-recovery for the engineering and legal time required to respond to a request. Costs are waived for emergency requests and for requests narrow enough that they take less than thirty minutes to action.

9. Transparency report

Beginning in the calendar year after launch, we publish an annual transparency report summarising the number of requests received by type and outcome, the number of accounts affected, and the number of requests challenged or rejected. Aggregate counts only — no user-identifying information.

10. Pushback

We push back on requests that are vague, overbroad, lack a valid legal basis, target political activity protected under Swiss law, or appear to be aimed at chilling legitimate use of the Service. We are willing to litigate to the appropriate Swiss court where we believe a request crosses these lines.

11. Questions

Authorities seeking guidance on the form of a request before issuing it may contact legal@ampersand-hosting.test. Users with questions about how their data may be disclosed should consult our Privacy Policy or contact privacy@ampersand-hosting.test.