Law Enforcement Guidelines

Last updated: 13.02.2026 · Version: 1.0

This guide explains how legal data requests submitted by law enforcement and other competent public authorities (courts, Offices of the Chief Public Prosecutor, regulatory/administrative authorities, etc.) are received, verified, assessed, and answered in connection with services operated by WIN (“Platform”).

This guide is a standard that aims both:

• to enable public authorities to submit requests through the correct channel and with the correct content, and
• for WIN to handle requests in a manner that is lawful, proportionate, secure, and recorded.

Related documents

This guide should be read together with the following WIN documents:

Section 1: Purpose, scope, and legal basis

1.1 Purpose

The main purposes of this guide are:

• To ensure requests from public authorities are received in a procedurally proper manner,
• To assess requests under the principles of lawfulness, necessity and proportionality, and data minimization,
• To ensure responses are produced and transmitted in a secure manner,
• To record processes and, where appropriate, generate input for transparency reporting,
• To prevent fraudulent/misleading requests, unauthorized disclosure, and abuse.

1.2 Scope (which requests / which authorities)

This guide covers the following types of requests (including but not limited to):

• Information/document requests: Account/subscription information, traffic data/logs, content data, etc.
• Data preservation (preservation / legal hold) requests: Preventing deletion or ensuring preservation of data with respect to a specific account or content.
• Emergency requests: Limited data sharing in situations involving risk to life or imminent/irreparable harm.
• Content/account measures: Allegations of illegal content, access blocking/removal, account freezing, etc. (different regimes may apply depending on geographic targeting).

This guide is addressed to requests from the following authorities and competent institutions:

• Courts and other judicial bodies,
• Offices of the Chief Public Prosecutor and judicial authorities,
• Law enforcement (including police/gendarmerie and specialist units),
• Regulatory/administrative authorities, to the extent applicable (e.g., digital services/communications/competition authorities in certain countries).

1.3 Geographic context and applicable regimes (summary)

The countries/regions where WIN provides services and the data hosting architecture may affect the procedures and legal bases applicable to requests.

1.4 Legal basis (general reference)

WIN’s approach to law enforcement requests is structured taking into account in particular the following rules:

• Law No. 6698 on the Protection of Personal Data (KVKK).
• Communique on the Procedures and Principles to be Complied with in Fulfilling the Disclosure Obligation (content/format of disclosure; linked to notice/transparency approach).
• Regulation on the Transfer of Personal Data Abroad (cross-border data transfer framework; linked in particular to hosting/supplier architecture).
• Law No. 5651 (publications on the internet; hosting provider liability and traffic data/log obligations).
• Turkish Penal Code No. 5237 (TCK) — in particular:
  • Art. 226 (Obscenity),
  • Art. 132–140 (Offenses against private life/communications; unlawful recording, capture, or disclosure of personal data).
• Electronic Communications Law No. 5809 (to the extent relevant to assessments linked to communications infrastructure and security).
• GDPR (in the context of EU users and cross-border data transfer).
• Digital Services Act (DSA) (where services are provided in the EU; communication with authorities and order/notice processes).

Note: This list is illustrative; additional legislation or different procedures may apply depending on the countries where WIN operates.

Section 2: Definitions

Section 3: Core principles in assessing requests

3.1 Lawfulness and procedural compliance

WIN shares data only within requests/decisions that:

• are transmitted by a competent authority,
• are communicated in a procedurally proper manner,
• have a clear legal basis.

3.2 Necessity and proportionality (scope control)

Requests are assessed with respect to scope, duration, and data categories in connection with the purpose. For overly broad or vague requests:

• narrowing of scope is requested,
• linkage to a specific account/incident is required,
• the request may be rejected or only partially fulfilled if necessary.

3.3 Data minimization and segregation

WIN adopts the principle of achieving the purpose with the least data. To the extent applicable:

• data belonging to third parties is filtered out,
• unnecessary fields are masked,
• output is produced limited only to the relevant time range/incident only.

3.4 Security, privacy, and integrity

Requests and responses are:

• handled/transmitted by authorized teams,
• under the principle of access only as needed,
• using secure communication methods.

3.5 Transparency and user notification

As a rule, WIN adopts a notification approach regarding requests affecting users. However, notification may be delayed or not provided if:

• it is prohibited by law,
• there is a risk of compromising an investigation,
• there is a risk to a person’s safety
  (see Section 9).

3.6 Record-keeping and accountability

WIN:

• records requests and responses in internal systems,
• leaves an audit trail where necessary for audit/review,
• uses them statistically in transparency reporting to the extent appropriate (see Transparency Reports).

Section 4: Request channels and authentication

4.1 Official communication channels

Note: For EU authorities, the DSA Art. 11 contact point, if published, should be followed via the DSA Compliance Page.

4.2 Request format and accepted documents

Requests are expected to meet the following characteristics:

• Be written and official in nature (wet ink / secure electronic signature / via official systems),
• Clearly show the identity and authority of the requesting authority/personnel,
• Include file/document number, date, and legal basis,
• Have a defined scope (account/incident, data categories, time range).

WIN does not process “oral” requests made by telephone only or applications whose official identity cannot be verified.

4.3 Identity and authority verification (checks performed by WIN)

When assessing requests, WIN may perform the following checks (to the extent applicable):

• Verification of the requesting person’s institutional email domain / official contact information,
• Verification of signature/stamp/e-signature,
• Confirmation via callback through the institution’s official channels,
• Review of the request content for procedure and scope.

4.4 Response times (target approach)

Response times may vary depending on the scope of the request, technical availability, and completeness of the request. General target approach:

• Complete standard requests: The goal is to complete the initial assessment and begin a response within 5 business days.
• Preservation requests: Processed as soon as possible after verification.
• Emergency requests: Answered on a priority basis if verification and urgency criteria are met.

Note: Requesting additional information for incomplete/vague requests may extend response times.

Section 5: Minimum information required in a request

5.1 Minimum fields (checklist)

5.2 Account/content identifiers (examples)

For requests to be handled quickly and correctly, at least one of the following should be provided where possible:

• In-app user ID / account number: 12345678 (Example)
• Registered phone number or email of the user
• Profile username (handle) or in-app link/screenshot of the profile
• Content ID / message ID / report ID for the relevant content

5.3 Request template (suggestion)

Section 6: WIN’s end-to-end request assessment and response process

Section 7: Request types and response scope

7.1 Standard information requests (account/data/transaction records)

WIN may share data available in its systems within procedurally proper and legally valid requests. Example data types:

• Account information: registration date, verification status, profile/settings information, Device ID and session (login/last seen) records,
• Content data: profile images/texts, report attachments; message content stored on Google Firebase (messages are not end-to-end encrypted),
• Technical data: login/logout times, IP/session information, error/activity logs obtained via automated infrastructure services such as Firebase,
• Purchase/subscription: App Store / Google Play transaction records and subscription status information.

Note: WIN can provide only data that exists in its own systems (server-side login/last seen, etc.) and is technically accessible.

7.2 Traffic data / log requests (Law No. 5651 context)

WIN handles traffic data/log records generated during provision of the service within the obligations foreseen under Law No. 5651 and related secondary legislation.

7.3 Preservation (preservation / legal hold) requests

Where WIN receives a procedurally proper “preservation” request:

• it may apply temporary preservation to prevent deletion of data with respect to the relevant account/content,
• during this preservation, it may separate the data from the normal retention flow.

• Preservation period: The standard preservation period is applied as a minimum of 90 days. Extension requests must be submitted in official writing before the period ends.

7.4 Emergency requests (risk to life / imminent harm)

Exceptionally, where permitted by law and after necessary verification, WIN may share limited data to protect a person’s safety or reduce imminent life-threatening risk.

7.5 Content removal / access blocking / account measures

In situations involving illegal content or security risks:

• WIN may apply content/account restrictions under its own contractual rules (see Community Guidelines and Terms of Use),
• depending on geographic targeting, orders of competent authorities (e.g., orders under the DSA in the EU) are assessed separately.

Public authorities may use the form on the Illegal Content Notice Form page to submit illegal content notices in a standard and traceable manner; the form contains fields aligned with Law No. 5651, the TCK, and the DSA.

Section 8: Categories of data that may be shared (sample inventory)

Section 9: User notification and transparency

9.1 User notification and responsibility

Notifying the user in the context of government/law enforcement requests is not WIN’s responsibility or obligation. Prosecutor’s office and law enforcement investigations are confidential as a rule. Therefore, there is no obligation to notify users regarding data sharing carried out pursuant to procedurally proper requests.

9.2 Situations where notification is not made or is delayed

WIN may not notify or may delay notification in the following situations:

• Where there is a legal confidentiality obligation or notification prohibition,
• Where notification could compromise an investigation,
• Where it would create a risk to a person’s safety.

9.3 Transparency reports

WIN aims to publish statistics regarding public authority requests and content actions periodically to the extent appropriate. See Transparency Reports.

Section 10: International requests and cross-border data

10.1 Requests from foreign authorities

When assessing requests from foreign authorities outside Turkiye, WIN considers whether the request has been transmitted in a procedurally proper manner through the Republic Prosecutor’s Office of the relevant country or an equivalent official/judicial institution. Such applications are responded to only through authorized official channels.

10.2 Orders under the EU (DSA)

Where services are provided in the EU, for orders of EU authorities and contact points, see the DSA Compliance Page.

10.3 Cross-border data transfer and hosting

In WIN’s technical infrastructure, which countries host data and which suppliers are used may affect transfer and response processes. In Turkiye, the KVKK and Regulation on the Transfer of Personal Data Abroad framework is also considered for cross-border transfer scenarios. For the general approach on these matters, see the Privacy Policy.

Section 11: Security, record-keeping, and audit

11.1 Access and authorization

Law enforcement requests are processed only under the control of legal/compliance and security teams authorized on this topic. Accesses are recorded.

11.2 Secure transmission

While the transmission method for responses has not yet been finalized as a single technical standard, transmission is principally carried out by taking necessary security measures via encrypted files, secure links, or notification systems.

11.3 Retention of records (request records)

Request records and response metadata (e.g., date, scope, delivery method) are retained for the period appropriate under relevant retention policies for accountability and audit purposes.

Section 12: Changes and contact

WIN may update this guide due to legislative changes, technical architecture changes, or operational needs. The current version is published in the in-app “Legal” section and at whoisnextapp.com (opens in a new tab).

Public authorities should submit their requests through the official channels stated in Section 4.