Türkiye's Law No. 5651 and Log Records: Central Log Management Guide
Law 5651 log retention is the obligation under Türkiye's internet regulation (Law No. 5651) for organizations that give staff, guests or customers internet access to keep internal IP allocation logs and access records whose integrity can be proven. This guide is not a legal text; it explains, from an IT manager's point of view, the central log architecture from FortiGate to FortiAnalyzer or a syslog server, time-stamping, retention policy and access control.
What Is Law No. 5651 and Who Does It Cover?
Law No. 5651, Türkiye's internet regulation formally titled the Law on Regulating Broadcasts on the Internet and Combating Crimes Committed Through Such Broadcasts, defines four actors: content providers, hosting providers, access providers and collective use providers. Each carries a different record-keeping duty. Corporate offices usually fall into the collective use provider category.
The part of the law that matters to corporate IT is that it leaves the traffic-data retention period for access providers (internet service providers) and hosting providers to secondary regulation within a minimum and maximum range, while collective use providers are covered by a separate regulation. The law states that access providers retain traffic data for a period set by regulation of no less than six months and no more than two years; for hosting providers the range is one to two years. Check which role applies to your organization against the current text of the law on mevzuat.gov.tr.
A collective use provider is a party that gives people the ability to use the internet at a certain place for a certain period. Under the common interpretation, a company that opens internet access to employees over wired or wireless networks, a university serving students, a hotel with guest Wi-Fi or a hospital all fall within this definition. Collective use providers operating for commercial purposes (such as internet cafés charging for access) are subject to additional duties such as a permit certificate and filtering; a corporate office is in most scenarios treated as a non-commercial provider. This is not legal advice; confirm your organization's category with your legal counsel and the current text of the regulation.
The practical consequence for IT is this: whatever category you are in, you must be able to produce a record showing which internal IP address each device leaving your network used, with which MAC address and during which time window; retain that record in a way that proves it has not been altered; and present it within a reasonable time on request. These three verbs (produce, prove, present) are the design requirements of the log architecture, and they overlap with the technical measures of KVKK, Türkiye's personal data protection law. To meet both obligations on one platform, see our KVKK technical measures checklist.
Which Logs Must Be Kept? Internal IP Allocation Logs and Access Records
An internal IP allocation log shows the IP address an organization assigned on its internal network, the start and end time of its use, and the MAC address of the device using it. The regulation's definition of access records also covers destination IP and port information where a single IP is shared through ports (NAT). In practice DHCP, NAT and identity session records together form this record.
A DHCP log alone is not enough. Knowing that a device received an internal address does not show which public IP and source port that address used to reach the internet; the NAT log is what maps the internal address to the outside world. On networks with authentication (802.1X, captive portal), the session record that binds an IP to a user account is the third link. If the clocks of these three sources drift apart, the chain breaks during an audit, which is why time synchronization is critical.
In a corporate network, the components that generate these records are typically:
- DHCP server (FortiGate built-in DHCP, Windows Server or a separate appliance): IP lease, MAC address, start and end time.
- Firewall (FortiGate): traffic log, NAT translation, session start and end, user identity, application and destination.
- Wireless controller and access switches (FortiAP, FortiSwitch): client association, port and VLAN information; in a FortiLink-managed environment these records join the FortiGate log stream.
- Authentication server (RADIUS, Active Directory, FortiAuthenticator): mapping of user name to device and time.
A common mistake is to keep only an "internet egress log" and forget the DHCP and identity layers. Because the auditor's question is "who went out from this address at this time?", every link in the chain must be collected in the same central place. Removing unused rules directly reduces log volume; we cover that step by step in our article on firewall rule cleanup and policy audits.
Retention Period and Time-Stamping: How Is Integrity Proven?
For the retention period, the Regulation on Internet Collective Use Providers requires access records to be stored electronically on the organization's own systems for two years, and a value confirming their accuracy, integrity and confidentiality to be recorded daily. In practice that value is produced with a time stamp; verify the period that applies to you in the current text of the regulation.
A time stamp, defined under Türkiye's Electronic Signature Law No. 5070, is a service that proves a piece of electronic data existed at a specific moment and has not changed since. The mechanism is simple: the cryptographic hash of the daily log file is calculated, sent to an electronic certificate service provider authorized by BTK, and returned signed with official time information. During an audit, the file's hash is recalculated and compared with the stamp; if a single byte has changed, the hash no longer matches. Because only the hash is sent, no personal data leaves the organization.
BTK's website hosts the IP Log Signer software prepared under the earlier 2007 regulation; it is reported that the 2017 regulation removed the requirement to use a specific piece of software, so verify the current position. At corporate scale, stamping is usually the job of the central log platform or a separate signing service. Two design points matter: stamping must be daily and automated (a manually triggered process gets forgotten, and a forgotten day has no evidence), and the stamped file must be byte-identical to the archived file (if compression happens after stamping, the hash will not match).
When planning retention, define three separate periods: the analytics period (how long logs remain in a queryable database, typically 30–90 days), the archive period (how long raw logs are kept compressed and stamped, i.e. the period the legislation requires) and the disposal point (when the record is deleted after the period ends). KVKK's principle of not keeping data longer than necessary meets the 5651 retention duty here: the archive period is set to the statutory period and automatic disposal follows. Because secondary sources quote different periods, rely only on the legislative text.
Log Architecture Comparison: On-Device, Syslog, FortiAnalyzer and SIEM
Central log management can follow four architectures: the firewall's own disk, a general-purpose syslog server, FortiAnalyzer and a SIEM. In a small office the on-device disk is enough in the short term; once a two-year stamped archive, multiple devices and audit reports are needed, FortiAnalyzer or syslog plus a signing layer becomes a practical necessity. A SIEM is for organizations needing correlation and a SOC.
| Criterion | On-device disk | Syslog server | FortiAnalyzer | SIEM |
|---|---|---|---|---|
| Suitable scale | Single device, low traffic | A few devices, multi-vendor environment | Multiple FortiGates, Security Fabric | Many sources, organization with a SOC |
| Retention | Limited by disk, risk of rotation overwrites | Depends on disk plan, managed manually | Analytics and archive quotas managed separately | Hot/cold tiers, cost depends on licensing |
| Integrity evidence | None; separate stamping required | Separate signing script or service required | Log file checksum and integrity verification command; time stamp via an additional service | Varies by product; usually an additional service |
| Transport security | Local | UDP by default; TCP/TLS must be configured | Encrypted proprietary protocol with FortiGate, reliable delivery | Depends on the collector agent |
| Access control | Same privileges as device admin | Operating-system level | Role-based, device grouping with ADOMs | Role-based, granular |
| Built-in compliance reports | No | No | Yes (PCI DSS, HIPAA templates; custom reports) | Yes, requires rule writing |
| Loss risk | Logs lost if the device fails | Packet loss over UDP is silent | Device caches logs on disconnect and resends | Depends on the agent |
| Operational load | Lowest | Medium; disk, rotation, signing by hand | Medium; quota and report tuning | High; rules, correlation, staff |
The appeal of the on-device disk is that it needs no extra hardware; its weakness is that when the device fails or is replaced, the logs go with it. SSD variants such as the FG-61F (128 GB) and FG-71G (64 GB) offer limited space for local logging; we use that space only as a temporary buffer and keep the permanent archive centrally.
A syslog server (rsyslog, syslog-ng) is the most flexible option in a multi-vendor environment, but UDP transport silently swallows packet loss, and rotation and signing must be built by hand. On FortiGate, syslog transport can be configured in three ways: UDP, the older TCP-based legacy reliable mode, and reliable TCP mode using RFC 6587 framing. For a flow that must produce audit evidence, choose reliable mode and confirm that the receiver understands that framing. For configuration details, see our article on FortiGate logging, monitoring and FortiAnalyzer integration.
FortiAnalyzer is the central log platform designed for Fortinet devices. It keeps logs in two tiers, analytics (a queryable SQL database) and archive (raw, compressed), with separate quotas and retention periods for each; when an archive file is rolled, its checksum is written to the event log and can later be checked with an integrity verification command. According to Fortinet's FortiAnalyzer administration and best practice guides, an average analytics log is 600 bytes, an average archive log is 80 bytes, and analytics logs are compressed to an average of 150 bytes after seven days; we size platforms with these figures. A qualified time stamp, however, is not a built-in product feature; a separate signing step is designed to send the hash of each daily archive file to a certificate service provider.
A SIEM is for correlation and incident management; the 5651 obligation itself does not require one. If you already run a SIEM, positioning FortiAnalyzer as the collection and archive tier and the SIEM as the analysis tier keeps archive volume under control.
How Do You Build the FortiGate to FortiAnalyzer Log Flow?
For the FortiGate log flow the order is: first the time source (NTP) and time-zone decision, then which policies generate logs, then defining the FortiAnalyzer or syslog destination with reliable, encrypted transport, and finally writing the quota, retention and stamping policy. Reverse the order and fixing it later means retroactive log loss.
- Time source. FortiGate, FortiAnalyzer, the DHCP server and the identity server all point to the same NTP source. Time-zone confusion is the most common audit problem; decide on one standard (we store UTC centrally and convert to local time in reports) and document it.
- Logging policy. For each firewall rule you decide separately whether session start and end are logged. For 5651, all internet-bound traffic must be logged; for traffic between internal segments you balance volume against value. Without a rule cleanup first, unused rules also consume quota.
- Destination. FortiAnalyzer talks to FortiGate over an encrypted proprietary protocol; when the connection drops, the device caches logs and resends them. If syslog is used, prefer reliable TCP mode and, where possible, TLS. Fortinet's Log Integrity and Secure Log Transfer appendix covers both secure transfer and archive checksum verification.
- Device grouping. In FortiAnalyzer, ADOMs (administrative domains) separate branches, subsidiaries or customer groups, each with its own quota and retention. They are also an access-control boundary: branch IT sees only its own ADOM.
- Quota and retention. The analytics quota is calculated as daily log count × analytics days × 600 bytes (first week) and 150 bytes (afterwards); the archive quota as daily log count × retention days × 80 bytes. When the quota fills, the oldest records are deleted, so we set the archive quota above the statutory period with an alert threshold.
- Stamping. When the daily archive file closes, its hash is sent to the time-stamping service; the stamp is kept for the same period as the archive. The step is automated and raises an alert on failure.
- Testing and drills. After deployment, a drill confirms that the question "who used this internal IP at this time last month?" can be answered within minutes.
According to the Fortinet FortiAnalyzer data sheet, the hardware family scales from 100 GB/day (FAZ-300G) to 8,300 GB/day (FAZ-3750G) of logs and from 180 to 10,000 devices/VDOMs; virtual machine and FortiAnalyzer Cloud options also exist for smaller environments. We choose the model after measuring daily log volume for at least a week; in our field experience, platforms sized on estimates trigger quota alarms early.
Access Control, Retention Policy and Audit Evidence
Log access control is a role-based model that separates who can view records, who can export them and who can delete them. Because 5651 records contain personal data, the KVKK principle is least privilege; the log platform's own administration log must also be retained, because the auditor will also ask "who accessed the logs?".
In practice three roles are enough: a read-only analyst (queries, cannot export), an operator (quotas, devices, report templates; cannot delete) and an administrator (retention policy and deletion, with four-eyes approval). Accounts must be personal, never a shared "admin" account; central authentication and multi-factor authentication should be mandatory for the log platform too.
The retention policy should be written down and cover: the log sources collected, analytics and archive periods, the stamping service and frequency, how disposal is verified, where the backup copy lives and how the archive is restored after a disaster. The Personal Data Security Guide (Technical and Organizational Measures) published by the KVKK Board lists keeping log records regularly and retaining access logs among technical measures; a 5651 archive produces a large part of that evidence at the same time.
Audit evidence consists of three items: a report showing the user/device mapping for a given date and internal IP, a verification output showing that the day's archive hash matches its time stamp, and the access record of the person who produced the report. If you do not want to run this operation with your own team, quota monitoring, stamping checks and a monthly compliance report can be included in a managed firewall service; in our projects we bundle these three tasks into a single service calendar.
Frequently Asked Questions
Does an ordinary company that gives employees internet access have to keep logs under Law No. 5651?
Under the common interpretation, yes: an organization providing internet use at a certain place and time is a collective use provider and is expected to keep internal IP allocation logs. Commercial providers have extra duties. Confirm your category with the current regulation text and your legal counsel.
How long must 5651 logs be retained?
The Regulation on Internet Collective Use Providers provides for two years of retention of access records; the law sets different ranges for access and hosting providers. Because secondary sources quote different periods, rely on the legislative text and cite the provision in your retention policy.
Is a log without a time stamp valid?
The regulation requires a value confirming the accuracy, integrity and confidentiality of records to be recorded daily; in the field this value is usually produced with a time stamp. A log whose integrity cannot be proven is weak evidence in an audit, so daily, automated stamping belongs in the architecture.
Is FortiGate's own disk enough for 5651?
In a single-device, low-traffic office, short-term local logging works, but logs are lost if the device fails, a two-year archive does not fit on the disk, and stamping requires exports. We recommend keeping the permanent archive on FortiAnalyzer, FortiAnalyzer Cloud or a syslog server with reliable transport.
Does FortiAnalyzer apply a time stamp?
FortiAnalyzer records a checksum when an archive file is rolled and offers an integrity verification command, but an official time stamp from a BTK-authorized provider is not a built-in feature. A separate, automated step that stamps each daily archive hash is designed alongside it.
What is the risk of sending syslog over UDP?
UDP produces no error for lost packets; records missing during peak moments show up as gaps in an audit. FortiGate supports reliable TCP mode with RFC 6587 framing; confirm the receiver understands this mode and, where possible, encrypt it with TLS.
How should logs be protected under KVKK?
IP addresses, MAC addresses and user names are personal data. Access should be role-based under least privilege, the platform's own administration log must be kept, and disposal after the period must be automatic and verifiable. Meet the KVKK guide's technical measures and the 5651 archive on one platform.
Conclusion
Türkiye's Law No. 5651 and its regulation expect three things from your organization: produce internal IP allocation logs, retain them for the statutory period with provable integrity, and present them on request. This is an architecture question: a single time source, the DHCP–NAT–identity chain collected in one place, reliable transport, separately planned analytics and archive quotas, daily automated time-stamping and role-based access. Once a two-year stamped archive is involved, FortiAnalyzer or reliable syslog plus a signing layer becomes a practical necessity. Always verify legal details such as periods and the definition of obligated parties against the current text of the legislation.
If you would like to design log volume measurement, FortiAnalyzer sizing, retention policy and the stamping flow for your existing FortiGate environment together, contact us for a free discovery call; we listen to your requirements and prepare a proposal only for the components you actually need.
