The Blind Spot in ISO 27001: The Myth of GitOps as Your Backup

When companies embark on their journey toward ISO 27001 certification, focus quickly shifts to access matrices, encryption, and physical office security. But once the auditor sits down with the DevOps team and starts digging into control A.8.13 (Information Backup), an uncomfortable silence often fills the room – or a defensive argument arises claiming that everything is "stateless" and doesn't require backups.

Especially if you are running Kubernetes and relying on a modern GitOps workflow.

It is easy to be lulled into a false sense of security. You have all your infrastructure as code (IaC) in GitHub or GitLab. You think: ”Our apps are stateless, so if a cluster crashes, we'll just trigger our pipeline and rebuild everything in ten minutes.”

But here is the catch: Rebuilding from code is not the same as restoring the live state. And an ISO 27001 auditor will see right through that myth.

Why Even "Stateless" Requires Backup to Prove the Live State

Many developers argue that a stateless container (an application without an attached database or persistent storage) does not need to be backed up. But is your app running in Kubernetes truly stateless? Does it really not handle data in any way, even if the data resides outside of Kubernetes?

Ignoring this is a mistake that can cost you your certification.

💡 Technical Statement for ISO 27001 in Kubernetes: Just because an application is stateless does not mean the app functionality is. To satisfy ISO 27001 requirements for system integrity and traceability, backing up stateless containers and cluster metadata is an absolute mandatory requirement. Without a snapshot backup of the cluster's exact live state (including ConfigMaps, Secrets, certificates, and runtime changes), an organization cannot document or verify the precise environment at the time of a security incident. GitOps shows how the environment should look, but a backup proves how the environment actually looks right now.

Even if your containers are technically stateless, the exact live state of a container and the cluster changes constantly in real time due to three core factors:

• Dynamic Configurations: ConfigMaps, Secrets, certificates, and network policies are created, scaled, and updated live inside the cluster. What lives in your Git repository rarely mirrors the exact environment variables or certificates running at this very second.

• The GitOps Drift/Gap: If an urgent hotfix or troubleshooting change is made directly in the cluster (kubectl apply) before being pushed to Git, that live cluster configuration becomes your actual state.

• Traceability and Replication: Without a snapshot backup of the app metadata and stateless configurations, you cannot prove to an auditor exactly which version or configuration was running during a potential security incident.

In short: For ISO 27001, having the blueprint (the code in Git) is not enough. You must have an exact copy of the finished house (the live state in Kubernetes).

What Does an ISO-Approved Kubernetes Backup Look Like?

When an auditor reviews your environment, they want to see proof of recoverability for the entire system, not just the databases. Your strategy must include three core pillars:

• Complete Protection (Git to Pod): The backup must encompass the source code in Git, your Kubernetes manifests (YAML), environment configurations for your stateless apps, and all persistent data – including resources residing outside of Kubernetes.

• Independent State Capture: Backup data must be saved regularly and completely independent of the production environment, allowing you to restore the cluster's exact state even if your primary cloud region suffers from ransomware or a total power outage.

• Automated Restoration Tests: Living with "Schrödinger's backup"—where the status of your backup is unknown until you actually try to restore it—won't cut it for a certification. You must prove that recovering both stateless and stateful resources actually works, and that both RPO (Recovery Point Objective) and RTO (Recovery Time Objective) are measurable, documented, and verifiably meet your targets.

The Solution: IssProtect for DevOps

At IssTech, we have taken our decade-long data protection expertise and brought it into the modern container era. We know that developers and DevOps teams don't want clunky, external systems slowing them down. It has to happen on your terms.

With IssProtect for DevOps, we seamlessly secure your entire development pipeline:

• Captures the Entire Live State: We take continuous backups of your Git repositories, your CI/CD pipelines, and all resources within Kubernetes, as well as dependent data sources outside the cluster – whether they are stateful databases or stateless containers and their hidden configurations.

• Platform and Cloud Mobility: Should a disaster strike, you can easily restore from one Kubernetes provider to another, or move your application from the public cloud to a secure, sovereign data center.

• Pipeline Automation: Developers can manage backup requirements directly via tags within their projects, while the system automatically scans for ransomware and deduplicates data to secure S3 storage.

Stop playing Russian roulette with your pipelines and don't blindly assume GitOps solves everything ahead of your ISO audit. Let us show you how to secure your entire DevOps chain and turn backups into a strategic advantage rather than an administrative burden.

Want to see how it works in practice? Book a demo of IssProtect for DevOps today, and we can set up a PoC in your own environment in just a few hours.