Decree 2018-062 and Kubernetes: The Gap Between the Text and the Implementation

A compute platform that hosts Togolese data has to satisfy a precise body of law: law 2017-007 on electronic transactions, its implementing Decree 2018-062, law 2019-014 on the protection of personal data, and the cybersecurity rules of the 2022-040 order issued by the ANCY. The problem is not that these texts are lax. The problem is that they were written with one image in mind: a physical server in a datacenter, or at best a virtual machine with an address, a disk, a location. Kubernetes does not work that way. A pod is born, dies and is reborn elsewhere in seconds. A volume is provisioned on demand by a CSI driver and can change zone. An "Operator" is not a company, it is a piece of code that reconciles a desired state.

This article looks that mismatch in the face. For each relevant obligation I look for its native Kubernetes equivalent, then I isolate the places where the equivalence breaks. The angle is legal-technical, not a how-to: the intended reader is as much a data protection lawyer as a platform engineer. One useful caveat up front: this is an engineering analysis, not legal advice. And a second, subtler one: Decree 2018-062 primarily targets trust service providers (signature, certification, timestamping, electronic archiving). I take an extensive reading here, treating its obligations as a reasonable baseline for any platform that hosts and processes data, while flagging each time where that extension is an interpretation and not the letter of the text.

A text written for the server, not for the pod

The mental-model mismatch has to be named precisely, because it is what creates every gap that follows.

The law reasons in terms of stable, locatable entities. A provider is "established on the national territory" (Decree 2018-062, art. 58). Data is "retained" for a duration. A provider has a "wind-down plan" (art. 58). All these notions implicitly assume there is a place, a server, an asset you can point at and audit.

Kubernetes dissolves those anchors. The pod is ephemeral by design: the scheduler places it on a node according to the capacity available at time t, kills it when a liveness probe fails, and recreates one elsewhere. The IP address changes at every restart. Storage splits in two: the ephemeral kind, which vanishes with the pod, and the persistent kind, which lives in a PersistentVolume whose physical location depends on the provisioner. Responsibility spreads across the application team, the platform team, and the managed cluster provider. There is no longer a server: there is a desired state and a reconciliation loop.

The text did not anticipate this abstraction. That is not a reproach to the lawmaker of 2018, it is an observation: compliance is no longer a matter of ticking "the server is in Togo", it is a matter of rebuilding, on top of a shifting infrastructure, the guarantees the text assumed were granted by the stability of the hardware.

The real obligations, article by article

Before mapping anything, we have to be exact about what the texts actually say, because several common intuitions are wrong.

Traceability and logging. Article 41 of Decree 2018-062 requires providers to retain, "for at least a duration of one year", the data that identifies who contributed to a content. The text explicitly names "the IP address of remote connection points" and "the timestamped trace of sessions opened for each service used". The 2022-040 order reinforces this for operators of essential services with a control dedicated to event logging (D1.1.1).

Security. Article 44 of the decree requires protecting transmitted data "against any unauthorized access". Article 52 goes further: "adequate technical and organizational measures to manage risks", at a level "proportionate to the degree of risk", with notification of any security incident "within twenty-four hours" to the supervisory body and, where relevant, to the data protection authority. This is an obligation of proportionate means, not a frozen checklist of technical controls.

Personal data protection. Article 50 of the decree explicitly defers to law 2019-014: the storage and processing of personal data is carried out "in compliance with the protection of personal data". Law 2019-014 defines the data controller, the processor, and the Personal Data Protection Authority (the Instance) that supervises. Its article 20 requires the processor to offer "sufficient guarantees", to be bound by a written contract, and to act "only on the instruction of the data controller". Its article 19 states the principle of confidentiality and security.

Continuity. Article 58 of the decree requires the relevant records to be "accessible for a duration of twelve months ... for the purpose notably of ... ensuring the continuity of the service", and that the provider hold "an up-to-date wind-down plan ensuring the continuity of the service and verified by the supervisory body". The 2022-040 order makes it a whole domain, business continuity and resilience (R1).

Integrity and reversibility. Article 69 of the decree, on archiving, requires preventing "any modification of the retained data", "detecting operations, normal or fraudulent", and "allowing the identification of the authors of such operations", all timestamped and accessible only to authorized persons. Article 71 mandates reversibility: on request, return, transfer to another provider, or definitively destroy the data.

Localization. This is where intuition is most misleading. Decree 2018-062 does not impose data residence on Togolese soil. It anchors the provider's establishment "on the national territory" (art. 58) and the territorial control of the regulator. The real localization constraint comes from elsewhere: article 28 of law 2019-014 frames the transfer of personal data "to a third country", which is permitted only if that State "ensures a sufficient level of protection" and after prior notice to the Instance, which issues a reasoned opinion. So the question is not "is the data in Togo", it is "does the data cross a border into an inadequate country, and did I declare it".

Encryption at rest. None of these texts writes "encryption of data at rest" in black and white. The decree speaks of protecting "against any unauthorized access" (art. 44) and of measures "proportionate to the risk" (art. 52). The 2022-040 order has a control on the regulation of cryptographic controls (G3.1.5), but phrased by reference: cryptographic controls "must be used in accordance with the relevant laws and regulations". Encryption at rest is therefore an implicit requirement, deduced from the security obligation, never a literal prescription.

The mapping: each obligation and its Kubernetes equivalent

For a good part of these obligations, Kubernetes offers a native answer. That is important to establish before talking about gaps, because the platform is not in compliance bankruptcy: it naturally covers several requirements.

On paper the coverage is decent. Audit logs answer the need for a trace, PodDisruptionBudget and anti-affinity answer the need for continuity, RBAC and NetworkPolicy materialize proportionate security. A platform engineer can legitimately say "Kubernetes can do all of that". The trap is that this coverage is true at the infrastructure level and false at the data level. That is exactly where the gaps live.

The real gaps

A gap, here, is not a missing Kubernetes feature. It is a place where the tool's native answer does not cover the legal obligation, because the two do not talk about the same object. The text talks about identified and located data; Kubernetes answers at the level of resources and APIs. Here are the four mismatches that matter.

Data residence versus ephemeral storage and dynamic volumes

Article 28 of law 2019-014 makes the legality of a transfer depend on the geographic destination of the data. Yet Kubernetes is designed to make that destination fluid.

A PersistentVolume is provisioned by a StorageClass, itself backed by a CSI driver that talks to the real storage backend. In a managed cluster at a hyperscaler, that backend is a regional service: the volume lives in a zone, and depending on configuration, the replication of that service can copy the blocks to another region for durability. Nothing in the application manifest makes this geography visible. A developer who writes storageClassName: standard does not know, and has no reason to know, in which country their bytes physically land.

Ephemeral storage makes the blur worse. Temporary files, caches, emptyDir volumes live on the disk of the node hosting the pod at that instant. The scheduler picks that node dynamically. If the node pool spans several zones, or even several regions in the most elastic architectures, a piece of personal data can transit through a node located outside the declared perimeter, for the duration of a processing step, without any application trace recording it.

The gap is twofold. First, the text never defined data residence for a system where data has no fixed place: it presumed the stability of the server. Second, even if you read article 28 as applying to these movements, Kubernetes provides no native mechanism that declares, controls and logs a border crossing at the data level. topologySpreadConstraints or nodeAffinity can constrain placement, but those are scheduling tools, not auditable compliance guarantees.

Traceability of access to personal data in multi-tenant clusters

Article 41 of the decree wants the timestamped trace of access, and article 69 wants "the identification of the authors" of operations on the data. The kube-apiserver audit log seems to answer. It only answers halfway.

The API server audit logs actions on Kubernetes objects: who created a pod, modified a Secret, listed the ConfigMaps. It is a trace at the control-plane level. But the legal obligation is about access to personal data, which happens at the application level, inside the container, when the code reads a row in a database or an object in a bucket. That access is invisible to the API audit: Kubernetes does not see the SQL queries your application makes.

Multi-tenancy blurs accountability further. In a shared cluster, isolation goes through namespaces, but several teams, several applications, sometimes several customers coexist. Technical identities, ServiceAccounts, are shared across the replicas of a single deployment: when three pods of the same service access data, they present the same identity. A service mesh that adds sidecars, a connection pooler that funnels database access under a single service identity, and the chain between the human user and the byte read is broken. The trace exists, but it stops at the cluster boundary or at the service identity, exactly where the lawyer expects the identification of an author.

The gap: Kubernetes native traceability is an infrastructure traceability. The traceability required by articles 41 and 69 is a data traceability. Closing the gap requires application instrumentation that the platform does not provide on its own.

Legal "operator" versus Kubernetes Operator

The word "operator" is a perfect false friend, and the collision is more than a vocabulary curiosity.

In the legal sense, the operator or provider is a person, natural or legal, who carries obligations and liability. Article 47 of the decree makes the provider "liable for damages caused intentionally or by negligence", and even presumes that liability for a qualified provider. Law 2019-014 distinguishes the data controller, who decides, from the processor, who executes on instruction (art. 20). These are accountable roles.

In the Kubernetes sense, an Operator is a software pattern: a controller paired with one or more CustomResourceDefinition, which watches the cluster state and reconciles it toward a desired state. A database Operator can, on its own initiative, decide to fail over, restore a backup, delete and recreate a volume, move a workload from one node to another. In other words, code makes decisions that touch personal data, without human intervention, on the basis of a reconciliation loop.

The gap is an accountability void. When an Operator triggers a restore that overwrites data, or a rebalancing that moves a volume to an unplanned zone, who is the responsible party in the sense of article 47? The Operator's vendor? The team that deployed it? The organization that runs the cluster? The law assumes a chain of responsibility between persons; Kubernetes inserts an autonomous agent into that chain, and the text has no slot for it. This is not a problem you solve with a manifest: it is a governance problem that has to be made explicit by contract and by documentation.

Encryption at rest: etcd, Secrets and volumes

The obligation to protect data "against any unauthorized access" (art. 44) collides with a well-known Kubernetes default.

Three surfaces deserve attention. First etcd, the key-value store that holds all the cluster state, including Secrets. By default, depending on the distribution, etcd can store this data without application-level encryption: anyone who accesses the disk or a backup of etcd reads the Secrets in clear. Second, Kubernetes Secrets themselves, whose name is misleading: a Secret is not encrypted, it is base64-encoded, which offers no confidentiality. Third, PersistentVolumes, whose encryption depends entirely on the storage backend and its configuration, not on Kubernetes.

The gap here is double: on the legal side, the encryption-at-rest obligation is implicit, deduced from article 44 and the cryptographic control G3.1.5 of the 2022-040 order, never stated as such; on the tool side, the default behavior does not satisfy that implicit obligation. The meeting of the two ambiguities produces a real risk: an organization can believe its Secrets protected because they are called "Secrets", and find itself in breach of an obligation that no text spelled out explicitly but that any serious auditor will demand.

Implementation patterns to close the gaps

The analysis is only worth something if it leads to answers. Here, gap by gap, are patterns to rebuild on top of Kubernetes the guarantees the text assumed were granted. The goal stays conceptual: these are directions, not deployment recipes.

Anchor data residence. Constrain placement with nodeAffinity and topologySpreadConstraints to keep workloads that process personal data in mapped zones. Choose StorageClasses whose physical geography you know and document, disabling unwanted cross-region replication. Above all, keep a processing register that declares, for each volume and each flow, where data resides and to which countries it may transit, so that article 28 becomes verifiable instead of endured.

Make traceability application-level. Complement the API server audit with data-level logging: the database logs access, the application emits personal-data access events with a real user identity, not just a service identity. Avoid blind identity pooling: propagate the user identity end to end rather than dissolving it into a connection pool. A policy engine like OPA Gatekeeper can enforce that workloads touching sensitive data carry the required labels and instrumentation.

Make Operator responsibility explicit. Treat every autonomous Operator as a link in the chain of responsibility and document it as such: which Operator can act on which data, with which minimal RBAC permissions, under which team's responsibility. Restrict destructive actions, require guardrails for operations that move or erase data, and record these decisions in the governance register. The pattern is not technical, it is organizational: give a human name back to every automatic action.

Encrypt at rest, explicitly. Enable the API server's EncryptionConfiguration to encrypt Secrets in etcd, ideally backed by an external KMS rather than a local key. Treat Kubernetes Secrets as a distribution mechanism, not a protection one, and consider a dedicated secrets manager or sealed secrets. Enable storage-backend encryption for PersistentVolumes. Document these choices to turn an implicit obligation into auditable proof.

Limits of the analysis and open questions

This analysis rests on an extension I have to own clearly. Decree 2018-062 primarily targets trust service providers: electronic signature, certification, timestamping, archiving. Applying its obligations to a generic compute platform is a reasonable reading, but it is an interpretation, not the letter of the text. A lawyer could defend a narrower perimeter, limited to cases where the platform actually delivers a trust service.

Several questions stay open. The exact articulation between the decree, law 2019-014 and the 2022-040 order deserves a cross-reading by a Togolese legal practitioner, notably on whether a platform qualifies as an operator of essential services in the sense of the order. The notion of transfer in article 28, applied to intra-cluster, ephemeral and automatic movements, has not, to my knowledge, been settled: does an emptyDir briefly touching a node in another zone constitute a transfer in the sense of the law? Finally, the responsibility for the autonomous actions of an Operator is a blind spot common to many legal frameworks written before declarative automation, not only to the Togolese one.

The heart of the matter fits in one sentence. These texts are not bad: they are written for a world where infrastructure was stable and locatable. Kubernetes made infrastructure shifting, and compliance now consists of rebuilding, layer by layer, the guarantees that hardware stability used to grant for free. The work is not to circumvent the text, it is to translate it into a model it never anticipated.

Sources

• Decree n°2018-062/PR regulating electronic transactions and services in Togo, ARCEP
• Law n°2017-007 on electronic transactions, numerique.gouv.tg
• Law n°2019-014 of 29 October 2019 on the protection of personal data, Official Journal
• Order n°2022-040/PMRT adopting cybersecurity rules in the Togolese Republic, CERT Togo

This is an engineering analysis, not legal advice. For any compliance decision, consult a Togolese data protection practitioner.