How to Build a GDPR and KVKK Compliant Website: A Business Guide

A GDPR compliant website takes far more than a cookie banner. In this guide I walk through privacy notices, consent, cookie controls, international transfers, form copy and the Turkish KVKK rules that apply if you also serve Turkey. One honest note first: I am not a lawyer. I build the technical side of websites. So treat this as a practical guide, not legal advice, and let a lawyer sign off on your final texts.

What is a GDPR compliant website and how do you build one?

A GDPR compliant website is a site that ties every piece of personal data it collects to a lawful basis, explains this clearly before collection, asks for separate consent where needed, and keeps non-essential cookies off until the visitor agrees. You build one by mapping your data first, then shaping texts, forms and cookie controls around that map.

In practice the process has four steps. First, you list what data the site collects and where. Next, you write down the purpose and the lawful basis for each item. Then you move that information into the privacy notice, the form copy and the cookie panel. Finally, you test whether the tags on the page really follow those rules.

I cover each step below. However, one point matters from the start: compliance is not a one-off project. Every new form, ad pixel or chat widget changes your data map. So a GDPR compliant website is something you review on a schedule, not something you tick off once.

What personal data does a typical website collect?

In practice, most business owners start with "we don't collect any data." Then we build the inventory, and the list grows. Even a simple company website has several data sources. For example, on a typical site I usually find these items:

• Names, phone numbers, emails and messages from contact, quote and booking forms.
• IP addresses, browser details and timestamps in server logs.
• Analytics cookies and device identifiers.
• Advertising pixels and remarketing audiences.
• Live chat, WhatsApp buttons and newsletter sign-ups.
• CVs and attachments from job application forms.

Each line then raises three questions. Why do I collect this? How long do I keep it? Who receives it? That is why I open a simple spreadsheet at the start of every project. Rows hold the data sources. Columns hold purpose, lawful basis, retention period and recipients. As a result, you write your texts from a concrete map instead of guesswork.

The same sheet also doubles as your record of processing activities under Article 30. Moreover, it helps when a data subject request or an audit arrives. You can show who accesses what within minutes.

How do GDPR and Turkey's KVKK differ?

Both laws share the same idea. Still, they differ in detail. The General Data Protection Regulation (EU) 2016/679 can apply to companies outside the EU when they offer goods or services to people in the EU or monitor their behaviour. KVKK is Turkey's Law No. 6698 on the Protection of Personal Data. Many of my clients sell into both markets, so they need to think about both.

In short, if you only serve EU customers, GDPR is your main frame. If you also run Turkish pages or process data in Turkey, you need to plan for KVKK as well. I explained how I structure language versions in my multilingual website SEO guide.

What belongs in a privacy notice, and where should it sit?

A privacy notice tells people who processes their data, for what purpose and on which lawful basis. It also names recipients, retention periods and the rights people have. Under Article 13 you give this information at the time you collect the data. As a result, the notice must be reachable before someone hits "send."

I place it in three layers. The first layer is the full notice, linked from the footer on every page. Next, the second layer is a short line under each form, written for that specific form, with a link to the full text. The third layer lives inside the cookie panel and covers cookies only.

Also, avoid copying a template from another company. Their purposes are not yours. Listing processing you don't do creates confusion. Missing processing you do perform creates risk. Your data map is the only honest source for this text.

Another common mistake is merging the notice with a consent checkbox. A notice informs, so it needs no agreement. Asking visitors to tick "I have read and accept the privacy policy" does not turn information into consent. It only blurs the line between the two.

When do you actually need consent?

Consent is only one of six lawful bases in Article 6. The others include contract, legal obligation and legitimate interests. Therefore adding a consent box to every form is not the right default.

For example, when someone fills in a quote form, you use their name and phone number to send the quote. That step happens at their request before a contract. In most cases it does not rely on consent. However, if you want to send marketing messages to the same number later, that is a new purpose. You need a separate opt-in for it.

Specifically, these are the typical cases where I see consent as the right basis:

1. Non-essential analytics and advertising cookies.
2. Marketing emails and SMS, depending on local e-privacy rules.
3. Transfers that rely on the explicit consent derogation.
4. Special category data, such as health information, where no other condition applies.

Consent is not insurance. If you ask for it where you don't need it, you must stop processing when someone says no. So agree with your lawyer which basis covers which activity, and write it into your data map.

How should you build a consent checkbox?

The technical rule is simple. The box starts unticked, and the form still works without it. If you make consent a condition for the service, it is no longer freely given. The European Data Protection Board says the same in its guidelines on consent: pre-ticked boxes do not count as valid consent.

In practice, each purpose gets its own box. "Send me marketing emails" and "Send me SMS offers" sit on separate lines. The visitor can pick one and skip the other. That keeps consent specific instead of bundled.

You also need proof, because regulators ask for it. When a form arrives, I store the date and time, the ticked boxes, the version of the text shown and the source page. When you change the wording, you bump the version number. Then you can show exactly which text each person agreed to.

Finally, make withdrawal as easy as giving consent. Article 7 asks for exactly that. A one-click unsubscribe link at the bottom of every email is the simplest fix. It is also the one people forget most often.

How should you write form copy?

Form copy is the short sentence that tells people what they agree to at that moment. After all, nobody reads long legal paragraphs next to a submit button, so two clear lines do the real work. I usually write something like this: "We only use your details to reply to your request. Read our privacy notice for more."

Keep data minimisation in mind while you design the form. If you don't need a birth date for a quote, don't ask for it. Every extra field lowers conversion and adds to your compliance load. I go deeper into field choices in my article on booking, quote and demo form design.

Job application forms, on the other hand, need extra care. CVs often contain photos, health details or union membership. So I add a line such as "Please don't include health, religious or similar information in your CV." In addition, state how long you keep applications, and then actually delete them after that period.

How should cookie consent work on your site?

The core rule comes from Article 5(3) of the ePrivacy Directive, read together with GDPR consent standards. Non-essential cookies stay off until the visitor agrees. Analytics and ad tags should not fire until someone clicks "Accept." Above all, this is where most sites fail, even when the banner looks fine.

A good cookie panel has these features:

• "Accept" and "Reject" buttons on the first layer, with equal prominence.
• Separate choices per category, such as necessary, analytics and marketing.
• A list of cookies in each category, with provider and lifetime.
• A permanent link that lets visitors change their choice later.

In other words, a banner with only an "OK" button informs, but it does not collect consent. Likewise, "by continuing to browse you accept cookies" does not meet today's standard. That is why I make rejecting as easy as accepting whenever I build a panel from scratch.

If you target Germany, note that the TDDDG (formerly TTDSG) sets out the same principle in its section 25. The rule is local, but the logic is identical.

How does cookie consent affect ads and analytics?

I will be honest: a properly working cookie panel reduces the data you measure. For example, a visitor who rejects cookies won't show up in Google Analytics in the classic way. That also affects how ad platforms optimise your campaigns.

Google offers Consent Mode for this situation. Tags read the visitor's choice and adjust. Without consent they don't set cookies, and they only send cookieless signals. For users in the EEA, Google expects advertisers to pass these consent signals to its ad products. Therefore, if you advertise in Europe, your cookie panel needs to talk to Consent Mode.

My advice is to accept the gap and read your reports with it in mind. For instance, tagging campaign links with a UTM builder strengthens the source data in your CRM. I also explained how consent shrinks audience lists in my piece on remarketing and the sales funnel.

How do international data transfers affect your website?

Websites also move data abroad without anyone noticing. Your server may sit in one country, your email provider in the US, your form tool in Ireland and your chat widget somewhere else. Each of these can count as an international transfer.

Under GDPR Chapter V, you can transfer data outside the EEA on the basis of an adequacy decision, appropriate safeguards such as standard contractual clauses, or narrow derogations. For the US, the EU-US Data Privacy Framework adequacy decision came into force in July 2023. However, it only covers companies that have certified under the framework.

Meanwhile, Turkey changed its own rules too. Law No. 7499 amended KVKK Article 9 in 2024, and the new regime has applied since 1 June 2024. It now lists adequacy, appropriate safeguards such as standard contracts, and incidental transfers. If you sign a standard contract, you must notify the Turkish authority within five business days.

In practice I add a "where is the data stored?" column to the data map. Then I collect each provider's data processing agreement. When possible, I choose infrastructure in the same region. My business email guide covers the email side of that choice.

Do you need to register with Turkey's VERBİS?

This section only matters if you act as a data controller in Turkey. VERBİS is the Turkish Data Controllers' Registry. Not every company must register, because the Board exempts those below certain thresholds. According to the authority's public announcement, the current frame looks like this:

• Controllers with fewer than 50 employees and an annual balance sheet below 100 million Turkish lira are exempt, unless processing special category data is their main activity.
• If special category data is the main activity, the threshold is 10 employees and 10 million lira, under Board Decision 2025/1572.
• Controllers that don't keep balance sheet accounts only apply the employee criterion, under Decision 2025/2393.

For example, a dental clinic processes health data as its core activity, so it falls under the lower threshold. Check your own case with your accountant and lawyer. Remember that an exemption from VERBİS does not remove your duties on notices, security or cookies.

Which security measures does a compliant site need?

Article 32 of GDPR asks for appropriate technical and organisational measures. KVKK Article 12 sets a similar duty. On a website, that turns into a concrete checklist. On every GDPR compliant website project I set up at least the following:

1. HTTPS across the whole site with a valid certificate.
2. Strong passwords and two-factor authentication for the admin panel.
3. Form data stored in a protected panel, not sent around as plain email.
4. Regular updates for plugins and the core system.
5. Encrypted backups with restricted access.
6. Access logs that show who opened which record and when.

First, a password generator is a simple starting point for strong credentials. Still, a tool alone is not enough. Give access per person, and close accounts on the same day someone leaves the company.

How do you plan retention and deletion?

Deleting data is also as much a part of compliance as collecting it. The storage limitation principle in Article 5 says you keep data only as long as the purpose requires. So every item in your data map needs a written retention period.

For example, how long will you keep a quote request that never turned into a sale? You and your lawyer decide that. What matters is that the period exists on paper and that the site actually applies it. I don't leave this to manual cleanup. Each record gets a creation date, and a scheduled job deletes or anonymises records when their time runs out.

Watch for forgotten copies as well. Form data doesn't only live in the database. It also sits in notification emails, backups and spreadsheets someone exported last year. As a result, data you think is gone may still exist in three places. Your deletion plan has to cover those copies too.

How should you prepare for data subject requests?

GDPR gives people the right to access, correct and erase their data, among others. Article 12 sets a one-month deadline to respond, which you can extend in certain cases. KVKK sets thirty days. Either way, you need a ready process before the first request arrives.

In practice, I state clearly in the privacy notice how people can send a request. Then I build an admin screen where you can find all records for one person by email or phone. When a request arrives, gathering the data takes minutes rather than hours.

Don't skip identity checks, though. Sending someone's data to the wrong person is worse than a late reply. So I recommend replying only to the contact details already on file.

Keep a short log of every request, too. Record the date, request type, response date and outcome. That log keeps you inside the deadline. It also shows patterns. If people keep writing to leave your newsletter, your unsubscribe link is not visible enough.

What risks do third-party scripts create?

On business websites, compliance usually breaks because of code someone added later. An embedded video, a map, a chat bubble or a font service can send the visitor's IP address to another server the moment the page loads. The visitor doesn't need to click anything for that to happen.

So I ask three questions for every script. Does it run before consent? Where does it send data? Do we really need it? For example, hosting fonts on your own server is often better for both privacy and speed. I showed how to measure that speed gain in my Lighthouse performance test guide.

Likewise, for embedded videos you can use a click-to-load preview. No request goes to the video platform until the visitor presses play. The page gets lighter, and data stops flowing before consent.

If you use a tag manager, check which consent category each tag belongs to. When a marketer adds a new pixel and forgets that link, the banner looks right while the tag still fires in the background. Limit publishing rights to a few people. My rule for clients is simple: new code goes into the data map first, then onto the site.

Which legal pages does a GDPR compliant website need?

In practice, I prefer separate, easy-to-find pages over one giant legal page. For a typical business site I suggest a privacy notice, a cookie policy, a way to submit data subject requests, and, for online shops, terms of sale and a returns policy.

The GDPR notice also needs specific elements. These include the contact details of your data protection officer if you appointed one, the right to lodge a complaint and the name of the supervisory authority. Sites aimed at Germany also need a legal notice, the Impressum, which is a separate duty.

Link all of these from the footer, one click away. In addition, keep them visible on mobile. A link hidden three levels deep in a menu is, in practice, a link nobody can reach.

How does GDPR change for online shops and member accounts?

First, a brochure site and an online shop carry very different data loads. The brochure site mostly collects form data. The shop also processes addresses, order history, invoices and data that flows to payment providers. Consequently your data map grows from a few rows to dozens.

On sites with customer accounts, I pay close attention to these points:

• Ask only for the fields you need to complete an order.
• Keep guest checkout open, and don't force account creation.
• Separate newsletter consent from account creation, and leave the box unticked.
• Let users start account deletion from their own dashboard.

On payments, I recommend never storing card data on your own server. Let the payment provider handle that screen, and both your security load and your data map get simpler. Shipping companies also receive addresses, so list them as recipients in the notice. I cover other shop decisions on my ecommerce consulting page.

What are the most common compliance mistakes?

So here are the mistakes I see again and again. Most don't come from bad intent. They come from a site that an agency launched years ago and nobody reviewed since.

• There is a cookie banner, but tags load before consent.
• The privacy notice comes from another company and still names that company.
• Notice and consent sit together in one checkbox.
• The form won't submit unless the consent box is ticked.
• Form data stays in the database forever.
• Overseas providers are missing from the data map.

A quick first test needs nothing more than your browser. Open developer tools, go to the Network tab and load the page in a private window. Before you click anything in the banner, you'll see which outside domains receive requests. That way you test real behaviour instead of a theoretical checklist.

How often should you review compliance?

I tie reviews to change. Whenever someone adds a form, plugin, pixel or provider, I update the data map the same day. Beyond that, I recommend a full review at least once a year.

The rules also keep moving. Turkey rewrote its transfer rules in 2024 and updated VERBİS thresholds in 2025. In the EU, guidance from the EDPB and national authorities keeps evolving. Therefore a GDPR compliant website is never finished. Working with a lawyer who follows these updates is the safest way not to miss them.

In short, treat compliance like security patches: a normal part of site maintenance. If you want to see how I set measurable goals for a business site, read my guide on website conversion goals.

Who does what in a GDPR compliant website project?

First of all, compliance is never one person's job. The lawyer defines the texts and the lawful bases. The web team puts those decisions into forms, cookie controls and the database. Inside the company, someone owns the process and checks that it keeps working.

My role is usually the middle link. In web design projects I build the data map, set up the technical base and place the lawyer-approved texts where they belong. The final word on content always stays with the lawyer. Read this article with the same limit in mind: it is a general technical guide, not legal advice for your case.

Before we start, I ask clients for a short brief. It should list every plugin and service on the site, the ad platforms you use, who receives form emails, where you keep customer records and where your server sits. In practice, that list alone often reveals an old heatmap script nobody remembered.

To sum up, a well-planned GDPR compliant website lowers risk and builds trust. When visitors see that you respect their data, they feel more comfortable filling in your form.