How do you secure a website? A checklist based on the KVKK.
Under Article 12 of the KVKK, every website that collects personal data must take technical and organizational measures to keep that data secure. The Authority’s Personal Data Security Guide of April 2025 lists these measures but does not translate them, one by one, into the parts of a website. This checklist does that translation: the connection, the admin panel, the software, the release process, forms, logs, backups, service providers and the breach plan.
The Guide opens with a warning of its own: the view that complete security can be achieved with a single security product is not always correct, because threats change form every day. The approach it recommends is measures that complement each other and are checked regularly. That is why the items below are not a list to tick once and leave; they are questions to ask again every time the site changes.
Who is responsible for a website’s security?
The site owner. Article 12 of the Law places the technical and organizational measures needed to ensure an appropriate level of security on the data controller; the fact that an agency built the site does not remove this burden. Under the second paragraph of the same article, the companies that process data on your behalf, that is, the services that host the site, maintain it or carry the form messages, are jointly responsible with you for security. In 2026, the administrative fine for breaching the data security obligation ranges from 256,357 TL to 17,092,242 TL.
Does the whole site open via HTTPS?
The Guide requires that, where personal data is collected through websites, the connection be established with SSL or a more secure method. On today’s web, this means the whole site opening via https, not just the form page; the http address redirecting to https in a single step; and the HSTS header, which tells the browser to open the site only via https. The steps of the move are in the HTTPS and www redirect guide. In the 31 August 2026 measurement of this site’s open dataset, the Measurement Observatory, 83 of 131 live sites from Türkiye and the EU sent the HSTS header.
Who can get into the admin panel?
The Guide requires access to be granted only to the extent the job requires and to be provided with a username and password; the password should not be derived from personal information and should contain upper- and lowercase letters, numbers and symbols. The number of password attempts should be limited against brute-force attacks, administrator rights should be enabled only when needed, and the account of a person who has left should be deleted or disabled without delay. An access authorization and control matrix showing who can access what is also among the Guide’s recommendations.
On a website, this list covers more than the admin panel: the hosting panel, the domain account, DNS, and the accounts of the form and e-mail services are access to the site as well. The one most often forgotten is the account of the agency or freelancer who built the site, left open after the work is done. The Guide recommends two-factor authentication for remote access to data kept in the cloud; enabling it on each of these accounts managed over the internet follows the same logic.
Have you deleted unused software?
The Guide’s finding on software is clear: widely used software, especially in older versions, has documented security vulnerabilities, and deleting software and services you do not use, rather than keeping them up to date, is the method that may be preferred first because it is easier. For the software in use, patch management and updates are needed, along with regular checks of whether the measures taken are sufficient.
On a website, this means plugins that have been deactivated but not deleted, unused themes, old installations forgotten on the server, and test copies. In a ready-made content management system, the stack of software that needs updating is part of the system; how this cost compares with custom development is covered on the WordPress or custom development page.
Do you test changes before release?
A Board decision specific to the web shows why this question is on the list. In Decision 2023/1796, after a system change on a company’s website, a caching configuration exposed members’ names, surnames, membership and phone details to anyone. The Board found that the change had not been tested sufficiently before going live and imposed a fine of 200,000 TL.
The Guide likewise asks for security requirements to be taken into account from the start when new systems are procured or developed and when existing systems are improved. In practice, this means trying a change first on a copy separate from the live site, and checking it after release as well: is a page meant for a logged-in user being shown to another visitor; can form messages, admin pages and backup files be opened from outside?
Does the form check the data it receives?
The Guide requires checks that the data entering applications is correct and appropriate, and mechanisms that verify whether correctly entered information has been corrupted during processing. On a web form, this check is done on the server; validation in the browser is a convenience for the visitor, not security, because a request can also be sent bypassing the browser.
The second question is what the form collects and where the message goes: every field you do not need is extra data that has to be protected. Explaining to the visitor which data the form collects and for what purpose is the job of the privacy notice.
Would you notice an attack?
According to the Guide, systems are attacked from inside and outside, and despite the signs this often goes unnoticed for a long time. What it recommends: checking which software and services are running, determining whether there has been an intrusion or any activity that should not be there, keeping users’ activity logs regularly, reporting security problems quickly, and having regular vulnerability scans and penetration tests carried out. When an incident occurs, evidence should be collected and stored securely.
For a website, this means at the very least keeping login records for the admin panel and server logs, and someone actually looking at them. Since logs also carry personal data such as IP addresses, how long they are kept is set separately; the retention and disposal rules are in our article on designing a KVKK-compliant website.
Is your backup stored separately from the site?
The Guide deals with backups together with ransomware: against software that locks files and demands a ransom to unlock them, a backup strategy is needed; only the system administrator should be able to access the backups, and dataset backups must always be kept offline. Otherwise the backup may also be rendered unusable in the same attack.
A copy kept on the same server or in the same hosting account as the site is not the offline backup the Guide describes. The purpose of the backup is written in the Guide as well: to return to operation as soon as possible when data is damaged. Whether that is possible only becomes clear once the backup has been restored and tested.
Does your contract with service providers cover security?
The Guide requires a data controller that receives services from a data processor to make sure the processor provides at least the same level of security as the controller itself, and recommends the following for the contract: that it be in writing; that the processor act only on instructions and within the purpose and scope set out in the contract; a duty of confidentiality with no time limit; that the processor notify the data controller of a breach immediately; and that the categories of data transferred be listed in a separate clause. The data controller may audit the system itself or have it audited.
On a website, these companies are usually the hosting and content delivery service, the form and e-mail sending service, and the agency that maintains the site. If the server is abroad, the rules on transfers abroad also come into play.
Which security rules do you send to the browser?
In the Guide’s table of technical measures, “application security” appears as a heading, but the Guide does not name the web’s own tools. Chief among them are response headers. Content Security Policy (CSP) tells the browser which sources the page may load scripts, styles and images from; it is an additional layer of defense against cross-site scripting (XSS) attacks and does not replace sanitizing input. HSTS, in turn, makes the browser open the site only via https.
Every response from this site sends these headers: the default source is only its own domain, HSTS is set for one year and covers subdomains, and the site cannot be placed inside another page’s frame. You can see your own site’s headers in the browser’s developer tools, in the “Network” tab, among the response headers of the main document.
What has to happen within 72 hours of a breach?
Article 12 of the Law requires that, if the processed data is obtained by others through unlawful means, the data controller notify the data subject and the Board as soon as possible. In its Decision 2019/10, the Board set this period at 72 hours at the latest from the moment the breach becomes known; the Authority repeated the rule in an announcement of 20 January 2026. Notification is made with the Board’s breach notification form; if the 72 hours are exceeded for a justified reason, the reason for the delay is also explained. The affected people are informed as soon as reasonably possible.
72 hours is a short time in which to draw up a plan once a breach has happened. What needs to be in writing beforehand: who reports the breach to whom, when the service provider will notify you (the Guide says “immediately”), how evidence will be preserved and how the affected people will be reached. The Guide’s table of administrative measures also lists crisis management and the processes for informing the Board and the data subject as a separate heading.
Checklist
- Responsibility · you are the data controller; those who process data on your behalf are jointly responsible with you
- Connection · the whole site via https, single-step redirect, HSTS
- Access · personal accounts, strong passwords, attempt limit, two-factor authentication, accounts of people who have left closed
- Software · unused plugins and installations deleted, the rest up to date
- Release · changes tried first on a separate copy and checked after release
- Forms · validation on the server, only the fields you need
- Monitoring · login records and logs kept and read, regular vulnerability scans
- Backups · offline, accessible only to the administrator, restore tested
- Contracts · in writing, processing on instructions, confidentiality, immediate notice of a breach
- Headers · CSP, HSTS, frame protection
- Breach · a written 72-hour notification plan
This list was written as of 30 October 2026 on the basis of the Authority’s security guide and the regulations in force. It is not legal advice, and it does not replace a security test either. If you would like to measure together what your site shows from the outside, write to us.
If you want to see these answers on your own site, corporate web design delivers design, code and technical SEO from one hand, on a measurable budget.