Data Breach Notification Within 72 Hours: An Incident Response Plan for Egyptian Companies

Imagine a Monday morning in Cairo: an employee reports that a spreadsheet with 8,000 customer names and phone numbers was shared by mistake in a public link, or your IT provider finds that the online store's database was accessed overnight. What happens in the next three days now has a legal deadline.

The short answer: under the executive regulations of Egypt's Personal Data Protection Law 151/2020, controllers and processors must notify the Personal Data Protection Center within 72 hours of becoming aware of a personal data breach, and inform affected individuals within three working days of that notification. Meeting that deadline is almost impossible without a plan prepared in advance. This article gives you one: who does what, an hour-by-hour timeline, what evidence to keep, and how to tell customers.

Key takeaways

• The 72-hour clock starts when you become aware of the breach, not when the investigation ends.
• A breach is not only hacking: misdirected emails, lost laptops, public links and staff misuse all count if personal data is exposed.
• Name an incident team in advance, including the data protection officer, IT, management, legal and communications.
• Logs and access records are the evidence you need to know what happened and whom it affected.
• Practise once a year with a tabletop exercise; the first run always reveals gaps.

What the rule says and when it applies

The executive regulations of Law 151/2020 were issued by Ministerial Decree 816/2025 on 1 November 2025 and gave companies a one-year grace period ending on 1 November 2026, according to CMS's January 2026 update. Al Tamimi's analysis of the regulations summarises the breach duties: notify the Center within 72 hours of becoming aware of a personal data breach, and notify data subjects within three working days of the Center's notification, through the agreed contact method.

The regulations and the Center's guidance set out the details, such as the exact content of the notification and any exceptions. Those details can change, so check the current text with a specialist when you build your plan. The practical principle does not change: you must be able to find out quickly what happened, which data and people are affected, and what you are doing about it.

What counts as a personal data breach

Any incident that leads to personal data being accessed, disclosed, altered, lost or destroyed without authorisation. Common Egyptian examples:

• A customer list exported from the CRM and sent to a personal email or WhatsApp.
• A shared drive or spreadsheet link set to "anyone with the link".
• A stolen laptop or phone with unencrypted files.
• Ransomware on an office server holding HR or accounting files.
• An online store database or admin panel accessed by an attacker.
• A clinic receptionist sending a patient's results to the wrong number.
• An email with all customers in "To" instead of "Bcc".

Not every security incident involves personal data, but you only know after checking. Treat every incident as potentially reportable until you confirm otherwise.

Build the incident team before you need it

Write down phone numbers, including after-hours ones, and backups for each role. Include your software, hosting and cloud vendors' emergency contacts, and make sure your contracts oblige them to tell you about incidents quickly.

The 72-hour timeline, hour by hour

Hour 0 to 4: confirm and contain

• Record the time you became aware and who reported it. The clock starts here.
• Stop the leak: disable the public link, revoke compromised passwords and tokens, isolate the infected server, block the attacker's access.
• Preserve evidence before wiping anything: logs, screenshots, affected files.
• Call the incident team.

Hour 4 to 24: assess the scope

• Which systems and files were affected?
• Which categories of personal data: names, phone numbers, national IDs, health data, financial data?
• Roughly how many people, and are any of them children or patients?
• What harm could follow: fraud, phishing, embarrassment, discrimination?

Hour 24 to 48: decide and draft

• The DPO and legal adviser decide whether the incident is notifiable and what the notification should say.
• Draft the notification to the Center with the facts known so far, the measures taken and the DPO's contact details.
• Draft the message to affected individuals in clear Arabic, and English where needed.

Hour 48 to 72: notify and continue

• Management approves; the DPO submits the notification before the deadline.
• If facts are still missing, notify with what you know and update later rather than miss the deadline.
• Prepare customer service with a script, and plan the notice to individuals within the following three working days.

The full response cycle

The 72-hour rule covers notification, but a good plan covers the whole cycle. The US National Institute of Standards and Technology published SP 800-61 Revision 3 in April 2025, which frames incident response within its Cybersecurity Framework 2.0: preparing, detecting, responding and recovering as part of ongoing risk management. In practical terms for an Egyptian SME:

1. Prepare: the team, contact list, templates, logging and backups, before anything happens.
2. Detect and analyse: alerts, staff reports and customer complaints lead to a quick triage.
3. Contain: limit the damage fast, even if it is inconvenient.
4. Eradicate and recover: remove the cause, patch, restore from clean backups, monitor closely.
5. Notify: the Center within 72 hours, individuals within three working days of that notification.
6. Learn: a written review within two weeks, with owners and dates for each fix.

Evidence: why logs decide the outcome

Without logs, you cannot answer the questions the notification needs: when it started, what was accessed and whose data. Make sure your systems record:

• Logins, failed logins and password resets, with time and IP address.
• Exports, bulk downloads and permission changes.
• Admin actions in ERP, CRM and store dashboards.
• Access to sensitive records such as patient files or payroll.

Structured logging tools such as Pino make these records searchable. Keep logs protected from tampering and for a defined period. Our website security checklist covers logging with the other controls that prevent incidents in the first place.

How to tell affected customers

• Use plain Arabic: what happened, which of their data was involved, and when.
• Say what you have done and what they should do: change a password, beware of calls claiming to be from you, contact the bank if card data was involved.
• Give a contact channel with a real person, and make sure customer service has the same information.
• Do not minimise or speculate. Stick to confirmed facts and update if they change.
• Send through the contact method the customer agreed to, such as SMS, email or WhatsApp.

Three scenarios to rehearse

• Online store in Cairo: an attacker uses a leaked admin password to export orders with names, phones and addresses. Contain by revoking sessions and resetting passwords, check logs for the export, notify, and warn customers about fake delivery calls.
• Clinic in Alexandria: lab results sent to the wrong WhatsApp number. Small in scale but health data is special category. Ask the recipient to delete, document it, and assess with the DPO.
• Distributor in the Delta: ransomware encrypts the accounting server. Isolate, restore from offline backups, and investigate whether customer or employee data was copied before encryption.

Run one scenario as a two-hour tabletop exercise each year. It shows who is missing from the contact list, which logs do not exist and how long decisions really take.

How Nilex helps

Nilex builds business systems with the controls an incident response depends on: role-based access, audit logs of logins, exports and admin actions, structured application logs and secrets kept out of the code. We also help set up backups and restore tests. For existing systems, we can review what your software records today and close the gaps before 1 November 2026. Contact us through our contact page, and see how we work.

Frequently asked questions

How long do companies in Egypt have to report a data breach?

According to the executive regulations as summarised by Al Tamimi, controllers and processors must notify the Personal Data Protection Center within 72 hours of becoming aware of a personal data breach. Affected individuals must be informed within three working days of the Center's notification.

When does the 72-hour period start?

From the moment you become aware of the breach, not when you finish investigating. Record that time carefully, and notify with the facts you have if the investigation is still ongoing.

Is a lost laptop a data breach?

If it holds personal data that is not properly encrypted, it can be. Full-disk encryption and remote wipe reduce the risk and may change the assessment.

Who should submit the notification?

Normally the data protection officer, after the incident lead and management approve. Your legal adviser should review the wording.

Do we need to notify if we are only the processor?

The regulations place breach duties on both controllers and processors. A processor, such as a software or hosting provider, should also inform its client, the controller, immediately so the client can meet its own deadline. Confirm your exact obligations with a specialist.

Want to know if your systems would give you the answers you need within 72 hours? Book a free review of your logging, access control and backups through our contact page.

This article is general information, not legal or tax advice. Confirm the details that apply to your company with a specialist.