Tecof • September 28, 2026
KVKK Compliance: A Checklist for E-commerce Sites
In Brief
KVKK compliance is the work of writing down which legal basis an e-commerce site relies on when it processes customer, visitor and employee data, for how long it keeps that data and with whom it shares it — and then actually implementing that on the system side. The hard part in e-commerce is not writing the text; the order flow collects name, address, phone, payment and purchase history by its very nature, and that data then spreads to the courier, the payment provider, the accounting software, the email tool and the advertising platforms. Non-compliance usually comes not from bad intent but from the fact that nobody has ever mapped that spread. As of 2026 the question is not "do we have a privacy notice" but "does every data field we collect have a legal basis, a retention period and an owner".
Thursday afternoon, 15.10. The dashboard of a home textiles store that has been selling for nine years shows 61,400 registered customers. The registration form asks for first name, surname, email, phone, date of birth and gender; nobody on the team knows what the last two are collected for, because those fields arrived with the site back in 2017. The newsletter list holds 38,000 records, and for 12,000 of them there is no record of when or from which screen consent was given. Fourteen different third-party tags run in the site's source; for four of them, nobody knows who added them or when.
The real problem here is not a missing document but an inventory that was never produced. The privacy notice sits on the site, but it describes eight data fields while the form collects twelve; the cookie banner says "accept" but offers no way to refuse, and the tags fire before the banner appears. None of these three mismatches is fixed by writing legal text; they are fixed by changing what the form, the banner and the tag manager actually do. That is what makes KVKK compliance a systems job rather than a writing job.
1. What Exactly Does KVKK Cover in E-commerce?
KVKK governs the processing of any information relating to an identified or identifiable natural person; in e-commerce that covers a wide area, from the customer who places an order to the seemingly anonymous visitor browsing the site. The concepts below are the foundation the rest of the checklist rests on.
Which fields count as personal data in e-commerce?
Personal data in e-commerce is not just name and address; any record that can single out a user falls within scope.
- Identity and contact data: first name, surname, email, phone, delivery and billing address.
- Transaction data: order history, cart contents, return records, invoice number.
- Security data: IP address, session records, login logs, device information.
- Marketing data: cookie identifiers, advertising IDs, email open and click records.
- Customer service data: call recordings, live chat transcripts, complaint files.
IP addresses and cookie identifiers are personal data too; the "if there is no name it is not personal data" assumption is the most common conceptual error in e-commerce, because those identifiers point directly at a person the moment they are matched to an order record.
Who is the data controller, and who is the processor?
The company running the store is the data controller; the platform, courier and email tool that process data on its instructions are processors. That distinction has a practical consequence: you cannot transfer responsibility to a service provider. A leak at the courier concerns you too, both in the customer's eyes and legally, which is why you need written contracts with processors and security undertakings inside those contracts.
Is explicit consent always required?
No; explicit consent is not the only legal basis for processing personal data, only one of several. The name, address and phone number needed to prepare and deliver an order are processed under performance of a contract; invoices and financial records fall under a legal obligation. Explicit consent mainly comes into play for processing that is not essential to running the service — marketing communication, profiling and non-essential cookies. Tying everything to consent is a risky shortcut: when a customer withdraws it, you end up unable to deliver their order.
Stay away from special categories of data
Processing special categories — health, biometrics, religion, membership — is subject to far heavier conditions, and a typical e-commerce operation has no need for them. Even so, there are two places where they get collected unintentionally: free-text fields (a customer writing a health condition into an order note) and return-reason forms. Do not make those fields mandatory, use a list of options instead of free text, and instruct the customer service team not to record such information.
2. Data Inventory: What Do You Hold, Where, and For How Long?
The inventory is the first step of KVKK compliance, because every other document is derived from it: the privacy notice and the retention and destruction policy are both the inventory written out in prose. Text written before the inventory exists does not describe what the site actually does.
How is the inventory produced?
Start from the screen, not from the data category. Registration form, guest checkout, newsletter box, contact form, review field, return request screen, call centre recording — write down, one by one, which fields each of them collects. Then answer four questions for every field: why do we collect it, which legal basis does it rest on, where does it sit, when is it deleted. A field with no answer to "why" is a field to remove from the form. Date of birth is necessary only if you sell age-restricted products; if a gender field exists for segmentation, it should be optional.
How is a retention period set?
Retention is not arbitrary; data is kept for as long as the legal basis it rests on lasts. For financial records that is the period set by tax legislation, for contract-based records the limitation period, for marketing consent the time until consent is withdrawn. Put the current periods into a table together with your own accountant and legal adviser; a single "keep everything ten years" rule both accumulates unnecessary risk and conflicts with the duty to destroy data.
Does destruction actually run?
A destruction policy on paper while nothing is ever deleted in practice is the most common situation we see. Three things are needed for destruction to work: the periodic destruction job has to be on a calendar; deletion has to have an equivalent not only in the main database but also in backups, the data warehouse, the email tool and the support system; and every destruction round has to be recorded in a report. Deleted records reappearing after a restore from backup is the quietest gap in the whole process.
| Data category | Typical source | Typical legal basis | What sets the period |
|---|---|---|---|
| Name, address, phone | Order form | Performance of contract | Contract limitation period |
| Invoice and payment record | Accounting integration | Legal obligation | Financial legislation |
| Member account | Registration screen | Contract / legitimate interest | Account activity |
| Newsletter subscription | Newsletter box | Explicit consent + İYS approval | Withdrawal of consent |
| Marketing cookie | Tag manager | Explicit consent | Cookie lifetime / consent |
| Site security log | Server | Legitimate interest | Security need |
3. Notice and Explicit Consent Are Not the Same Thing
The privacy notice is a duty to inform and must be fulfilled in every case; explicit consent is a separate approval obtained for specific processing. Merging the two into a single checkbox is the most frequent error, and the easiest to fix.
What should the privacy notice contain?
The notice should explain, in plain language, the identity of the controller, which data is processed for which purposes, to whom and for what purpose it is transferred, the method and legal basis of collection, and the rights of the data subject. Two practical rules: the text must match the fields the form actually collects, one for one, and it must be reachable at every point where data is collected. A single link in the footer is not enough; it has to be visible separately on the registration screen, the checkout screen and the contact form.
How is a consent checkbox built?
Explicit consent must be freely given, specific to a subject and informed; those three conditions translate directly into checkbox design.
- Not pre-ticked: the user has to tick the box themselves.
- Not a condition of service: "you cannot order without accepting the newsletter" invalidates the consent.
- Separated: acknowledging the privacy notice, consenting to commercial messages and accepting the membership agreement should be separate boxes.
- Provable: the date, time, IP, version of the text shown and the screen it was given from should all be recorded.
That last item is the most neglected in practice. A newsletter list with no consent records is, at the moment of an audit, in the same position as a list with no consent at all.
Cookies and consent management
Cookies strictly necessary for the site to work require only a notice, while analytics and marketing cookies require explicit consent. The technical consequence is clear: advertising and analytics tags must not fire until the user has consented. Most sites have a banner, yet the tags trigger on page load independently of it — in which case the banner is purely decorative. The refuse option must be as visible as the accept option, and consent once given must be changeable later.
Commercial message consent is a separate world
Commercial communication by SMS, email and phone is subject to separate legislation and to the Message Management System (İYS) alongside KVKK; having obtained a KVKK-compliant explicit consent does not on its own grant the right to send commercial messages. We covered how that side is set up in our article on İYS, and we looked at the cost and conversion side of channel choice in the email versus SMS comparison.
| Aspect | Privacy notice | Explicit consent | İYS approval |
|---|---|---|---|
| When required | All processing | Consent-based processing | Commercial messages |
| Checkbox | Not required | Required | Required |
| Withdrawable | — | Yes | Yes |
| Proof record | Text version | Date, IP, version | System record |
| Consequence if missing | Breach of duty | Processing loses its basis | Cannot send messages |
4. Third Parties and Transfers Abroad
Most data in e-commerce does not stay where it was collected; the moment an order is created it spreads to at least five different systems. The hardest part of compliance is being able to show that this spread is under control.
The typical transfer map
Behind a single order there are usually these transfers: card and amount data to the payment provider, name, address and phone to the courier, invoice details to the accounting software, contact details to the email tool, behavioural data to analytics and advertising platforms, and order details to the marketplace if you sell there. For each transfer you need to know three things: which fields go, for what purpose, and whether there is a written contract with the receiving party. Card data never resting in your own systems is the structure to aim for on the payment side.
Not over-transferring
The most common excess is integrations sending the entire customer record to the other side "to keep it simple". The courier does not need order history; the email tool does not need the billing address. Narrowing the field mapping while setting up the integration is more effective than any document written afterwards. We covered the technical side of checking field-level mapping in our article on APIs and integrations.
Transfers abroad
A significant share of cloud hosting, email delivery tools, analytics and advertising platforms process data outside Turkey, and those transfers need their own legal basis. The legislation in this area changed recently and implementation details continue to develop, so for every foreign service you use, verify with your legal adviser, against the current rules, which mechanism you rely on and whether the required notifications have been made. The practical advice is this: list which service processes your data where, match that list against your contracts, and make updating the list part of your procurement process whenever a new tool is added.
| Party | Typical data transferred | Control needed | Common mistake |
|---|---|---|---|
| Payment provider | Amount, order, card transaction | Card data never resting with you | Logging card details |
| Courier | Name, address, phone | Narrowed field mapping | Sending the whole profile |
| Email tool | Email, name, consent record | Not syncing unconsented records | Uploading the entire list |
| Ad platform | Cookie ID, event data | No firing before consent | Tags independent of the banner |
| Accounting / ERP | Invoice, amount, identity | Restricted access rights | Full permissions for everyone |
5. Technical and Organisational Measures
KVKK requires appropriate technical and organisational measures for data security, which in e-commerce largely comes down to access rights, encryption, logging and staff discipline. Documents are what an audit asks for, but these four headings are what prevents a leak.
Access rights and role management
Tie who can see what in the admin panel to a written permission matrix. The warehouse team needs the delivery address, not the customer's email history; the marketing team needs segment lists, not individual invoice records. Three basic rules: a departing employee's account is closed the same day, access granted to agencies and freelancers is time-limited, and admin accounts use two-step verification. Keeping bulk export rights with only two people stops most accidents before they happen.
Encryption, backups and transfer security
The site should be served over HTTPS end to end, passwords stored irreversibly, backups kept encrypted, and the location of those backups written into the inventory. We detailed the certificate's role on both the security and visibility side in our article on SSL. Exporting data as an unencrypted email attachment is, in practice, the most common gap and the easiest one to close.
Logging and traceability
When there is no record of who accessed which data and when, determining the scope of a breach becomes impossible. Admin logins, bulk exports, permission changes and views of customer records should all be logged, and those logs should be subject to their own retention period. Logging is the precondition for being able to meet the breach notification duty at all.
Staff and process discipline
The invisible part of organisational measures is people. Customer service not sharing data via screenshots, lists never being downloaded to personal email accounts, health-type information never being typed into order notes, new joiners signing a confidentiality undertaking, and a short awareness session at least once a year — none of this costs money, and all of it gets asked about in an audit.
6. VERBİS, Data Subject Requests and Breach Procedures
This section is the outward-facing side of compliance: the registration duty, requests from customers, and the bad-day scenario. All three end up being managed under pressure if they are not set up beforehand.
Is VERBİS registration required?
Registration with the Data Controllers Registry (VERBİS) is mandatory for controllers above certain thresholds; an exemption is provided for businesses below the employee-count and balance-sheet thresholds whose main activity is not processing special categories of data. Because thresholds and exemptions can change, verify whether you have a registration duty through the Authority's current announcements and together with your accountant. If registration is required, the inventory you declare has to match the data you actually process; a contradiction between the VERBİS declaration and the privacy notice is the first thing noticed in an audit.
What happens when a data subject request arrives?
A customer has the right to access their data, have it corrected or erased, learn to whom it has been transferred and object to processing, and they direct those requests to you first. Define a channel the request can reach (a dedicated email address and a form), log the incoming request, verify identity, and respond within the period the legislation sets. Confirm the current period and format requirements with your legal adviser. The point that matters in practice: when an erasure request arrives, deletion must not stop at the main database — there has to be a procedure for the email tool, the support system, the data warehouse and the backups as well.
If a data breach happens
Breach notification goes to the Board, and also to the affected individuals, within a short and limited period from the moment it is discovered — which is why the process cannot be designed on the day of the breach. What has to be prepared beforehand: who decides, which logs get examined, what text goes to customers, and how contact with service providers is established. A one-page response plan is the most valuable document you can write for this scenario. Verify the current deadline and scope of the obligation with your legal adviser.
Documents: the short list of what should exist
- Personal data processing inventory: the source of every other document.
- Privacy notice: with website, registration, checkout and call centre versions.
- Retention and destruction policy: with a period table by data category.
- Cookie policy: with the list of active cookies and their categories.
- Processor contracts: for the platform, courier, email tool and agency side.
- Breach response plan: with roles, deadlines and communication steps.
Raising Your Compliance Level in Thirty Days
Claiming full compliance in thirty days is not realistic, but the biggest gaps can be closed in that time. The order matters: text written before the inventory exists gets rewritten a month later.
Days 1-7: inventory and establishing the facts
List every screen where data is collected, write down field by field what each form collects, count the third-party tags running on the site, and map which systems hold which data. No text is written this week; only the current state is recorded. It is normal for the resulting list to be longer than expected.
Days 8-14: cutting the excess
Remove form fields with no justification or make them optional, narrow the field mappings in your integrations, delete unused third-party tags, rebuild panel permissions by role, and close the accounts of departed employees. This week's output is less data and less access.
Days 15-21: consent and information flows
Match the privacy notice to the inventory one for one, separate the consent checkboxes and remove pre-ticked ones, start recording consent with date and text version, wire the cookie banner so it genuinely holds the tags back, and align commercial message consents with the İYS side.
Days 22-30: process, contracts and a rehearsal
Complete the retention table and run the first periodic destruction round, list the gaps in your processor contracts, open the data subject request channel, write the breach response plan on one page, and run one erasure request end to end to see that the process actually works. To simplify data flows on the integration side, you can look at the integration options.
Here is the job for tomorrow morning: open your registration and checkout forms, write a one-sentence justification next to every field you collect, and remove that same day any field you cannot justify; data you never collect is data you do not have to protect, store or delete. On an e-commerce platform where controls like consent logging, retention periods and role-based permissions come built into the template, a large part of this list starts out already ticked. This article is a general framework; verify the current state of your own obligations with your legal adviser and accountant.
Frequently Asked Questions
Does KVKK apply to a small e-commerce site too?
Yes; scope is determined by whether personal data is processed, not by company size, and every site that takes orders processes personal data. What depends on size is not scope but certain additional obligations such as VERBİS registration. A one-person store still carries duties around notice, security and retention.
Can I copy a privacy notice from the internet?
A copied text does not describe the fields your site actually collects or the parties it transfers to, so in practice it does not work and creates a record of non-compliance. The text has to be derived from the inventory. You can use a template as a skeleton, but the data fields, purposes, recipients and retention periods have to be written for your own operation.
Is putting up a cookie banner enough?
It is not; the banner has to be functional, meaning analytics and marketing tags must not run until the user consents. The refuse option should be as visible as the accept option, consent once given should be changeable, and which cookies run for which purpose should be listed.
If a customer says "delete my data", do I delete their orders too?
No; the right to erasure is not absolute and does not extend to records kept under a legal obligation. Invoices and financial records are retained for the period the legislation requires. What you should do is delete the data whose basis has fallen away, such as marketing data and account details, and explain to the customer which records are kept and why.
I sell on a marketplace — whose responsibility is the customer data?
The marketplace is the controller for its own platform, but to the extent that you process the order data transferred to you, you are a controller for that data as well. Adding contact details obtained from a marketplace to your own marketing list requires separate consent and is also subject to the platform's rules.
Is using Google Analytics or advertising pixels a problem?
The problem is not their use but using them without consent and without disclosure. These tools fall in the non-essential cookie category; they must not fire before the user consents, they must appear in the privacy notice and the cookie policy, and where they process data must be written into your transfer inventory.
Does this cover my employees' personal data as well?
Yes; personnel files, payroll records, job applications and camera footage are personal data too, and they require their own inventory lines, retention periods and privacy notices. This is the most frequently skipped section in e-commerce companies, because attention concentrates on the customer side.
My newsletter list contains people with no consent record — what should I do?
For records where consent cannot be proven, the safe route is to obtain consent again or remove those records from the list. If you plan a re-consent campaign, bear in mind that you also need a valid basis for sending it; assess the channel and method for that with your legal adviser. The list shrinks in the short term, and both risk and deliverability improve in the medium term.
Can I keep my data with a cloud provider abroad?
Transfers abroad are possible, but they have to rest on one of the mechanisms the legislation provides, with the required notifications and documents completed. Because the rules in this area changed recently, verify your basis for every foreign service with your legal adviser against the current legislation, and keep the service list current in your inventory.
How often should I repeat the compliance work?
Review the inventory and transfer list every six months and the permission matrix and access list quarterly; run destruction rounds at the interval set in your policy. Beyond that, update the inventory after every new tool, new integration, new form field and platform change; the moment compliance breaks is usually the moment a new tool is quietly added.