Websites today are not just a matter of “corporate visibility”: they are the most visible part of a professional presence and, in most business models, the business development channel itself. Indeed, in the digital age we live in, the website effectively serves as the “marketplace” and the “business centre” for many companies.
However, treating websites solely as a matter of design, content or sales falls short. A website is a space of interaction where the relationship with the user, member or customer begins, is directed and is often recorded. In that interaction, what we promise, how we inform, which approvals we obtain and how, and how we design our processes all bring specific responsibilities and, frequently, binding consequences. The real question at this point is this: while building a website to be “functional” and “attractive”, how far do we also take account of regulatory compliance and evidence?
The statements, prompts, checkboxes, forms and checkout flows on a website are, in practice, not mere communication elements. They become texts and processes that can, when needed, be read as “undertakings”. A website is therefore not just a shop window but also an area of legal responsibility that must be managed. Although there is a common compliance core for every website, in some sectors a website becomes not merely a communication tool but an arena in which the legislation is actually applied. The texts and user journeys used in these areas therefore produce far more direct and binding consequences.
In this article, we address the mistakes we encounter most often in practice and the points most frequently confused, under four headings:
KVKK (data protection) duty to inform, cookie management and explicit consent: mistakes made in practice
Distance selling: the points where the pre-contractual information, contract and right of withdrawal structure most often breaks down
“Copy-paste” texts and the risks they create in audits and disputes
Regulated/specialised areas: additional layers of obligations that must be designed separately according to the business model and sector, and that often carry direct binding force
Before we start, let us clarify a critical distinction: simply “having a document” on a website often does not provide protection on its own. What matters is presenting the right content in the right place, obtaining the right consent by the right method and designing the entire flow so that it can be proven when needed. We will therefore start with the core mistakes and move on to the “specialised area” layer at the end of the article.
1) The most common KVKK mistake: building the duty to inform and explicit consent on the same footing
The compliance problem we encounter most often in website practice is the merging of the duty to inform and the explicit consent mechanism into the same text and the same action. Yet the Communiqué on the Procedures and Principles to be Followed in Fulfilling the Duty to Inform dated 10 March 2018 clearly sets out both the minimum content and the application principles of the duty to inform under Article 10 of Law No. 6698 on the Protection of Personal Data (KVKK).
First, the correct distinction must be made clear:
The duty to inform is the mandatory obligation under which we transparently notify the data subject of “which data we process, for what purpose, on which legal basis and within what transfer structure”.
Explicit consent, by contrast, is not a general approval mechanism to be used in every case. It is used only where necessary and under the conditions laid down in the legislation.
Indeed, the Communiqué requires that, even where a processing activity is based on explicit consent, informing and obtaining explicit consent be carried out separately. When these two steps are reduced to a single checkbox in practice, the notice turns into a “general and vague” text and the validity conditions of consent are weakened.
We see a similar standards problem with the minimum content of the privacy notice. Under Article 4(1) of the Communiqué, the notice must contain at least: (a) the identity of the data controller (and of its representative, if any); (b) the purposes of processing; (c) the persons/categories to whom data may be transferred (recipient groups) and the purposes of transfer; (ç) the method of data collection and the legal basis; and (d) the rights under Article 11 of Law No. 6698. In this framework, we must give a specific and clear explanation, particularly under the headings of “purpose” and “legal basis”. Article 5(1)(g) of the Communiqué expressly provides that the privacy notice must not contain general and vague statements, and that open-ended language creating the impression of “other possible purposes in the future” must not be used. Article 5(1)(h) of the Communiqué provides that the term “legal basis” means clearly stating which of the processing conditions in Articles 5 and 6 of Law No. 6698 is relied upon. In practice, however, these areas are often dealt with in abstract terms, which weakens both transparency and the evidential position.
The other critical axis is procedure and evidence. Article 5 of the Communiqué accepts that the duty to inform may be fulfilled by different methods, such as orally, in writing or electronically, but it also clarifies the following principles:
The duty to inform does not depend on a request from the data subject. In designing processes, we must treat it as a “default” obligation.
The burden of proving that the duty to inform has been fulfilled lies with the data controller. For this reason, a “text in the footer” approach on its own does not provide adequate assurance in most scenarios. We need to place the notice appropriately at the touchpoints where data is actually collected.
Where the purpose of processing changes, a separate notice must be given for that purpose before the activity begins.
Where data is processed for different purposes in different units of the data controller, the notice must be designed separately for each unit/purpose.
Where there is an obligation to register with the Data Controllers' Registry (VERBIS), the information given in the notice must be consistent with the information disclosed to the Registry.
In the transfer structure, recipient groups and the purposes of transfer must be stated clearly.
In website practice, this means the following. We must present the privacy notice not merely as “a single page” but with the right content and the right positioning in every flow through which we collect data (membership/contact forms, quote requests, newsletter sign-ups, payment steps, support requests, etc.). In addition, where we do not obtain personal data directly from the data subject, Article 6 of the Communiqué requires the notice to be given within a reasonable time, at the time of first contact or at the time of first transfer. This increases the risk of a “we will add it later” approach.
As a result, when we treat KVKK compliance at the level of “adding a text”, two main risks arise:
(i) the privacy notice does not meet the standard of clarity and specificity required by the Communiqué;
(ii) explicit consent is unnecessarily extended and merged into a single action, and so becomes open to challenges as to its validity.
Our goal should be to design the privacy notice so that it is clear, understandable and provable along the axis of purpose, legal basis, transfer and recipient group. Explicit consent, where required, should be designed separately, as a distinct action.
2) A common cookie management mistake: “There is a notice”, but consent management and legal basis analysis are missing
Cookies are often treated as a technical detail on websites. In reality, however, they trigger two separate “compliance areas” at the same time: (i) the processing of personal data through cookies, and (ii) carrying out that processing on the right legal basis + with the right notice + (where required) valid explicit consent.
The strongest aspect of the Personal Data Protection Authority's (KVKK) Cookie Guidelines (Çerez Rehberi) of July 2025 is that they move cookie compliance beyond “placing a banner” and tie it first and foremost to the requirement of an inventory and assessment. In practice, however, designs are often produced without answering the questions “which cookie, what purpose, which party, what duration, what data”. Nor is it made clear whether to proceed on explicit consent or on processing conditions other than explicit consent. This approach reduces cookie compliance to a technical interface problem and may weaken the legal basis and evidential dimensions.
2.1. Stretching the “necessary cookie” label: the Criterion A / Criterion B distinction is not applied correctly
The Guidelines discuss scenarios that do not require explicit consent by reference to two main criteria:
Criterion A (enabling communication): assessed within a narrower and specific technical purpose (e.g. by reference to scenarios such as load balancing).
Criterion B (strictly necessary for the service): cookies that are essential for performing a function expressly requested by the user (e.g. basket, session, authentication, certain security cookies, and the cookie that remembers the preference set in the consent management platform).
A common problem in practice is that a broad set of cookies is automatically placed in the “necessary” category on the grounds of “keeping the site running/measuring performance”. Under the logic of the Guidelines, however, the decisive factor is a concrete demonstration that the cookie is genuinely strictly necessary for the service expressly requested by the user. Where this line is not clearly drawn, the necessary/non-necessary distinction may become legally contestable.
2.2. Structural flaws in explicit consent design: the opt-out reflex, steering interfaces and the “anyone who enters the site is deemed to have accepted” approach
The standard set by the Guidelines is clear. Where explicit consent is required for cookies, consent must be opt-in; that is, the user must express their choice through an active, affirmative act. Despite this, approaches such as “if you continue to use the site, you are deemed to have accepted” can still be seen in practice. This model effectively makes consent a “default” and may leave it on weak ground as regards the elements of consent.
Similarly, it remains common to see the “accept” option highlighted in the first layer while the “reject” option is made less visible or is moved to the “preferences” area. Such designs may cast doubt on the claim that consent was given freely.
Cookie walls are also a risky area. The Guidelines emphasise that cookie walls may in some cases vitiate free will and that each case must be assessed separately. Therefore, structures that make access conditional on consent should not be treated as “automatically correct”. Instead, they should be structured with regard to the nature of the service, the alternatives offered and the principle of proportionality.
2.3. The duty to inform and the consent mechanism are blurred: a “privacy statement” is used as a substitute for consent
The Guidelines require that, for cookies too, the duty to inform be fulfilled in line with Article 10 of Law No. 6698 and the standard of the 2018 Communiqué on the Duty to Inform. They also require informing and obtaining consent to be kept separate where explicit consent is required.
A problem frequently encountered in practice is this: the website has a comprehensive “Privacy Statement” or “Cookie Policy”, but on first entry the user does not see, in a noticeable and accessible way, which cookies are activated and for what purposes. In such a case, “the existence of the document” does not always mean that “the obligation has been fulfilled”. The visibility and accessibility of the notice at the moment of first contact in particular become critical.
2.4. Third-party cookies and cross-border transfers: the invisible risk layer is often overlooked
In the cookie ecosystem, risk is often concentrated in third-party technologies. The Guidelines emphasise that responsibility for third-party cookies may in practice be shared and that it is important for the parties to act together. In this context, two main fault lines stand out in practice:
Where there are third-party cookies, they must be shown in the panel separately, clearly and by purpose.
Where transfers abroad may occur through third-party providers, Article 9 of Law No. 6698 and the related secondary legislation must be assessed separately. Reducing cookie compliance to a “consent screen” alone may make the transfer layer invisible.
2.5. The practical threshold for cookie compliance: not a “banner” but a four-component structure
In practice, what makes cookie compliance robust is not a banner on its own but four components working together:
2.5.(i) Cookie inventory and visibilitySetting out consistently which cookies are running, with their name, purpose, duration and first-party/third-party status.
2.5.(ii) Matching purpose to legal basisFor each cookie category, determining with reasons which purposes require explicit consent and which can be carried out on processing conditions other than explicit consent, without taking the easy route of the “necessary” label.
2.5.(iii) Genuine preference management (opt-in)Keeping non-necessary categories switched off by default; presenting the user with accept, reject and preferences options in the first layer without steering; and not treating passive behaviour such as “continuing to use the site” as consent.
2.5.(iv) Reversibility and evidenceEnsuring that users can easily change their preferences later (accessibility of the panel/icon) and keeping preference records in a compliant manner.
3. The risks “copy-paste” texts create in audits and disputes
One of the most common practices in preparing website texts is to produce a quick solution by “adapting” templates circulating in the market or the text of another website. At first sight this approach may appear to offer cost and speed advantages. In audit processes and in a dispute, however, the text itself often becomes the source of risk. This is because, once connected to concrete processes, website texts go beyond being “information” and become a basis that gives rise to undertakings, evidence and liability.
3.1. Mismatch between text and process: “compliance on paper” may not work in reality
The most fundamental problem with copy-paste texts is the gap between the process the text describes and the process actually in operation. For example, the text says “we obtain explicit consent” but the consent mechanism is not properly designed; it describes the “conditions of the right of withdrawal” but the order flow/delivery model does not meet them; it lists “data transfers” but the infrastructure actually used is different. The question asked during an audit is not how well-written the text is but whether it is consistent with practice. In a dispute, the text takes on the character of a “representation” and a “promise” for the other party, and produces binding consequences for the company.
3.2. Wrong category / wrong role: e-commerce language, membership relationships and the marketplace model get mixed up
Template texts are generally written for an “average” business model. However, the legal structure of a website varies with the B2C/B2B structure, the intermediary/supplier role, the membership system, the payment and delivery model and even the advertising/marketing infrastructure. A common risk in practice is that the text speaks as a “seller” while the company actually acts as an “intermediary” (or vice versa), or that the distance selling structure is confused with a service/subscription structure. Role errors of this kind make the text directly problematic in both consumer disputes and administrative reviews.
3.3 Burden of proof and record-keeping: the text alone does not provide a defence
Many obligations are not completed merely by publishing the text; they require a provable record-keeping system. It must be possible, when needed, to show through records the stages at which the notice was given, consent was obtained, pre-contractual information was provided, the contract was concluded and the right of withdrawal process was operated. Template texts often assume such a record-keeping system. If the system does not generate such records, however, the text remains a mere “statement” and its defensive value decreases.
3.4. Overly broad statements: they create unnecessary undertakings and a wide area of liability
The other problem most often seen in copy-paste texts is an unnecessary broadening of scope driven by a reflex to “cover every possibility”. Overly broad data categories, open-ended transfer wording, disproportionate retention periods or vague sentences such as “we use it for the following purposes” give rise to debates on “specificity/proportionality” during audits. In a dispute, these statements may turn into an area of liability that the company has widened with its own hand.
3.5. Risk of becoming outdated and failing to track legislation: the text “freezes” while the system is updated
Template texts usually create a feeling of being “done” on the day they are published. Website infrastructure, however, changes constantly: new integrations are added, new cookies run, different shipping/payment models are introduced and new marketing tools come into use. If the text is not updated, a “self-defeating” inconsistency develops on the company's site over time. In an audit, this inconsistency is seen as a direct problem in terms of “currency and accuracy”.
3.6. Conclusion: template texts are fast, but the risk is often more costly than the speed
For this reason, website texts should be treated not as a “set of texts” but as a compliance structure tied to the business model, the flow and the technical infrastructure. The soundest approach is (i) first to clarify the processes and data flows, (ii) then to write the texts on the basis of that reality, and (iii) finally to design the notice/consent/pre-contractual information/contract steps so that they generate evidence. In such a structure, website texts become more than information. They become a consistent and defensible framework that protects the company during audits and in disputes.
4. Regulated/specialised areas: additional layers of obligations that must be designed separately according to the business model and sector, and that often carry direct binding force
In general, the “basic” set of texts and compliance structure for many websites consist of similar headings. In some sectors, however, the website is not only a channel through which information and sales flows are conducted. It is also an area in which regulations apply directly and which becomes the “touchpoint” for specific notification/transparency/warning obligations. In regulated or specialised areas, therefore, publishing general texts is often insufficient. Additional layers with direct binding force, which must be designed separately according to the business model, come into play.
These layers can be read under two headings:
(i) content and processes mandated by sector-specific regulations;
(ii) contractual/undertaking-based obligations arising from the business model itself.
4.1. “General compliance” is not enough here, because the texts become not mere explanations but a regulated standard of conduct
In regulated areas, statements on a website are often not treated as “corporate messaging”. In audits and disputes they are approached from the perspective of “transparency obligations” or “misleading representations”. This has two consequences:
The texts become not merely content but part of a standard of conduct with which compliance is expected.
Flows on the site (registration, membership, payment, service delivery, information screens) cease to be a “design choice” and are treated as compliance requirements.
In regulated areas, therefore, website texts are not a “copyable template”. They are often a binding framework that must be designed together with the process in the manner envisaged by the regulation.
4.2. Additional layers of obligations generally arise along three axes
In regulated/specialised areas, additional obligations in practice tend to concentrate along the following three axes:
4.2.i Transparency and mandatory information screensIn some sectors, certain risk warnings, fee/commission information, limits on the scope of service, conditions that vary according to user status or certain declarations are expected to be clearly presented on the website. The critical point here is not to bury the information in a “hidden” document but to make it visible at the moment the user makes a decision.
4.2.ii Contract architecture and compliance of the approval flow with regulationIn regulated areas, not only the content of the contract but also how the contract is concluded matters. The flow of pre-contractual information, contract, approval and record-keeping may differ according to user categories (consumer/merchant/professional client, etc.). A “one-size-fits-all contract” approach therefore creates direct risk in some business models.
4.2.iii Data processing, identity verification and record-keeping obligationsIn regulated areas, obligations such as customer due diligence, identity verification, retention of transaction records, generation of audit-ready logs and, where necessary, reporting touch the website flow. At this point, the existence of the technical/procedural infrastructure supporting the text becomes as critical as the accuracy of the text.
4.3. In which sectors is an “additional layer” almost unavoidable?
By way of example, additional layers of obligations are often more pronounced in the following areas (each assessed under its own set of legislation and authorities):
Financial services and fintech (payment services, electronic money, investment services, etc.)
Crypto-asset services / digital asset platforms (topics such as user classification, risk warnings, custody/transaction processes, record-keeping and reporting)
Healthcare, telehealth and medical services (sensitive data, explicit consent, privacy, information and retention)
Education and services aimed at children (children's data, age verification, the language and format of the notice)
Marketplace / intermediary platforms (role distinction between seller, intermediary and service provider; distance contract responsibilities; complaints/returns)
Digital advertising/AdTech (cookies, profiling, transfers, third-party ecosystems)
The point here is not so much to say “these sectors must always have these texts” as to recognise that, by the very nature of the sector, the website intersects with a set of regulations and becomes the area in which they are applied.
4.4. Conclusion: in a regulated area, the website is not a “shop window” but the surface on which compliance is applied
In regulated/specialised areas, the website is often the “most visible and most testable” surface of a company's compliance. The approach should therefore not consist of simply adding general texts and moving on. It requires sector-specific additional layers to be designed separately on the basis of the business model's allocation of roles, user flows, data processing logic and record-keeping system. Otherwise, even if a set of texts appears to “exist”, the areas in which the website structure produces binding consequences remain weak in audits and disputes.
5. Conclusion and closing remarks
Website texts and flows are often seen as a matter of “communication” or “design”. Yet they can become a legal basis that produces binding consequences for the company during an audit, complaint or dispute. A website should therefore be treated not merely as a visible shop window but as an operational area in which regulatory compliance, management of undertakings and evidence must be designed together.
The problems we see most often in practice mostly stem from the same root cause. The texts “exist” but are not consistent with the process. Approval mechanisms “work” but are not designed on the right legal basis or by the right method. A record-keeping system is “assumed” but does not generate evidence. Yet the aim of compliance is not merely to publish texts. It is to present the right content at the right touchpoint, obtain valid consent where needed, ensure that consent can be withdrawn and make all these steps demonstrable when needed.
Against this background, our practical approach is clear. We first clarify the business model and the data flow. We then write the texts in line with that reality. Finally, we design the steps of notice, consent, pre-contractual information and contract together with system-generated records. Particularly in regulated/specialised areas, this approach is not a “good practice” but often the mandatory minimum standard of compliance.
As a final word: the website is not only a company's most visible face in the digital world but also the surface that is most easily tested and most quickly questioned. Texts and flows should therefore be managed not through “copyable templates” but through a consistent and provable framework tied to the sector, business model and technical infrastructure. Doing so both reduces operational risks and strengthens the organisation's professional credibility.
Att. Sara Civiler
GlobalB Law
05332118645