What Decree 25-320 Establishes
On 30 December 2025, Algeria issued Presidential Decree No. 25-320 setting up a national data governance framework. Based on tracking from the Digital Policy Alert register and the CMS Expert Guide chapter on Algeria, the decree defines three pillars:
- Data classification — a structured taxonomy for data held by public administrations, covering sensitivity levels (public, internal, restricted, confidential) and business domains.
- Data cataloguing — every public administration is expected to maintain a catalogue of its data assets, describing them in a way that makes reuse and controlled sharing possible.
- Secure interoperability — public administrations must be able to exchange data with each other over secure, standardised channels, aligned with cybersecurity and personal data protection rules.
This sits alongside existing instruments: Law 18-07 on personal data protection (as amended by Law 25-11), the 2024 cybersecurity law, and the cloud computing regulation that ARPCE enforces. Decree 25-320 is the layer that tells public bodies how to organise their data so the other laws can work on top of it.
This article is an explainer for vendors, integrators, and cloud architects who sell to or build for the Algerian public sector — not a critique of the decree or the administrations implementing it.
Who This Matters To
Even though the decree addresses public administrations directly, the operational impact spreads across the vendor ecosystem:
- SaaS providers that serve ministries, agencies, local authorities, hospitals, or public universities — their platforms must fit the classification and catalogue model.
- System integrators building or upgrading public-sector information systems — tenders will increasingly reference the decree.
- Cloud architects designing landing zones for public clients — their reference architectures should support classified storage, catalogue hooks, and interoperability APIs out of the box.
- Consultancies supporting public-sector digital transformation — data governance maturity assessments become a recurring engagement.
Private-sector companies are not directly bound by Decree 25-320, but those whose products are consumed by public administrations (or that exchange data with them) will effectively inherit its expectations.
Data Classification: The Tagging Layer Every Product Needs
Classification is the foundation. Without it, neither cataloguing nor interoperability can work cleanly. A typical implementation aligned with Decree 25-320 expectations will need:
- A classification scheme with clear criteria for each level (e.g., public data on the administration’s website, internal data used for daily operations, restricted data on citizens, confidential data linked to state security).
- A labelling mechanism at the data layer — tags in the database, metadata in document stores, classification attributes in file headers, or labels in object storage buckets.
- A propagation rule — when data moves between systems, the classification follows. This is where most implementations fail: reports exported to Excel lose their sensitivity label unless the platform enforces it.
For vendors, the design implication is clear: platforms sold to Algerian public clients in 2026 should expose a classification field by default and allow administrators to configure the taxonomy.
Advertisement
Cataloguing: From Spreadsheet to API
A catalogue is more than an inventory. Under the framework, each administration should be able to describe its datasets — who owns them, how they were created, at what frequency they are updated, who can access them, under which conditions they can be shared.
Practical requirements vendors should anticipate:
- Metadata standards — support for common standards (DCAT-AP is a reasonable baseline) to make cross-administration discovery possible.
- Lifecycle events — the catalogue should reflect creation, updates, archiving, and deletion.
- Access controls linked to the classification — catalogue entries must be visible only to the people authorised to see them.
- Machine-readable interfaces — a public catalogue is useful for citizens, a catalogue API is useful for other administrations.
An implementation team preparing for a ministry tender should treat “catalogue API” as a first-class requirement, not an afterthought.
Secure Interoperability: The Real Engineering Work
Interoperability is where architectural discipline pays off. The decree frames exchanges between public administrations as a secure, documented channel — not a CSV emailed between ministries.
A conformant interoperability stack looks like this:
- Authenticated endpoints — mutual TLS between administration systems, with certificates issued under a recognised hierarchy.
- Identity and authorisation — each request is signed by a known administration and scoped to a specific classification level.
- Transport and payload security — encryption in transit is mandatory; encryption at rest should follow the classification level.
- Logging and audit — every exchange is logged with a tamper-evident trail for later audit, consistent with cybersecurity obligations.
- Data protection alignment — when the exchanged data includes personal information, the exchange must respect Law 18-07 / Law 25-11 lawfulness and minimisation principles.
Cloud architects designing landing zones for public clients should bake these controls into the reference design, so that every new workload inherits them without re-arguing security.
A Three-Pillar Compliance Readiness Framework for Vendors
Decree 25-320 creates a predictable readiness sequence for any vendor or cloud architect preparing to compete in the Algerian public sector. The three pillars map directly to the decree’s structure and can be addressed in a single product roadmap cycle.
Pillar 1: Classification — Tag Every Data Object at the Source
The decree’s data classification taxonomy is the prerequisite for everything else. Vendors should implement classification as a first-class attribute in storage, document management, and database layers — not as a post-processing label applied by an administrator after data already exists. The practical design pattern: expose a classification dropdown or API field in every data-creation workflow, enforce propagation so that exports and copies inherit the source label, and log every reclassification event with a timestamp and user identity. The four standard levels (public, internal, restricted, confidential) align with French ANSSI and EU NIS2 frameworks, which means vendors with existing European public-sector deployments can adapt their classification schemas rather than rebuilding from scratch. Document the classification schema in sales collateral: procurement officers under Decree 25-320 will ask whether the product supports the taxonomy before any technical evaluation begins.
Pillar 2: Catalogue — Expose a Machine-Readable Data Asset API
A data catalogue under Decree 25-320 is not a user-facing documentation portal — it is a machine-readable registry that other administrations can query to discover datasets, understand their structure, and request access. The DCAT-AP standard (Data Catalog Vocabulary Application Profile), used across EU public-sector data portals, is the most widely supported baseline and is explicitly referenced in comparable national frameworks. Vendors should implement a DCAT-AP compatible API endpoint in any platform serving public clients, exposing at minimum: dataset identifier, owner administration, domain tags, sensitivity classification, access conditions, and update frequency. For system integrators, the catalogue API becomes a deliverable in every tender — its absence will disqualify a bid once procurement teams operationalize the decree’s expectations, estimated by Digital Policy Alert to begin in earnest in the second half of 2026.
Pillar 3: Interoperability — Implement Mutual TLS and Structured Audit Logging by Default
The secure interoperability layer is where architectural choices made today create either audit-readiness or compliance debt. Cloud landing zones for public clients should implement mutual TLS as a non-negotiable default between all service boundaries — not as an optional module. Each cross-administration exchange should carry a structured log record with: exchange timestamp, sender identity (with certificate reference), recipient identity, data classification level, and payload hash. This logging pattern is required for tamper-evident audit trails under both Decree 25-320 and the broader cybersecurity law, and it is most cheaply implemented at infrastructure design time rather than as a retrofit. Architects familiar with AWS Transit Gateway, Azure Virtual WAN, or on-premises API gateway products will recognize the pattern as standard zero-trust network architecture — the decree mandates what good practice already recommends.
What Comes Next
Decree 25-320 is the framework layer, not the implementation layer. The next 12 months will produce the implementing decrees, ministerial circulars, and ARPCE technical guidelines that translate the three pillars into specific technical and contractual requirements. Vendors and cloud architects who treat this moment as a waiting game will be disadvantaged: the organizations that begin aligning their product roadmaps and reference architectures now will meet the first wave of tenders with documented capability; those that wait for final guidelines will be retro-fitting governance under procurement deadline pressure.
Three developments are worth tracking closely. First, ARPCE’s technical guidance on cloud classification requirements — the regulator has authority over cloud computing in Algeria and is the most likely body to specify exactly which classification levels must be enforced at which storage tier. Second, ANPDP’s position on data catalogue access rights — as the personal data protection authority, ANPDP will determine how catalogue entries covering personal data are scoped, who can query them, and under what legal basis. Third, the extension of the framework to state-owned enterprises and public establishments with commercial mandates — the decree addresses public administrations, but the boundary between a ministry and a state-owned enterprise in Algeria is legally defined; the implementing texts will clarify whether entities like Sonatrach, Algérie Télécom, and the major state banks fall within scope or inherit equivalent obligations through procurement.
Vendors with existing European public-sector deployments compliant with EU NIS2 and the European Data Governance Act will find that the Algerian framework is structurally similar. That similarity is not coincidental — Algeria has historically aligned its digital governance architecture with the French model, and Decree 25-320 reflects that alignment. The practical implication is that vendors already invested in EU public-sector compliance can adapt rather than rebuild.
Frequently Asked Questions
Who does Decree 25-320 apply to?
Decree 25-320 applies to Algerian public administrations — ministries, agencies, public establishments, and local authorities. Private companies are not directly bound, but vendors and integrators working with public clients will see its expectations cascade through tenders and contracts.
How does Decree 25-320 interact with the data protection Law 18-07 / Law 25-11?
Decree 25-320 focuses on how public administrations organise, catalogue, and exchange data. Law 18-07 (as amended by Law 25-11) governs how personal data is processed. When personal data is involved in an inter-administration exchange, both frameworks apply: the exchange must be classified, catalogued, and secure (Decree 25-320) and also lawful, minimised, and rights-respecting (Law 25-11).
What should a cloud architect change in reference designs for Algerian public clients?
Build classification tags as a first-class attribute of storage services, integrate a catalogue API hook in data pipelines, require mutual TLS plus centralised logging for any cross-administration exchange, and align encryption settings with the classification level. Treat these as default controls rather than add-ons.
