Law Enforcement Requests.

Effective date: 2026-10-27.

These Law Enforcement and Government Request Guidelines (these "Guidelines") explain how wrxstack ("wrxstack", "we", "us") handles requests from law enforcement agencies, courts, regulators, and other government bodies (each a "Requesting Authority") for information about users of the wrxstack products, including Atlas at atlas.wrxstack.com and Folio, the portfolio and personal-site builder, at portfolio.wrxstack.com, and of the website at wrxstack.com (together, the "Service").

wrxstack is an independent product operated from India by a small team, and the Service is hosted in the United States. These Guidelines expand on section 7 of our Privacy Policy and section 8 of our Acceptable Use Policy. In short, we generally disclose user information only in response to valid legal process, in an emergency, or where the law requires us to report, we may challenge requests we consider overbroad or unlawful, and, where the law permits, we aim to tell the affected user or Customer before we disclose anything.

The short version

1. Scope and who these Guidelines are for

These Guidelines apply to any request, demand, order, or other legal process from a Requesting Authority, in any country, that seeks information about a user of the Service, or that asks us to preserve, restrict, or remove such information. They also explain how we respond to requests from private parties in legal proceedings, in section 5.

These Guidelines do not cover requests to remove content because it is unlawful or infringing. Copyright notices follow our Copyright and DMCA Policy, and reports of other misuse follow section 6 of our Acceptable Use Policy. Security researchers should use our Responsible Disclosure Policy.

2. Our principles

• Legal process first. We do not disclose user information to a Requesting Authority voluntarily, except in the emergency cases described in section 7 and the reports described in section 18.
• Specific, not bulk. A request must identify the accounts it concerns. We generally decline requests for information about users in general, about all users who meet a broad description, or for ongoing access.
• The least information. Where we must disclose, we aim to disclose only the information that the process legally compels, for the accounts and time period it names.
• Challenge what is wrong. We may ask Requesting Authorities to narrow or withdraw requests we consider overbroad, unclear, or unlawful, and where we consider it appropriate we may object formally, as described in section 12.
• Tell the user. We aim to notify affected users and Customers before disclosure where the law allows and it is appropriate, as described in section 13.
• No direct access. We have not built, and do not intend to build, any means for a government body to access our systems or user information directly, in bulk, or without going through us. We do not hold encryption keys on behalf of any government.

3. Legal process we require in the United States

wrxstack is operated from India, and the Service is hosted in the United States. Requests from US federal, state, and local authorities must comply with US law, including the Stored Communications Act, 18 U.S.C. sections 2701 to 2713, and the Fourth Amendment to the US Constitution. The table below sets out the minimum process we require for each kind of information.

Except as described in section 7 and section 18, we require a search warrant for content, including where a statute would otherwise allow a lower standard. A request that cites the wrong form of process for the information it seeks may be treated as a request for only the information that its form of process supports.

4. Requests from India and other countries

4.1 Requests from Indian authorities

Indian authorities must make requests in writing under a provision of Indian law that authorizes them, for example a notice or order under section 94 of the Bharatiya Nagarik Suraksha Sanhita, 2023, a direction under section 69 or section 69A of the Information Technology Act, 2000, an order or notice under section 79(3)(b) of that Act, a direction of CERT-In under section 70B of that Act, or an order of an Indian court. We review each request for its legal basis, its scope, and whether the officer making it has the authority to do so, and we respond as the law requires.

4.2 Requests from other countries

A Requesting Authority outside India and the United States must use a legal channel that binds wrxstack under US law or under an international instrument that applies to us. These channels include:

• a request made through a Mutual Legal Assistance Treaty or a letter rogatory, so that a US court issues process that we can act on;
• an order issued under an executive agreement made under the US CLOUD Act, 18 U.S.C. section 2523, such as the agreement between the United States and the United Kingdom, where the order meets the terms of that agreement; and
• an order under another international instrument that applies to us directly, such as the European Union's e-Evidence Regulation (Regulation (EU) 2023/1543), which we will handle as that instrument requires, including its grounds for refusal and review.

Except in an emergency under section 7, we generally do not disclose user information in response to a request from an authority outside India and the United States that comes to us directly and does not use one of these channels. Where the information is personal data protected by the EU or UK General Data Protection Regulation, we also take into account Article 48 of that Regulation, which limits the effect of a foreign authority's order unless it is based on an international agreement such as a Mutual Legal Assistance Treaty.

Where we process personal data for a Customer under our Data Processing Addendum and the Standard Contractual Clauses, we also follow our duties under those Clauses when a public authority requests that data. As the Clauses require, these include, where the law allows, notifying the Customer of the request, reviewing its lawfulness, challenging it where there are reasonable grounds to consider it unlawful, disclosing only the minimum information the request lawfully requires, and keeping a record of the request and our response.

5. Civil and private-party requests

The Stored Communications Act does not permit us to disclose the content of a user's communications or files in response to a civil subpoena, including one issued in a lawsuit between private parties or by a defense lawyer in a criminal case. If you need a user's content for a legal proceeding, ask the user for it, or ask the court to order the user to produce it.

We may disclose basic non-content information to a private party only in response to a valid subpoena or court order that is properly served and enforceable against us, and generally only after we have notified the user, where the law permits, and given them a reasonable opportunity to object or to seek a protective order, unless a court orders otherwise.

6. Data controlled by an organization

Where a user works in a workspace that is controlled by an employer or other organization (the "Customer"), that Customer is the controller of the content in its workspace, and we process that content on its behalf. Requests for the content of an organization's workspace should be directed to the organization itself, which controls the data and is best placed to respond. This approach follows published US Department of Justice guidance that agencies should seek data from an enterprise directly where practicable.

If we receive a request for data that a Customer controls, we may ask the Requesting Authority to seek it from the Customer, unless the law prohibits us from doing so or the Authority shows that approaching the Customer would put the investigation at risk. If we are legally compelled to disclose the data ourselves, we aim to notify the Customer before disclosure where the law permits, as the DPA requires and consistent with section 13 and our Data Processing Addendum.

7. Emergency disclosure requests

US law allows a service provider to disclose information to a government body without legal process where the provider believes in good faith that an emergency involving danger of death or serious physical injury to any person requires disclosure without delay (18 U.S.C. sections 2702(b)(8) and 2702(c)(4)). We may also apply this standard to emergency requests from authorities outside the United States, where the law that applies to us allows it.

To make an emergency request, email contact@wrxstack.com from an official government email address with the subject line "Emergency disclosure request", and include:

• the name of your agency, and your name, rank or title, and direct telephone number;
• the nature of the emergency, and who is at risk of death or serious physical injury;
• why the risk is immediate, and why the information cannot wait for legal process;
• the account identifiers concerned, as described in section 9; and
• the specific information you need to address the emergency.

We decide each emergency request on its own facts. We aim to disclose only the information we believe is needed to prevent the harm described, and we may ask for valid legal process before disclosing anything further. We may confirm the request by telephoning the agency through a publicly listed number. A request that does not describe a genuine emergency may be treated as a request for disclosure under ordinary legal process.

8. Preservation requests

A Requesting Authority may ask us to preserve records while it obtains legal process. Under 18 U.S.C. section 2703(f), a US governmental entity may request preservation for 90 days, and may extend that period by a further 90 days with a renewed request. When we receive a valid preservation request, we take the steps that section requires to preserve a copy of the identified records that exist at the time of the request.

• Preservation is not disclosure. We do not release preserved records without valid legal process under section 3 or section 4.
• A preservation request must identify the accounts concerned and should name the categories of records and the time period it covers. Requests for future records, or for records that do not yet exist, are not preservation requests.
• If we do not receive valid legal process before the preservation period ends, and no renewed request arrives, the preserved copy may be deleted without further notice.
• Records that were already deleted before the request, including records removed under our Data Deletion Policy, may no longer be available.

Requests from outside the United States to preserve records should be made through the channels in section 4, or through the network of national contact points under the Council of Europe Budapest Convention on Cybercrime, where it applies.

9. How to submit a request

Send all requests by email to contact@wrxstack.com, with the subject line "Law enforcement request" or "Preservation request". Attach the legal process as a PDF. Each request should include:

1. Who you are. The name of the agency or court, the name and title of the requesting official, an official government email address, and a direct telephone number.
2. The accounts concerned. At least one specific identifier for each account, such as the email address used to sign in, the Atlas workspace address, or the full Folio page address (for example, a link on portfolio.wrxstack.com). We cannot search for users by name alone, by a description, or by a general topic.
3. The information sought. A specific description of the categories of information you need, and the time period they cover.
4. The legal basis. A signed copy of the legal process, issued by a body with authority to issue it, with any case or reference number.
5. Any secrecy order. A copy of any court order that prohibits us from notifying the user, with its duration. See section 17.
6. A response deadline. Any date the process sets for our response, and how you would like to receive the response.

Requests must be written in English, or come with an English translation. We generally do not respond to requests made by telephone, by social media, or through the in-product support channels, except to point the caller to this process.

10. Delivery of legal process

For convenience, we accept a copy of legal process by email at contact@wrxstack.com. Our receipt of process by email, and our response to it, is not a waiver of any requirement of law, including requirements as to proper service, jurisdiction, venue, the form or sufficiency of process, or the time allowed to respond. It is not consent to the jurisdiction of any court or other body, and it does not waive any objection, right, privilege, or protection available to wrxstack or to any user. We reserve all of them.

Where the law requires formal service by a particular method, a Requesting Authority must complete service by that method. Email to the address above is not a substitute.

11. How we verify a request

False requests that pretend to come from the police or a court are a known way to obtain personal data unlawfully. We take reasonable steps to check a request before acting on it.

• We may confirm the request with the issuing agency or court, using contact details we find independently, such as a publicly listed telephone number.
• We generally do not act on requests sent from personal or free email accounts, or from email addresses that do not belong to the agency named in the request.
• We may decline to act on a request that we cannot verify, and we may report an apparently fraudulent request to the agency it claims to come from.

12. How we review and narrow requests

We aim to review each request to check that it is valid, that it was issued by a body with authority over us and over the information sought, that it uses the right form of process for that information, and that it is specific to identified accounts and a defined time period.

• Overbroad requests. If a request seeks more than is needed for its stated purpose, covers more accounts or a longer period than it justifies, or is unclear, we may ask the Requesting Authority to narrow or clarify it before we respond.
• Unlawful requests. If we believe a request is unlawful, we may decline it and, where we consider it appropriate, explain why. Where appropriate, we may object to it formally or ask a court to set it aside or modify it.
• Partial responses. If part of a request is valid and part is not, we may respond to the valid part only, and we may say what we have left out.
• No information. If we find no information for the identifiers given, we may say so, where the law permits.

We aim to respond within a reasonable time and, where valid process sets a deadline, to meet it. Where we need more time to review a request properly, we aim to tell the Requesting Authority.

13. Notice to users

Where the law permits, we aim to notify the affected user, and where the data belongs to an organization's workspace the affected Customer, before we disclose their information to a Requesting Authority. Where we give notice, we normally send it to the email address on the account, and may include a copy of the request or a description of it, so that the user or Customer has a reasonable opportunity to seek legal advice or to object before we respond.

We may decide not to give advance notice, for example where:

• a statute or a court order prohibits notice, such as an order under 18 U.S.C. section 2705(b);
• we believe in good faith that the request is an emergency under section 7 and that advance notice would increase the risk of death or serious physical injury;
• notice would put a child at risk, or the request relates to child sexual exploitation;
• notice would be futile, for example where the account has been compromised and the notice would reach the person who took it over rather than the account holder; or
• we reasonably consider advance notice inappropriate in the circumstances, for example because it could put a person at risk or help someone evade the law.

When the reason for delaying notice ends, for example when a secrecy order expires or an emergency has passed, we may notify the user or Customer, where the law permits and we consider it appropriate, and we do so where the DPA requires. We may ask the Requesting Authority to confirm when a prohibition has ended. A Requesting Authority that believes notice would be harmful should obtain a court order prohibiting it. A request to us not to give notice, without such an order, does not by itself prevent notice.

14. What information may exist

We aim to collect only the information needed to run the Service, and to keep it only as long as we need it, as described in our Data Retention Policy, section 9 of our Privacy Policy, and our Data Deletion Policy. What we hold about a given account depends on how the account was used. It may include:

Information that has been deleted from the live Service may persist for a limited time in the hosting provider's encrypted backups, until the provider's ordinary backup rotation overwrites it. Backups are not edited record by record, and we generally do not restore an individual account from backup to answer a request, unless the law or a court order requires it and it is technically possible. Encryption at rest is provided by our hosting provider. It is designed to protect stored data from unauthorized physical access. It does not prevent us from producing information when we are legally compelled to.

15. Information we do not hold

• Sign-in providers. Google, Apple, Microsoft, LinkedIn, GitHub, GitLab, Meta (Facebook), X, and Discord are independent companies. Records they hold about a user must be requested from them.
• Model providers chosen by the user. Where a user connects their own AI model provider account, that provider's records of the user's requests are held by that provider under its own terms.
• Payment processors. Full payment card details and other payment records held by a payment processor must be requested from the processor.
• Analytics data. Website analytics load only with consent and are linked to a random browser identifier, not to a name or email address. We generally cannot find analytics data from an account identifier.
• Information we do not collect. We do not collect location history or contact lists, and we do not collect device information beyond what an ordinary web request and, with consent, our website analytics contain.

16. Authenticating records and testimony

Where it is reasonably required, we may be able to provide a written declaration from the operator of wrxstack that records we produce are true copies kept in the ordinary course of business, for example a certification under Federal Rules of Evidence 902(11) or a comparable rule. We provide live testimony, in person or by remote means, only when legally compelled to do so, and we ask that a declaration be accepted in its place wherever the rules allow.

17. Secrecy orders and national security process

Some legal process comes with a court order or statutory duty that prohibits us from telling the user, or anyone else, that we received it. We comply with any such prohibition that is lawful and properly issued. Where we believe a secrecy order is broader or longer than the law allows, we may ask the issuing body or a court to narrow it or to end it. Where the law prohibits us from saying whether we have received a particular kind of request, nothing in these Guidelines and nothing on this site should be read as a statement on that point.

18. Reports we make on our own initiative

• Child sexual exploitation. Where we become aware of apparent child sexual abuse material on the Service, we report it to the National Center for Missing and Exploited Children and preserve the related records, as 18 U.S.C. section 2258A requires.
• Emergencies. Where we believe in good faith that an emergency involving danger of death or serious physical injury requires it, we may contact the relevant authorities and disclose limited information, as described in section 7.
• Protecting the Service. We may report fraud, attacks on the Service, or other unlawful conduct directed at wrxstack or its users to the relevant authorities. We limit any information we share to what is needed for that report.

19. No fees and no compensation

We do not charge a Requesting Authority any fee for responding to a request, and we do not seek reimbursement of our costs, including any reimbursement that 18 U.S.C. section 2706 or a similar law might otherwise allow. No payment, reimbursement, reward, or compensation of any kind is offered, owed, or created by these Guidelines, by a request, or by our response to one, for any Requesting Authority, user, Customer, or other person, or for wrxstack.

20. Transparency

We do not currently publish a transparency report. We may publish one in the future, stating the number and kinds of government requests we receive and how we responded, to the extent the law allows. If we do, we may link to it from this page.

21. Questions from users

If you are a user and want to know whether we have received a request about your account, email contact@wrxstack.com. We aim to answer as far as the law allows. If you have received notice from us about a request, we recommend that you seek independent legal advice promptly. We cannot give you legal advice, and we cannot represent you.

22. Relationship to other documents

These Guidelines supplement our Privacy Policy, Terms of Service, Acceptable Use Policy, and Data Processing Addendum. Where we process data for a Customer, the Data Processing Addendum controls if it conflicts with these Guidelines. These Guidelines do not create any contract with, or any enforceable right for, a Requesting Authority or any other third party, and they do not change any right or obligation under the Terms of Service.

23. Changes to these Guidelines

We may update these Guidelines to reflect changes in the law, in the Service, or in how we handle requests. We will give notice where the law or the Terms require it, and the effective date at the top shows the current version.

24. Legal effect of this Policy

This Policy explains our practices. It is not a contract, and it does not create any contractual obligation, warranty, guarantee, or right for you or for any other person. The only agreements between you and wrxstack are the Terms of Service and, where it applies, the Data Processing Addendum.

Timelines and targets in this Policy are goals we aim to meet, not guarantees, except where a law that applies to us sets a deadline, in which case we follow that law. Nothing in this Policy increases wrxstack's liability. The disclaimers, the limitation of liability, and the other protections in the Terms of Service apply to everything this Policy describes. Nothing in this Policy limits a right you have under a law that cannot be limited by agreement.

25. Contact

Requesting Authorities should send requests and legal process to contact@wrxstack.com, following section 9. Users with questions about these Guidelines can reach us at the same address. Related documents: Privacy Policy, GDPR Statement, California Notice, Data Deletion Policy, Sub-processor List, and Data handling.