The First 24 Hours of a Cyber Incident: A Türkiye–EU Legal Reporting Playbook

Legal position last verified: 28 August 2026.

The first 24 hours of a cyber incident are not merely a race to restore systems. In the same period, the technical team must contain the event, management must protect continuity, legal advisers must distinguish several notification thresholds, and communications teams must avoid presenting unverified assumptions as fact. These tasks cannot be managed by treating every incident as if it were governed by a single “72-hour rule”. Cyber incident reporting is therefore the disciplined management of several thresholds and starting points, not one universal deadline.

Article 7(1)(b) of Türkiye’s Law No. 7545 on Cybersecurity requires in-scope persons and organisations that use information systems to provide services, collect or process data, or conduct similar activities to report to the Cybersecurity Presidency without delay vulnerabilities or cyber incidents detected within the field in which they provide services. The statute does not impose a general 24- or 72-hour period for that duty.¹ If personal data are involved, the Turkish data breach regime and, where relevant, the GDPR may run alongside that obligation. NIS2, DORA and, from 11 September 2026, the Cyber Resilience Act may add different triggers and reporting sequences.

This study provides a decision framework for a Türkiye-based business managing incidents with Turkish and EU/EEA connections. It is not a substitute for checking sector rules, contracts, insurance conditions, the national law implementing NIS2, or the official reporting route available when the incident occurs. For the wider governance and baseline-control framework, see our study on corporate cybersecurity legal obligations.

Working principle: open one authoritative incident record, then manage scope, threshold, clock, recipient and accountable owner separately for each legal regime. Waiting for complete technical certainty can cause an early-reporting deadline to be missed.

1. Cyber incident reporting clocks: one incident, different triggers

The first legal table used by the response team should do more than list statutes. It should identify the fact that starts each clock. Saying that “the attack began on Friday evening” is not enough. The actual occurrence, the organisation’s awareness, a later classification as significant or major, and the point at which a personal data breach becomes apparent may all be different moments.

These periods do not mean that every event is automatically reportable. Each regime has its own personal, organisational, sectoral, incident and risk thresholds. Threshold analysis should nevertheless proceed in parallel with technical investigation. A sequence in which the forensic investigation is completed before legal review starts is not compatible with short reporting windows.

2. The legal purpose of the first 24 hours

The objective of the first day is not to produce a definitive root-cause report. It is to limit harm, prevent irreversible loss of evidence, preserve reporting options and create a decision trail that can later be explained. An initial notification may properly be incomplete. The important distinction is between incomplete information and invented certainty: an unknown should be marked as under investigation, and an inference should not be recorded as a verified fact.

Legal review should not become a gate that slows necessary containment. Equally, the technical response should not treat the event as nothing more than malware removal. Shutting down a server, deleting a temporary object or rebuilding a cloud resource may erase evidence of attacker movement, data access or the organisation’s first awareness. The response plan must permit urgent, reversible containment while requiring deliberate approval for destructive remediation.

3. Five timestamps that must remain distinct

The incident record should preserve at least five different times:

1. Occurrence: the earliest malicious activity or disruption supported by technical evidence.
2. Detection: the moment an alert, report or supplier notification reached the organisation.
3. Organisational awareness: the point at which the authorised team reasonably understood that the event was genuine and which systems might be affected.
4. Legal classification: the time a personal data breach, significant NIS2 incident or major DORA incident was identified under the relevant test.
5. Notification and update: the dispatch time and version for each recipient.

Each entry should include its time zone, source, recorder and any uncertainty. This discipline is especially important under DORA, where awareness and classification as a major incident are not the same event. It also permits a business to answer a later question such as “why did your statutory clock start at that point rather than when the first malicious packet appeared?”

4. The first 60 minutes: establish command

Containment and preservation

Appoint an incident commander. Apply proportionate, reversible containment to affected accounts, devices, network segments and cloud resources. Extend log retention, capture critical images or memory where appropriate, and start a record of who acquired, transferred and accessed evidence. Confirm who may make business-continuity decisions if isolation will interrupt an essential service.

The legal incident record

Open a single incident number. Record the potentially affected legal entities, controller and processor roles, countries served, critical customers and the facts currently known. Enter potential deadlines even if no notification decision has yet been made. Define when external counsel, forensic specialists, insurers or crisis communications advisers will be called.

One verified communications flow

Give staff a short instruction: do not forward suspicious content, wipe affected devices, contact the attacker, or answer media and customer questions independently. Use an approved, access-controlled channel for the incident team and consider whether the attacker may have access to corporate email. Record decisions in the incident file rather than leaving them only in ephemeral chat messages.

5. Six legal tests: from technical event to reportability

1. Which legal entity is affected? Group companies may share infrastructure while having different controller, NIS2 entity, manufacturer or DORA financial-entity roles.
2. Which asset and service are affected? Record disruption, duration, service recipients, geographic spread and functional loss.
3. Are personal data involved? Assess confidentiality, integrity and availability, and run the Turkish and GDPR tests separately.
4. Has a sector threshold been met? A NIS2 significant incident and a DORA major ICT-related incident should not be conflated with a generic severity rating.
5. Is a product with digital elements affected? Examine the manufacturer’s role, product scope, active exploitation and the definition of a severe security incident.
6. Is there another reporting route? Customer, insurer, lender, market, law-enforcement and sector-regulator duties belong on separate lines even when the factual package overlaps.

6. Hours 4–12: complete the decision matrix

A matrix entry should not be left blank. If the threshold cannot yet be decided, state what information is missing, who has been asked for it and when the decision will be revisited. That distinction turns passive waiting into a controlled investigation.

7. Hours 12–24: convert analysis into notification decisions

Turkish reporting routes

Because Law No. 7545 does not set a universal number of hours, an incident team should not wait for the end of the first day. The “without delay” standard in Article 7(1)(b) must be applied to the event and the relevant field of service. The operative channel, form, secondary rules and any sector-specific criteria should be confirmed from current official material and guidance issued by the Cybersecurity Presidency.

For the Turkish personal data regime, 72 hours is an outer limit rather than a permission to wait. The Board’s Decision No. 2019/10 interprets notification to the Board as being required without delay and no later than 72 hours after the controller learns of the event. Affected data subjects are to be informed, once identified, within the shortest reasonable period by an appropriate method. The recipients, timing and content of those two communications are not identical.

EU/EEA reporting routes

A NIS2 early warning is not a completed forensic report. It is an early communication that may address whether unlawful or malicious acts are suspected and whether a cross-border effect is possible. The entity’s inclusion, the competent CSIRT or authority, forms and any national variation must be confirmed under the implementing law of the relevant Member State. Directive timelines do not eliminate that national-law check.

Under the GDPR, authority notification is not required where the breach is unlikely to result in a risk to people’s rights and freedoms. If that conclusion is reached, its facts and reasoning should be documented. Under DORA, the first-notification sequence begins when the ICT-related incident is classified as major. If classification occurs more than 24 hours after awareness, the first notification is due within four hours of classification.⁸

CRA Article 14 is not yet applicable on 28 August 2026. The European Commission page updated on 31 July 2026 states that the Single Reporting Platform is to be operational by 11 September 2026 and that functional and security testing is under way.⁹ Manufacturers should therefore prepare their internal route now, but recheck the live platform and official instructions on the reporting date.

8. What an initial notice should contain

An early notice should not imitate certainty that the organisation does not possess. Subject to the mandatory form for the relevant regime, the first package can hold:

• the incident number, affected legal entity and secure contact;
• occurrence, detection, awareness and classification times, clearly distinguished;
• the affected services, systems, countries and user populations;
• the known nature of the event and any indicators of attack or vulnerability;
• personal data categories and estimated ranges for people and records;
• operational, financial, safety and cross-border effects;
• containment, recovery and risk-reduction measures already taken;
• information that remains unknown and the proposed next update; and
• the information’s sensitivity and the secure response channel.

Number every version. When new evidence changes an earlier statement, record the correction and its basis rather than silently overwriting the previous account. Keep proof of submission, any portal receipt and the exact version sent.

9. Responsibility matrix: ownership in the incident room

10. Supplier and cloud incidents: do not turn dependency into delay

When an incident begins at a cloud, payroll, email or managed-security provider, the supplier’s investigation does not automatically pause or extend the customer organisation’s reporting periods. The point of awareness must nevertheless be determined separately under each regime by reference to whether the information available to the organisation is sufficient. Under the GDPR, a processor must notify the controller without undue delay after becoming aware of a personal data breach. The controller must manage its own awareness point and 72-hour authority assessment.¹⁰ Under Turkish data protection law, the controller and processor security relationship should likewise be managed so that notification accountability does not disappear into the contract chain.

Incident clauses should cover the supplier’s first-alert period, round-the-clock contacts, access to relevant logs and evidence, sub-processors, data location, investigation support, regulator assistance, coordination of public statements and cost allocation. They should also prohibit a supplier from waiting for a full root-cause report before giving the customer a factually useful early alert.

11. Evidence, confidentiality and review discipline

Evidence preservation does not justify copying everything without limit. Define the purpose and scope of collection, access rights, retention period and transfer method. Mark personal data, workforce communications, trade secrets and customer information according to their actual sensitivity. Before transferring material to an external forensic provider or another group company, examine the legal basis, contractual permissions and international-transfer rules.

Keep contemporaneous technical notes distinct from legal analysis commissioned for a defined purpose. Do not assume that adding “privileged” or “confidential” to every document creates legal protection. Privilege and confidentiality depend on the relevant jurisdiction, participants, purpose and handling of the communication. Incident notes should remain factual, dated and proportionate.

12. Customers, data subjects and public communications

A regulatory filing, a communication to data subjects, a contractual customer notice and a public statement are not the same document. A data-subject communication should enable people to protect themselves. It should describe, in clear language, the nature of the breach, likely consequences, measures taken and a usable contact route. Generic assurances that “security is important to us” do not replace specific protective guidance.

Communications should not disclose details that materially assist an attacker or include unnecessary personal data. They should also not minimise a verified effect. Subject lines and links must be designed so that the notice itself does not resemble phishing. Provide an independently navigable page or known contact channel where possible. Each version should pass a short fact check by the technical, legal and communications teams; one spokesperson should be appointed and employees should be directed not to speculate on social media.

13. Hours 24–72 and final reports

The incident record does not close after day one; the reporting chain becomes more detailed. For Turkish and GDPR analysis, update the affected data, people, consequences and measures. A NIS2 incident notification expands the early warning with the incident’s severity and impact and, where available, indicators of compromise. If the incident is ongoing when the one-month final-report point arrives, NIS2 provides for a progress report at that time and a final report within one month after the incident has been handled.¹¹

Under DORA, the intermediate report is due within 72 hours of the initial notification even if the incident’s status or handling has not changed. An updated intermediate report is submitted without undue delay once regular activities have recovered. The final report is due no later than one month after the intermediate report or, where applicable, the latest updated intermediate report.

Once CRA Article 14 applies, the different final-report triggers must not be collapsed. For an actively exploited vulnerability, the final report follows within 14 days after a corrective or mitigating measure is available; for a severe incident affecting product security, the period is one month after the incident notification. The initial and follow-up route should be retested against the platform that is actually operational at the time.

A post-incident review should address the root cause, missed alerts, decision delays, supplier performance, communications errors and control improvements. It should assign dated corrective actions and an owner. Understanding systemic causes before reducing the review to individual blame is more likely to prevent recurrence.

14. Worked scenarios

Scenario A — Customer accounts compromised at an online retailer

Unusual sessions and exports are detected. In the first hour, accounts are constrained, logs preserved and the relevant controller identified. The Turkish cybersecurity reporting question and the Turkish data breach awareness time are recorded separately. The team prepares protective guidance on password resets and fraud monitoring while confirming which people and records were affected.

Scenario B — Ransomware at an EU manufacturing subsidiary

Production stops at an EU subsidiary of a Türkiye-based group. The subsidiary’s NIS2 scope and the Member State’s implementing law are checked; disruption, customer effects and cross-border consequences are measured. Although group headquarters provides support, the accountable legal entity and local CSIRT or authority are separately identified. A parallel GDPR track is opened if workforce or customer data may be affected.

Scenario C — Active exploitation in software sold in the EU

A researcher reports that a product vulnerability is being used in attacks. The manufacturer validates the evidence and product scope, opens its PSIRT process, prepares remediation and gives users proportionate risk-reduction guidance. If awareness occurs on or after 11 September 2026 and the CRA conditions are met, the Article 14 sequence is opened without waiting for completion of the patch: the 24-hour early warning, 72-hour notification and, for an actively exploited vulnerability, final report within 14 days after a corrective or mitigating measure becomes available.

15. A 24-point first-day checklist

1. Assign the incident number and incident commander.
2. Record occurrence, detection and awareness times with time zones.
3. Contain affected accounts, devices, systems and services proportionately.
4. Prevent deletion of logs, images and volatile data.
5. Start evidence custody records and access controls.
6. List the affected legal entities and countries.
7. Identify controller, processor and possible joint roles.
8. Record data categories and estimated people/records as ranges.
9. Measure critical-service and business-continuity effects.
10. Open the Law No. 7545 without-delay assessment.
11. Calendar the Turkish data breach awareness time and 72-hour limit.
12. Confirm NIS2 scope and the national implementing law.
13. Record GDPR risk and high-risk tests separately.
14. Check DORA scope and major-incident classification.
15. For CRA, check the date, manufacturer role and product scope.
16. List sector, customer, insurance and finance notifications.
17. Request the supplier timeline, scope, logs and sub-supplier information.
18. Name an owner and deputy for each legal regime.
19. Draft initial notices distinguishing known from unknown facts.
20. Prepare protective messages for data subjects and customers.
21. Appoint one spokesperson and approve question-and-answer material.
22. Preserve submission evidence and every notification version.
23. Schedule the next technical and legal decision points.
24. Assign owners for 72-hour, intermediate and final reports.

16. Frequently asked questions

Must every cyber incident be reported within 72 hours?

No. Turkish Law No. 7545 uses a “without delay” standard rather than a fixed 72-hour period. The Turkish personal data regime, GDPR, NIS2, DORA and CRA have different thresholds and starting points. Each must be tested separately.

Can an organisation notify before the technical investigation is complete?

Yes. Early-reporting regimes can operate on limited initial information. Known and unknown facts, containment measures and the next update should be clearly separated, and estimates should not be presented as verified findings.

Does the Turkish 72-hour period also govern notice to affected people?

No. The Board’s decision treats notification to the Board as required without delay and no later than 72 hours after awareness. Affected data subjects are to be informed, once identified, within the shortest reasonable period by an appropriate method.

Which authority receives a NIS2 notification?

NIS2 establishes a CSIRT or competent-authority framework, but the precise recipient, scope, form and enforcement rules must be confirmed under the implementing law of the relevant Member State.

When does DORA’s four-hour period begin?

It begins when the ICT-related incident is classified as major. The initial notification must also be submitted no later than 24 hours after awareness; Article 5(2) of Delegated Regulation 2025/301 addresses classification occurring after that point.

Are CRA incident reports already required on 28 August 2026?

No. CRA Article 14 applies from 11 September 2026. The Single Reporting Platform and official reporting instructions should be checked again when a report may need to be made.

Does the organisation’s clock pause when the incident is at a supplier?

A supplier investigation does not automatically pause or extend the organisation’s reporting periods. The point of awareness must still be determined separately under each regime by reference to the sufficiency of the information available to the organisation. Contracts should require prompt alerts, information updates, preservation and investigative support.

Is one notification enough for an incident affecting several countries?

Not necessarily. Controllers, NIS2 entities, financial entities, manufacturers and competent authorities may differ by legal entity and country. Group coordination does not replace a separate check of each local obligation.

17. Conclusion: speed means disciplined decisions, not haste

Success in the first 24 hours is not measured by sending the greatest number of messages as quickly as possible. With clear command, separate timestamps, regime-specific thresholds and versioned notifications, a business can manage the incident and later explain its decisions. A robust cyber incident reporting process should bring the legal matrix, supplier contracts, evidence procedure and crisis communications together in one realistic exercise.

---

Legal information note

This study is for general information only. It is not legal advice, a cybersecurity assessment or a notification decision for any particular organisation, incident, sector or country. Applicable rules must be confirmed against the facts, legal entity, sector, national implementing law and official arrangements in force when the event occurs.

18. Primary and official sources

• Turkish Law No. 7545 on Cybersecurity, particularly Articles 2 and 7.
• Turkish Law No. 6698 on the Protection of Personal Data, Article 12, and the current public announcement concerning Board Decision No. 2019/10.
• Directive (EU) 2022/2555 (NIS2), Article 23.
• Regulation (EU) 2016/679 (GDPR), Articles 33–34.
• Commission Delegated Regulation (EU) 2025/301, Article 5.
• Commission Delegated Regulation (EU) 2024/1772 on the classification criteria for ICT-related incidents under DORA.
• Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 14, 69 and 71.
• European Commission, “Cyber Resilience Act — Reporting obligations”, last updated 31 July 2026.

Related reading

Related studies on the same subject and the broader practice page are listed below.

• Data Protection, Technology and Digital Regulation
• Is France Moving from Windows to Linux? DINUM’s Move, Digital Sovereignty, GDPR and Türkiye’s KVKK
• Cyber Resilience Act Reporting Duties Now Apply: What Changes for Manufacturers Supplying Digital Products to the EU?
• Responding to Türkiye’s Cybersecurity Presidency: A Company Guide to Official Notices, Vulnerability Remediation and Inspections
• When Your Cloud Provider Is Breached: A Türkiye–EU Cybersecurity Supply Chain and Contracting Playbook

Footnotes

---

1. Turkish Law No. 7545 on Cybersecurity, Article 7(1)(b), official text published by the Grand National Assembly of Türkiye (accessed 28 August 2026).↩︎

2. Turkish Law No. 7545, Articles 6(1)(h) and 7(1)(b).↩︎

3. Turkish Personal Data Protection Authority, public announcement concerning Board Decision dated 24 January 2019 and numbered 2019/10, official page (accessed 28 August 2026).↩︎

4. Directive (EU) 2022/2555 (NIS2), Article 23(3)–(4), EUR-Lex.↩︎

5. Regulation (EU) 2016/679 (GDPR), Articles 33–34, EUR-Lex.↩︎

6. Commission Delegated Regulation (EU) 2025/301, Article 5(1), EUR-Lex.↩︎

7. Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 14 and 71, EUR-Lex.↩︎

8. Commission Delegated Regulation (EU) 2025/301, Article 5(2).↩︎

9. European Commission, “Cyber Resilience Act — Reporting obligations”, last updated 31 July 2026 (accessed 28 August 2026).↩︎

10. GDPR, Article 33(2); Turkish Law No. 6698, Article 12(2).↩︎

11. NIS2, Article 23(4)(d)–(e); Commission Delegated Regulation (EU) 2025/301, Article 5(1)(b)–(c).↩︎