A KVKK data-protection checklist for publishers

Mention KVKK (Türkiye’s data-protection law, the local counterpart of the GDPR) and what comes to mind first is e-commerce sites and banks; publishers generally count themselves “small and unaffected.” But look at the range of personal data a publishing house actually holds: authors’ identity and contact details, reviewers’ identities and evaluation records, store customers’ addresses and order histories, newsletter subscribers, the financial details in royalty contracts…

What’s more, some of this data — reviewer identity, for one — sits in a more delicate balance than ordinary customer data: it must be protected and retained for years at the same time. Nor are the penalties symbolic: as of 2026, administrative fines for breaching data-security obligations can run to millions of lira (the amounts are revalued annually; for current figures see kvkk.gov.tr).

The 12 points below are a practical starting list for a publisher taking its KVKK snapshot. They are no substitute for legal advice; but they give you a concrete assessment in hand before you go to your counsel.

Data inventory and legal basis

1. Do you have a data map? In which process do you collect which data from whom? Submission form, reviewer pool, orders, newsletter, contact form — a list of the fields collected per channel is the first step. You cannot protect data you don’t know you have.

2. Does every processing activity have a stated basis? Each act of data processing must rest on a legal ground. Example: processing a name and address for an order falls under “performance of a contract” and needs no separate consent; but sending marketing to that same customer’s email requires explicit consent. Forms that squeeze both into a single checkbox are the most common mistake.

3. Have you checked your VERBİS status? VERBİS (Türkiye’s registry of data controllers) registration obligations depend on annual employee count and balance-sheet thresholds; the thresholds and exemptions are updated by decisions of the Board. Turn the assumption “we’re small, surely out of scope” into verified information.

Notice and consent

4. Are your privacy notices channel-specific? Instead of one catch-all text: the submission form, the reviewer invitation, store membership, and the newsletter sign-up should each have their own notice — because the purposes and the transfers differ.

5. Is your explicit consent actually explicit? A pre-ticked box, consent buried in the terms of service, and “you can’t proceed without accepting” designs do not count as consent. For newsletter subscriptions, double opt-in is good practice for proof and for courtesy alike.

6. Is consent recorded — and revocable? Who consented, when, and to which text — and if they change their mind, how is that processed? Consent management is not a one-off event but a versioned record: when the text is updated, it must be traceable which user approved which version.

Sensitivities specific to publishing

7. Is reviewer data under double protection? A reviewer’s identity is both personal data and an editorial secret. In a double-blind arrangement, the reviewer-author wall is the editorial counterpart of KVKK’s purpose-limitation principle: only those who need to see a reviewer’s identity should be able to, and the accesses should be logged.

8. Are your retention periods defined? KVKK requires data to be kept only as long as the purpose requires, then deleted or anonymized. But take care: retaining certain records is itself an obligation — TR Dizin requires peer-review process records for at least five years, and financial records have statutory periods of their own. The right construction is neither “keep everything forever” nor “delete everything at once”; it is a defined period per data type.

9. Are your logs leaking personal data? Names, emails, and addresses sitting in the clear in technical records (system logs, error logs) is a risk that slips past most reviews. Masking personal data in logs is a concrete piece of the “data security measures” the law demands.

E-commerce and third parties

10. Is customer data separated from publishing data? Your store customer’s account should carry no permissions whatsoever into the publishing workflows; your e-commerce operator should have no access to author or reviewer data. Role separation is precisely the “access restriction” measure KVKK prescribes.

11. Do you have a list of your data transfers? The courier gets addresses, the payment provider processes transaction data, the email service holds address lists. Who receives which data — and do your privacy notices match that real list?

12. Are your analytics and cookies honest? Curiosity about statistics does not justify smuggling tracking cookies through as “essential.” On the cookie banner, declining must be as easy as accepting; analytics should run on consent. (That is how we do it on this site, too.)

The structural fix: instead of patching compliance on afterwards

What most of the items on this list have in common is this: they are achieved not by a one-off “compliance project” but by mechanisms embedded in daily operations. Consent versioning, role-based access, log masking, retention policies — added on afterwards, these always stay incomplete.

In designing Nasirus we treated data protection not as a module but as ground to build on: from explicit consent to the ordering of access, these principles have had their counterpart in the product from the start. A summary of our security approach is on the site; if you would like to take your institution’s 12-point snapshot together, write to us — and bring your legal counsel to the demo; the most productive questions always come from them.