Algeria's Law 25-11: Five days to report a data breach. Would you even know one had happened?
Imagine it is Friday evening. Your company's website is working as usual, customers are placing orders, and no one is worried. Yet for three weeks, someone has been quietly copying your customer database: names, phone numbers, addresses and purchase histories. Nobody has noticed. No alert, no ransom note, nothing.
Now ask yourself the question Algeria's data-protection law has raised since July 2025: when would you find out that a data breach had occurred, and who would notify the authority within the required timeframe?
This is no longer a hypothetical concern. According to estimates cited by Kaspersky, Algeria faced more than 70 million cyberattacks in 2024. And since Law 25-11, an organization that processes personal data can no longer simply hope that everything is fine.
What changed, in two minutes
Law No. 25-11 of 24 July 2025 amends and supplements Law 18-07 of 10 June 2018, which governs the processing of personal data. Here are the key points:
- A data protection officer (DPO) is mandatory for data controllers and the relevant public authorities. The ANPDP has already issued an initial deliberation setting out the conditions for appointing a DPO and the officer's duties.
- Personal data breaches must be notified to the ANPDP within five days.
- Impact assessments are required for high-risk processing.
- New concepts have been added to the law, including biometric data, profiling, pseudonymization and data breaches.
- Transfers of data outside Algeria are subject to safeguards.
Law 18-07 had already established another principle: personal data processing is subject to a prior declaration to the ANPDP or, depending on the case, its authorization.
Data breaches: what counts and who is covered
Many business leaders picture a data breach as a spectacular hack. In practice, the scope is wider: any incident that exposes, destroys, alters or makes personal data inaccessible without authorization may raise the question of notification. “Personal data breach” is now among the definitions in the law; refer to the legal text for its exact wording.
Common examples include:
- a customer file accidentally sent to the wrong recipient;
- a lost or stolen work laptop or phone that was not encrypted;
- ransomware encrypting a database containing customer or employee data;
- a database accidentally exposed to the internet;
- a former employee retaining access and copying files.
Who is covered? Law 18-07 governs the processing of personal data by both public and private organizations. If you hold information about individuals (customers, patients, students, employees, applicants or subscribers), you are very likely within its scope. Data related to national defence and security is subject to a specific regime.
The real challenge is not notifying. It is detecting.
An organization can only report what it knows about. And knowing requires having the means to see what is happening before an incident occurs.
If you lead an organization, ask your teams these three straightforward questions this week:
- Who gets alerted when something unusual happens on our systems, even at 3 a.m. on a Saturday?
- Who decides whether an incident involves personal data, and according to what criteria?
- Who prepares and sends the notification, with what information and within what timeframe?
If the answers are unclear, five days can pass very quickly. The precise start of the deadline and the information required in a notification should be confirmed with your legal counsel, but your internal procedure needs to anticipate them.
For IT leaders: translating the law into technical requirements
| Requirement | In plain language | What it means for your information system |
|---|---|---|
| Breach notification (five days) | Promptly notify the ANPDP with the facts | Centralized logging (web servers, applications, databases, VPN, directory services), sufficient retention, alerts for unusual activity (bulk exports, off-hours logins, privilege escalation), and a documented, tested incident-response procedure |
| Data protection officer | A competent and independent point of contact | An up-to-date processing register and a map of databases and data flows that the DPO can rely on |
| Impact assessment | Evaluate risk before launching a project | Architecture reviews and penetration tests before sensitive projects (biometrics, profiling, large volumes of data) |
| Security measures (Law 18-07) | Protect against theft and unauthorized access | Encryption in transit and at rest, multi-factor authentication, least privilege, patch management, isolated and tested backups |
| Transfers outside Algeria | Know where your data goes | An inventory of SaaS and cloud services (email, CRM, email marketing, analytics, hosting), a review of processor contracts, and an assessment of local hosting options |
One organizational point matters too: the ANPDP stresses the DPO's independence and says the officer should not be given duties that conflict with data protection. Appointing the IT director as DPO means asking them to oversee systems they administer themselves. This deserves careful consideration.
Weaknesses that can turn an incident into a data breach
In web, API and network audits, the same types of weaknesses appear repeatedly. Any one of them may be enough to trigger a notification obligation:
- Outdated CMS platforms and plugins (WordPress in particular): a vulnerable plugin can expose the database.
- APIs without rigorous access controls: by changing an identifier in a request, one user may be able to read another customer's data. Without logging, nobody may notice.
- Forgotten backups and exports on a web server (`.sql`, `.zip` files): downloadable by anyone who knows the address.
- Administration interfaces exposed to the internet, such as admin panels and database management tools.
- Administrator accounts without multi-factor authentication, with passwords reused elsewhere.
- Secrets in code or repositories, such as API keys and database passwords.
- Insufficiently hardened Active Directory: starting from a single compromised account, an attacker may reach domain administrator privileges and therefore access all data.
The common thread: in many of these cases, the organization only finds out when someone else tells them.
Practical detection: what to log and what to monitor
For an IT leader, detection comes down to two things: collecting the right logs and knowing which anomalies should trigger an alert.
| Source | What to collect | Signals to alert on |
|---|---|---|
| Web server / reverse proxy | HTTP requests, response codes, IP addresses, user agents | Spikes in 401, 403, 404 or 500 errors; URL enumeration; downloads of sensitive files (`.sql`, `.zip`, `.bak`); injection patterns in requests |
| Application and API | Authentication events, access to resources by identifier, authorization errors | One account reading hundreds of different identifiers; access to another user's resources; bulk exports |
| Database | Connections, administrative queries, read volumes | A connection from an unusual machine; unusually large read queries; account creation |
| Active Directory | Authentication events, group changes, privileged accounts | An account added to administrative groups; bursts of failed logins; logins outside normal hours |
| VPN and remote access | Connections, geographic origin, duration | An unusual country; two geographically incompatible sessions; access at unusual times |
| Forwarding rules, connections, sending volumes | A new automatic forwarding rule to an external address; mass email with attachments; suspicious logins | |
| Backups | Job logs, deletions | Backups deleted or changed; repeated failures; the service being stopped |
Three practical rules:
- Centralize logs away from the systems being monitored. An attacker who takes control of a server may first erase its local logs. Open-source tools such as Wazuh, Graylog or the ELK Stack can centralize them without expensive licensing.
- Synchronize system clocks using NTP. Otherwise, reconstructing an incident timeline becomes a headache.
- Start small. Five or six alerts that are actually handled are better than two hundred that everyone ignores. Every alert needs an owner and an associated action.
An example five-day response timeline
This is a procedure outline to adapt to your organization. Confirm the exact start of the deadline and the required notification details with your legal counsel and the ANPDP.
- Hour 0: detect and assess. An alert comes in. Is the incident confirmed? Is personal data involved? Open an incident log immediately: who did what, and when?
- First few hours: contain. Isolate affected machines and accounts, and revoke compromised access and secrets. Do not shut down or erase potential evidence: preserve logs and, if possible, a copy of the affected systems.
- Day 1: notify the right people internally. Inform management, the DPO and legal counsel. Appoint a single incident lead.
- Days 1 and 2: assess the impact. What data is involved, how many people, and what level of sensitivity (identity, health, biometric or financial data)? Is exposure confirmed or only likely? A data map created in advance saves valuable time here.
- Days 2 to 4: prepare the notification. In general, this includes the nature of the breach; categories of data and people affected; likely consequences; measures taken; and the DPO's contact details. Also assess whether affected people should be informed.
- Before the deadline: notify the ANPDP and keep proof that it was sent.
- Afterwards: remediate and document. Identify the root cause, apply fixes, capture lessons learned and update the procedure.
What about the public sector?
Presidential Decree No. 26-07 of 7 January 2026, published in the Official Gazette on 21 January, defines the organization and operation of cybersecurity units within public institutions, administrations and bodies. Each institution is to have a dedicated unit, reporting directly to its head, to coordinate cybersecurity and data-protection actions.
Businesses working with the public sector should reasonably expect these units to look for demonstrable security practices from their service providers.
Questions business leaders often ask
“We are a small organization. Does this apply to us?” The presence of personal data, not the size of the organization, is what brings processing within the law. An online shop, professional practice, clinic or school that keeps customer, patient, student or employee data is covered.
“Our website is hosted abroad, or we use foreign cloud services. Is that a problem?” Not necessarily, but the law regulates transfers of data outside Algeria. Start by finding out which data goes where: email, CRM, email marketing, analytics and hosting. Then check the applicable requirements with the ANPDP or legal counsel.
“A provider manages our website. Who is responsible if there is a breach?” In principle, the data controller remains responsible for protecting personal data, even when technical work is outsourced. Use a contract that covers security measures, incident-notification timelines and audit rights.
“Are antivirus software and a firewall enough?” No. They block some attacks, but do not tell you what happened when one gets through. The law makes detection and response just as important as prevention.
“Where should we start with a small budget?” Three actions address a large share of common scenarios: enable multi-factor authentication for email and administrator accounts; keep tested offline backups; and centralize logs from your website and access systems.
Checklist: what to do in the next 30 days
- Appoint a data protection officer, formalize the role and submit the officer's contact details to the ANPDP.
- Map your data: what personal data you hold, where it is stored, who can access it, and which cloud and SaaS tools you use.
- Enable and centralize logs from exposed systems (website, API, database, VPN, directory services) and define a few simple, useful alerts.
- Write an incident-response procedure: who does what and in what order, with a notification template ready. Then run a one-hour tabletop exercise.
- Secure the basics: multi-factor authentication for email and administrator accounts, current security patches, and tested offline backups.
- Have exposed systems assessed: a web and API penetration test shows what an attacker could actually see before they find it themselves.
In conclusion
Law 25-11 does not demand perfection. It demands control: knowing what data you hold, where it is, who can access it, and being able to tell when something goes wrong.
At Yamoa Solutions, we conduct technical audits (web, mobile application, API and network penetration tests, Active Directory reviews and forensic analysis) as well as organizational assessments (risk analysis, business continuity and disaster recovery planning, ISO 27001). Contact us to assess your technical exposure and incident-detection capabilities.
This article is for informational purposes only and is not legal advice. Refer to the official texts published in the Official Gazette and, if needed, consult legal counsel.