Ackaia Corporation Legal Request Response Policy#

Ackaia Corporation v1.00.00 June 01, 2026 1233 York Avenue, Apt. 301 New York, NY 10065 United States of America www.ackaia.com

Effective Date: June 01, 2026

Publisher: Ackaia Corporation, 1233 York Avenue, New York, NY 10065, United States

(“Ackaia”, “Ackaia Corp.”, “we”, “our”, “us”)

Applies To: Ackaia CipherDrive™, Ackaia ID, Ackaia Cloud Services, Ackaia IAM and policy-engine services, Ackaia websites, public repositories, APIs, and related services, unless a separate legal-request policy applies.

Document Owner: Ackaia Corp Legal / Trust & Safety / Security

Primary Legal Contact: legal@ackaia.com

---

Revision History#

Version	Changes	Date
1.00.00	Initial Publication	06/01/2026

---

1. Purpose#

Ackaia builds privacy-first infrastructure. Our services are designed to protect user privacy, minimize unnecessary access to user information, and preserve strong technical boundaries between Ackaia-operated systems and user-controlled encrypted content.

This Legal Request Response Policy explains how Ackaia evaluates, processes, challenges, narrows, or complies with subpoenas, court orders, warrants, content-removal orders, preservation requests, law-enforcement requests, regulatory demands, and similar legal process involving Ackaia services.

This Policy is intended to make clear:

what categories of user account information Ackaia may have;

what information Ackaia does not have because of technical, cryptographic, or architectural limitations;

how Ackaia handles requests for CipherDrive™ files and file metadata;

how Ackaia responds to valid legal orders requiring removal or restriction of content;

when Ackaia may notify affected users;

when Ackaia may conduct internal forensic, trust, safety, or legal review before responding;

when Ackaia may challenge, reject, or publicly oppose requests that appear to target lawful expression, privacy, or basic human rights.

This Policy is provided for operational and informational purposes. It does not constitute legal advice, does not waive any legal rights or objections, and does not create enforceable rights for any third party.

---

2. Scope#

This Policy applies to legal requests involving Ackaia-owned or Ackaia-operated services, including:

Ackaia CipherDrive™;

Ackaia ID;

Ackaia Cloud Services;

Ackaia IAM and policy-engine systems;

Ackaia-operated APIs;

Ackaia public websites and dashboards;

Ackaia public or source-available repositories;

account, billing, subscription, public-sharing, and security-control systems;

metadata, logs, risk signals, and legal compliance records associated with Ackaia services.

Ackaia may publish more specific procedures for particular products, jurisdictions, abuse categories, or legal frameworks. If a more specific policy applies, that policy controls for the relevant subject matter.

This Policy does not apply to third-party services, infrastructure, payment processors, identity-verification providers, network carriers, hosting providers, or external platforms not controlled by Ackaia, even if Ackaia uses or links to them.

---

3. Relationship to Other CipherDrive™ Policies#

This Policy should be read together with Ackaia’s other CipherDrive™ trust, safety, and legal documents, including:

Ackaia CipherDrive™ Copyright Policy and Takedown Procedure;

Ackaia CipherDrive™ Acceptable Use & Abuse Policy.

The Copyright Policy describes Ackaia’s process for copyright notices, takedown requests, counter-notices, and repeat-infringer handling. The Acceptable Use & Abuse Policy describes prohibited use of CipherDrive™, including CSAM, malware, phishing, intellectual-property infringement, harassment, stolen data, public-link abuse, and attempts to evade safety systems.

Nothing in this Policy permits users to use privacy, encryption, or zero-knowledge architecture to violate Ackaia policy, applicable law, the rights of others, or child-safety obligations.

---

4. Definitions#

For purposes of this Policy:

“Legal Request” means a subpoena, summons, warrant, court order, judicial order, regulatory demand, law-enforcement request, preservation request, disclosure request, takedown order, administrative request, or similar formal process seeking information, action, preservation, removal, restriction, or cooperation from Ackaia.

“Account Data” means basic information associated with a user account or subscription that Ackaia may store in the ordinary course of operating its services.

“CipherDrive™ Content” means files, folders, objects, archives, shared objects, or other user-controlled data stored or transferred through CipherDrive™.

“Encrypted Blob” means encrypted object data stored by Ackaia that Ackaia cannot decrypt without user-controlled cryptographic material.

“Metadata” means technical and operational information about a file, account, object, event, or transaction, such as file size, file type, timestamps, download events, sharing events, region-placement records, account identifiers, IP-derived records, or other non-content signals.

“Risk Assessment Engine” means Ackaia’s automated safety, abuse-prevention, malware, CSAM, policy, and risk-signal infrastructure that may evaluate technical indicators associated with uploads, sharing, accounts, links, or activity.

“CSAM” means child sexual abuse material.

---

5. Core Principles#

Ackaia applies the following principles when handling Legal Requests:

Legality. Ackaia reviews whether the request appears valid, properly issued, specific, and legally enforceable.

Data minimization. Ackaia seeks to disclose only information that is legally required, technically available, and reasonably responsive to the request.

Privacy by design. Ackaia does not bypass its own privacy architecture merely because a request asks for information that Ackaia does not possess.

No compelled impossibility. Ackaia cannot produce plaintext files, cryptographic keys, master keys, file keys, or other cryptographic material that Ackaia does not store or control.

Specificity. Ackaia may require requesters to identify the account, object, link, time period, legal authority, and requested category of information with reasonable precision.

Security. Ackaia may verify the authenticity of a request and the identity, authority, and jurisdiction of the requester before responding.

Human rights and free expression. Ackaia may reject, challenge, narrow, or publicly oppose requests that appear to be abusive, overbroad, retaliatory, politically motivated, censorial, or intended to suppress lawful expression.

Child safety and severe abuse response. Ackaia may prioritize requests involving CSAM, child exploitation, credible threats of violence, malware, emergency safety issues, or other severe abuse, subject to applicable law and technical limits.

---

6. Categories of Legal Requests#

Ackaia may receive Legal Requests including, without limitation:

subpoenas for basic subscriber or account information;

court orders requesting account records, object metadata, logs, or preservation;

warrants or equivalent judicial process seeking information within Ackaia’s possession or control;

emergency disclosure or safety requests;

preservation requests;

abuse, CSAM, malware, fraud, or safety-related legal requests;

requests to remove, disable, restrict, block, or de-index content;

requests to provide files, file contents, file metadata, or access history;

requests to identify users associated with shared links or public objects;

requests to assist with moderation, enforcement, or legal compliance.

Ackaia evaluates each request based on applicable law, jurisdiction, the requesting authority, the requested data category, user privacy, product architecture, safety impact, and the technical information available to Ackaia.

---

7. Required Information for Legal Requests#

To help Ackaia evaluate a Legal Request, requesters should provide:

the requesting agency, court, party, or legal representative;

the legal authority under which the request is issued;

the issuing jurisdiction;

the specific Ackaia service involved;

the relevant account email, account ID, user identifier, public link, object ID, URL, IP address, transaction ID, or other precise identifier;

the specific category of information requested;

the relevant date range;

whether the request seeks disclosure, preservation, removal, restriction, or other action;

any non-disclosure, sealing, gag, or confidentiality requirement;

contact information for follow-up.

Ackaia may reject, delay, or request clarification for Legal Requests that are incomplete, invalid, unsigned, overbroad, vague, informal, improperly served, inconsistent with applicable law, or technically impossible to satisfy.

---

8. Verification and Intake Review#

Before responding to a Legal Request, Ackaia may:

verify the authenticity of the request;

verify the identity and authority of the requester;

review whether the request is facially valid;

confirm whether the request was served through an accepted legal channel;

assess whether the request seeks information within Ackaia’s possession, custody, or control;

evaluate whether the request is overbroad or insufficiently specific;

determine whether the request conflicts with user privacy, applicable law, human rights, or Ackaia policy;

seek narrowing, clarification, amendment, withdrawal, or judicial review where appropriate.

Ackaia reserves all available rights and objections, including objections based on jurisdiction, scope, burden, privilege, user privacy, freedom of expression, conflicts of law, technical impossibility, and legal insufficiency.

---

9. Account Data Ackaia May Have#

Depending on the service used, account configuration, subscription status, billing status, security context, and operational history, Ackaia may have access to some of the following Account Data:

email address;

name;

mailing or billing address, in some cases only where the user has a paid service;

government-document number supplied by the user, such as:

i) CPF for Brazilian users;

ii) SSN for United States users;

iii) NIF for Portuguese users;

IPv4 address associated with the account or activity, which may not be the user’s most recent IPv4 address;

approximate geolocation derived from the most recent IPv4 address, in specific security contexts related to the IAM policy engine;

account identifiers, subscription indicators, billing-state indicators, security events, policy-engine events, or other operational records where applicable.

Ackaia does not represent that all of this data exists for every account. Ackaia may not collect, retain, or be able to retrieve every listed category for every user or time period.

9.1 Address Data#

Ackaia may store address information for users who maintain or maintained paid services. Ackaia does not necessarily validate that a user-provided address is accurate, current, complete, or associated with the user.

9.2 Government-Document Numbers#

Ackaia may collect document numbers for certain jurisdictions, including CPF, SSN, or NIF, depending on product, billing, compliance, account, or regional requirements.

Ackaia validates these numbers only mathematically or structurally where applicable. Ackaia does not validate these numbers with any government agency, tax authority, social-security authority, identity registry, or governmental database in Brazil, the United States, Portugal, or any other country unless a separate written policy states otherwise.

Accordingly, Ackaia may be able to state that a number was supplied and passed a mathematical or structural validation check, but Ackaia generally cannot certify that the number belongs to the user or that it was confirmed by a governmental authority.

9.3 IPv4 and Approximate Geolocation Data#

Ackaia may store IPv4 information associated with account activity, security events, login events, policy-engine evaluation, or other operational contexts. The IPv4 address available to Ackaia may not be the most recent address used by the user.

In specific security contexts involving the IAM policy engine, Ackaia may also collect approximate geolocation information derived from the most recent IPv4 address available to that system. This geolocation is approximate, IP-derived, and may not reflect the user’s precise physical location.

---

10. CipherDrive™ Zero-Knowledge Architecture#

CipherDrive™ is designed around a privacy-first, zero-knowledge architecture for supported file-storage features.

In ordinary operation:

user files are encrypted before leaving the user’s device;

user files are decrypted only when the user retrieves and decrypts them through user-controlled cryptographic material;

Ackaia stores encrypted blobs rather than plaintext file contents;

Ackaia may be able to see that a user has a vault or stored objects, but the object payloads appear to Ackaia as encrypted blobs;

Ackaia does not store user master keys;

Ackaia does not store file keys;

Ackaia does not store the cryptographic material required to decrypt user files;

Ackaia employees do not have ordinary access to plaintext CipherDrive™ file contents;

Ackaia cannot open, inspect, read, export, or produce plaintext file contents that Ackaia does not possess or control.

A Legal Request asking Ackaia to produce plaintext CipherDrive™ files, master keys, file keys, private cryptographic material, or decrypted content may therefore be technically impossible for Ackaia to satisfy.

Ackaia may explain these technical limitations to the requester and, where legally required and technically available, provide responsive metadata or account information instead.

---

11. CipherDrive™ Information Ackaia May Be Able to Provide#

For CipherDrive™ objects, Ackaia may be able to provide certain metadata, subject to legal validity, scope, retention, technical availability, and product configuration.

Potentially available metadata may include:

file size or object weight;

file type or declared object type;

upload dates or timestamps;

download dates or timestamps;

sharing dates or timestamps;

public-link or controlled-sharing status;

regions where the encrypted object is replicated across Ackaia’s global infrastructure;

account or object identifiers;

technical risk, safety, or moderation signals where available and legally disclosable;

records showing whether access to a public link, object, or sharing feature was restricted, disabled, or removed.

Ackaia does not guarantee that all metadata exists for every file, account, object, event, or time period. Retention periods, product design, privacy settings, legal holds, operational events, and system changes may affect availability.

---

12. Shared Files and Risk Assessment Engine Signals#

CipherDrive™ may provide sharing mechanisms, including public links, controlled links, shared objects, or other platform-mediated distribution features.

When a file is shared using CipherDrive™ sharing mechanisms, automated systems such as the Risk Assessment Engine may operate to generate or evaluate technical signals related to the file, link, object, account, or sharing event.

Depending on the context, product configuration, and technical availability, these signals may include:

mathematical hashes;

perceptual hashes;

file fingerprints;

malware-detection indicators;

CSAM-related indicators;

known-content match indicators;

public-link risk indicators;

account, session, IP, timestamp, object, or event identifiers associated with a risk event;

moderation or enforcement indicators.

The Risk Assessment Engine may compare technical signals against public, trusted, reputable, or otherwise authorized databases for malware, CSAM, abuse, or severe-risk detection.

The Risk Assessment Engine does not give Ackaia employees general access to plaintext user files. Ackaia employees do not open, read, view, browse, or manually inspect CipherDrive™ file contents merely because the Risk Assessment Engine generated technical signals. The file remains protected by CipherDrive™ architecture, and Ackaia’s review is limited to technical signals, metadata, policy indicators, legal records, moderation actions, and other information available without defeating zero-knowledge protections.

---

13. Requests for CipherDrive™ File Contents#

If Ackaia receives a Legal Request for CipherDrive™ file contents, Ackaia will determine whether the requested information is technically available.

Ackaia generally cannot provide:

plaintext user files;

decrypted CipherDrive™ contents;

user master keys;

file encryption keys;

key-wrapping material;

passwords or secret recovery material not stored by Ackaia;

tools or assistance to bypass CipherDrive™ encryption;

backdoors, exceptional-access mechanisms, or new decryption capabilities that do not already exist in the product.

Ackaia may provide, where legally required and technically available:

account data;

object metadata;

sharing metadata;

upload, download, or sharing timestamps;

region-replication metadata;

public-link status information;

technical risk signals;

moderation or enforcement records;

records showing whether the file was removed, restricted, disabled, or subject to policy action.

Ackaia will not falsely represent encrypted blobs as plaintext files. If only encrypted blobs are technically available, Ackaia may explain that limitation to the requester.

---

14. Preservation Requests#

Where legally valid and properly scoped, Ackaia may preserve information within its possession, custody, or control while a requester seeks appropriate legal process.

A preservation request does not require Ackaia to create new information, decrypt encrypted content, obtain user keys, bypass encryption, monitor future activity without legal authority, or preserve information that Ackaia does not possess or cannot technically access.

Preservation may include available account records, metadata, logs, public-link records, risk signals, moderation records, or encrypted blobs, subject to technical feasibility, retention constraints, applicable law, and Ackaia policy.

---

15. Internal Audit Before Full Compliance#

Ackaia reserves the right to conduct an internal audit before complying fully with a Legal Request.

During this review, Ackaia may activate its forensic computing, trust and safety, security, legal, compliance, infrastructure, or moderation teams to better understand the request, the account, the object, the alleged conduct, and the legal basis for disclosure or removal.

This internal audit may include review of:

automated technical signals;

Risk Assessment Engine indicators;

malware or CSAM-related technical indicators;

public-link activity;

account security events;

IAM policy-engine events;

IPv4-derived approximate location signals where available;

upload, download, sharing, or replication metadata;

prior abuse reports;

prior copyright reports;

prior moderation or enforcement actions;

human moderation interventions;

account integrity indicators;

available legal, safety, or operational context.

The purpose of the audit is to understand why Ackaia is being required to provide data, preserve information, remove content, restrict access, or cooperate with an authority. The audit also helps Ackaia determine whether the request is valid, overbroad, censorial, abusive, technically impossible, or inconsistent with Ackaia policy or applicable law.

---

16. Response to Information-Only Legal Requests#

For Legal Requests that seek only information, such as Account Data, metadata, file records, logs, or other records, Ackaia will provide only information that is:

within Ackaia’s possession, custody, or control;

technically available;

responsive to the request;

legally required to be produced;

not subject to a valid objection, privilege, legal restriction, or technical impossibility.

Ackaia may narrow, object to, or challenge requests that seek excessive information, unrelated accounts, broad date ranges, unrelated files, mass disclosure, decryption, plaintext content, cryptographic material, or information beyond the legitimate scope of the request.

Ackaia does not create data for the purpose of satisfying a Legal Request, except where legally required preservation or export processes apply to existing records.

---

17. User Notice#

Ackaia reserves the right to notify the affected user that Ackaia received a Legal Request concerning that user, the user’s account, the user’s content, the user’s metadata, or the user’s activity.

Ackaia may also notify the user that Ackaia complied with, partially complied with, objected to, challenged, or rejected the request.

Ackaia may delay or withhold user notice where:

Ackaia is legally prohibited from providing notice;

a valid non-disclosure order, sealing order, gag order, or equivalent legal restriction applies;

notice could create a risk of death, serious physical harm, child exploitation, evidence destruction, witness intimidation, victim retaliation, or obstruction of a lawful investigation;

the request involves suspected CSAM distribution, child exploitation, grooming, sextortion, or related severe child-safety matters;

the request involves severe crimes, terrorism, credible threats of violence, active malware operations, ransomware, or other serious abuse;

Ackaia determines that notice would materially compromise platform security or abuse-prevention systems;

applicable law requires delayed notice.

Where legally permissible and appropriate, Ackaia may provide delayed notice after the restriction expires, the risk has passed, or the investigation no longer requires confidentiality.

---

18. Content Removal and Regional Restriction Orders#

If Ackaia receives a valid Legal Request requiring removal, disabling, restriction, blocking, or limitation of content for a legally valid reason, Ackaia may comply within the jurisdiction, territory, legal region, infrastructure region, or user-access region where the applicable law or order applies.

Ackaia’s default approach for legally valid regional orders is regional compliance. For example, if a valid order is issued by a United States court under United States law and applies to United States territory or infrastructure, Ackaia may remove, restrict, disable, or block the reported file or public access only within United States regions, United States infrastructure, or United States user-access contexts, as applicable.

Unless a valid order is legally binding on Ackaia on a broader basis, Ackaia may leave the same encrypted object, public link, or shared object available through datacenters or infrastructure regions outside the issuing jurisdiction. In that case, the file may remain accessible through the platform, including through the same link, from regions outside the scope of the legal restriction.

Ackaia may take broader action if:

the order is legally binding on Ackaia beyond the issuing region;

the content violates Ackaia’s Acceptable Use & Abuse Policy;

the content violates Ackaia’s Copyright Policy and Takedown Procedure;

the content involves CSAM, child exploitation, malware, phishing, stolen data, threats, or severe abuse;

broader restriction is necessary to protect users, victims, children, infrastructure, or legal rights;

Ackaia determines that a global or multi-region action is legally required or operationally necessary.

Removal, disabling, restriction, blocking, or restoration of content is not an admission by Ackaia that the content is lawful, unlawful, infringing, non-infringing, abusive, non-abusive, or otherwise legally determined.

---

For copyright-related requests involving CipherDrive™, Ackaia may process the request under the Ackaia CipherDrive™ Copyright Policy and Takedown Procedure.

For abuse-related requests involving CipherDrive™, including malware, phishing, CSAM, child exploitation, threats, harassment, stolen data, public-link abuse, or other prohibited use, Ackaia may process the request under the Ackaia CipherDrive™ Acceptable Use & Abuse Policy.

Ackaia may act on public links, metadata, claimant evidence, technical signals, account activity, law-enforcement references, legal notices, or other available information even where Ackaia cannot decrypt the underlying encrypted file contents.

Ackaia may disable public sharing, restrict access, preserve records, remove region-specific access, suspend accounts, terminate accounts, report suspected illegal activity, or take other action permitted by policy and law.

---

20. Requests That Seek to Silence or Censor Lawful Expression#

Ackaia recognizes that privacy-preserving infrastructure may be used by journalists, activists, researchers, civil-society organizations, lawyers, whistleblowers, human-rights defenders, and ordinary users who rely on secure services to protect basic freedoms.

If, at any point, Ackaia determines with full confidence that a Legal Request has the sole and exclusive purpose of silencing, censoring, retaliating against, intimidating, exposing, or otherwise impairing the lawful freedom of expression of a user who uses Ackaia services to preserve basic human rights, Ackaia will categorically reject compliance to the maximum extent permitted by law.

In such cases, Ackaia may:

refuse voluntary compliance;

object to the request;

move to quash, challenge, appeal, or seek judicial review;

seek narrowing or modification of the order;

assert constitutional, statutory, human-rights, privacy, jurisdictional, or procedural objections;

notify the affected user where legally permissible;

support the user’s ability to seek independent legal counsel;

publish transparency information about the case on Ackaia websites, blogs, transparency reports, public repositories, or other public environments where legally permissible;

take any other lawful counteraction available to Ackaia.

Ackaia may withhold or delay public disclosure where publication would violate law, expose victims, compromise child safety, endanger individuals, reveal sensitive investigative techniques, disclose private information, or create security risk.

---

21. Overbroad, Abusive, Invalid, or Impossible Requests#

Ackaia may reject, challenge, narrow, or decline to comply with Legal Requests that are:

legally invalid;

improperly served;

outside the requester’s jurisdiction;

overbroad;

vague;

insufficiently specific;

unsupported by adequate legal authority;

seeking information Ackaia does not possess;

seeking plaintext CipherDrive™ file contents that Ackaia cannot decrypt;

seeking cryptographic keys or material that Ackaia does not store;

seeking creation of backdoors, exceptional access, or new surveillance capabilities;

designed to harass, intimidate, censor, or silence users;

inconsistent with human rights, due process, user privacy, or applicable law;

inconsistent with Ackaia’s technical architecture;

inconsistent with Ackaia’s legal obligations to users, victims, children, or third parties.

Ackaia may require a requester to obtain a more specific order, a higher form of legal process, or review by a court of competent jurisdiction before Ackaia takes action.

---

22. No Backdoors or Decryption Assistance#

Ackaia does not create, maintain, or deploy backdoors for CipherDrive™.

Ackaia will not redesign CipherDrive™, weaken encryption, generate new plaintext access, obtain user keys, store new cryptographic material, modify client software, silently alter cryptographic behavior, or create exceptional-access mechanisms solely to satisfy a Legal Request unless legally compelled by a binding order and after Ackaia has evaluated all available objections, challenges, and appeals.

Even where Ackaia receives a binding Legal Request, Ackaia may be technically unable to provide decrypted files or cryptographic material that Ackaia does not possess.

---

23. Confidentiality and Transparency#

Ackaia may treat Legal Requests, related communications, internal audits, and response materials as confidential where required or appropriate.

Ackaia may publish transparency information, including aggregate statistics, case studies, policy updates, legal-request summaries, or notable challenges, where legally permissible and consistent with user privacy, child safety, security, and applicable law.

Ackaia may also disclose that it challenged, rejected, narrowed, or complied with requests where disclosure is lawful and appropriate.

---

24. Data Accuracy and Limitations#

Information produced by Ackaia in response to a Legal Request may reflect records stored in Ackaia systems at a particular time. Such information may be incomplete, outdated, user-supplied, approximate, mathematically validated only, technically derived, or subject to retention limits.

Examples include:

a user-provided address may not be verified;

a document number may be mathematically valid but not government-confirmed;

an IPv4 address may not be the latest address used by the user;

IP-derived geolocation may be approximate;

file type may reflect declared, inferred, or metadata-based type rather than plaintext inspection;

timestamps may reflect system events and may require technical interpretation;

region-replication data may change over time;

encrypted blobs do not reveal plaintext content to Ackaia.

Ackaia may include explanatory limitations when producing records.

---

25. Emergency and Severe Harm Matters#

Ackaia may prioritize review of requests involving imminent risk of death, serious physical harm, CSAM, child exploitation, credible threats of violence, active malware, ransomware, account compromise, or other severe abuse.

Emergency handling does not eliminate Ackaia’s technical limitations. Ackaia still cannot provide information, plaintext content, or cryptographic material it does not possess.

Ackaia may preserve records, restrict public links, suspend accounts, disable sharing, report suspected illegal activity, or cooperate with lawful authorities where appropriate and legally permitted.

---

26. Contact#

Legal requests should be directed to:

Ackaia Corp Legal Contact: legal@ackaia.com

For abuse reports, use:

Abuse Contact: abuse@ackaia.com

For security vulnerability reports, use:

Security Contact: security@ackaia.com

For copyright complaints involving CipherDrive™, use the reporting process described in the Ackaia CipherDrive™ Copyright Policy and Takedown Procedure.

For CSAM or child-safety matters, do not send illegal material to Ackaia. Provide the minimum necessary information, such as URL, object identifier, account reference, timestamps, and context, without redistributing illegal content.

---

27. Changes to This Policy#

Ackaia may update this Policy from time to time to reflect changes in law, jurisdictional practice, product architecture, cryptographic design, service operations, trust and safety systems, abuse-prevention practices, legal-request procedures, transparency practices, or company policy.

When changes are material, Ackaia may provide notice through its website, repository, legal portal, transparency report, blog, or other appropriate channel.

The version in effect at the time Ackaia receives a Legal Request applies to Ackaia’s handling of that request unless Ackaia determines otherwise or applicable law requires a different result.

---

End of Policy