NIS2 in Kubernetes operations: the evidence an auditor wants to see
NIS2 doesn’t require any particular technology, but measures and proof. For Kubernetes operations, that means personal access, a complete log and tested backups.
The NIS2 directive has shifted the question customers and auditors ask SaaS vendors. It used to be: do you have a security concept? Today it is: show me that it is actually practiced. For Kubernetes operations, that is good news, because almost everything an auditor wants to see can be proven from operations themselves – if they are set up properly.
This post is not legal advice. Whether your company itself falls under NIS2 depends on sector and size; clarify that with your legal counsel. But even companies that don’t fall under it get the questions – from customers who have to audit their supply chain.
What does Art. 21 of the NIS2 Directive require?
Article 21 of the directive lists measures an affected company must take. For running applications on Kubernetes, seven of them are tangible:
- Access control and management of permissions
- Multi-factor authentication
- Cryptography and encryption
- Business continuity: backups and recovery
- Handling of security incidents
- Security in maintenance, including vulnerability handling
- Supply chain security
The rest, such as risk analysis, training and personnel security, are organizational. They cannot be proven from a cluster.
Which questions does an auditor ask, and which evidence answers them?
Auditor’s question | Weak evidence | Strong evidence |
|---|---|---|
Who has access to production? | A list in the wiki | User list with roles, straight from the system itself |
Is multi-factor authentication mandatory? | A policy | Signing in without a second factor is technically impossible |
Who changed what on March 12? | Git history, provided everything was in Git | Log of every change with person and time |
Do your backups work? | A cron job | Record of a restore from this quarter |
How are secrets protected? | Kubernetes Secrets | Encrypted, not readable, access logged |
How up to date is the platform? | We update regularly | Current versions and dates of the last upgrades |
How do you notice incidents? | Customers get in touch | Alerts with timestamp and recipient |
Which gaps do auditors find most often?
The shared kubeconfig. One admin token, three colleagues, one CI pipeline. Nobody can say who made a change, and when a colleague leaves, the token would have to be rotated – which nobody does. An auditor spots this in five minutes.
Backups without a restore. A backup that has never been restored is a hope. The evidence an auditor wants to see is a dated restore, ideally into a copy alongside the running database.
Secrets that are merely encoded. A Kubernetes Secret is Base64, not encryption. Anyone allowed to read secrets in the namespace can read every password. Why that is and how to do better is explained in Kubernetes Secrets: why Base64 is not encryption.
Updates by gut feeling. A Kubernetes version past its end of support is a vulnerability waiting to happen. One upgrade per quarter is easier to prove and easier to carry out than one every two years.
Reporting obligations need timestamps
For significant incidents, NIS2 requires an early warning within 24 hours and a notification within 72 hours. Both assume you know when an incident began. An alert with a timestamp, a log of the changes leading up to it and the logs of the affected application are the basis of every report. If you only learn of an outage from customer calls, you start the clock already behind. Logs & monitoring shows how logs and availability become visible without your own monitoring stack.
An evidence package for Kubernetes operations
What has proven itself is a folder generated from operations every quarter, instead of one scraped together before the audit:
- User list with roles and multi-factor sign-in status
- Log of the quarter’s changes, filtered to production
- Proof of a restore: which backup, where to, when, by whom
- Current versions of Kubernetes and add-ons with the date of the last upgrade
- List of alert channels and the quarter’s alerts
- Data location and the list of service providers
The supply chain: your customers’ questions
Even if your company itself doesn’t fall under NIS2: your customers audit their service providers, and a SaaS vendor is exactly that. The questionnaires are very similar:
- Where is our data processed, and which subprocessors are involved?
- How quickly will you inform us about a security incident that affects us?
- How is your employees’ access to our data controlled and logged?
- How often do you back up, and when did you last test a restore?
- How quickly do you apply security updates?
If you have the evidence from the previous section, you answer these questions with attachments instead of declarations of intent. That noticeably shortens contract negotiations, especially with larger customers.
A quarter of evidence in practice
This is what the routine looks like once it is established. At the end of every quarter, one hour of work:
- Export the user list and compare it with the HR list: has anyone left the team and still has access?
- Filter the quarter’s audit log for production and file it.
- Restore a database from a backup into a copy, check it briefly, document it, delete the copy.
- Note the current versions of Kubernetes and add-ons, and schedule any upgrades that are due.
- Review the quarter’s alerts: were there incidents, and were they handled?
This quarter’s folder is the answer to the next customer question and the start of the next audit.
What doesn’t come from the cluster
To be honest: well-run Kubernetes operations cover only part of NIS2. Risk analysis, security policies, training, the procedure for reporting to authorities and the assessment of your own service providers are organizational work. And the security of your own code, from dependencies to input validation, lies with development. Operations deliver the evidence for their part, not for everything.
How Clusterward covers this
Clusterward enforces the technical parts and records them: personal accounts with mandatory multi-factor authentication, roles per area and application, an audit log with the person or API token behind every change, encrypted secrets that are no longer displayed once saved, backups with restore alongside the running database, and alerts to your channels. Exporting the configuration together with the past year’s audit log produces a single file. The mapping to the Art. 21 measures is under Audit & NIS2, roles and sign-in under Security & access, backups under Backups & recovery.
Conclusion
NIS2 doesn’t check whether you know Kubernetes, but whether you can prove who is allowed to do what, who did what, and how data comes back. Build operations so that this evidence is produced along the way: personal access, a log, tested restores, regular updates. Then the audit is an export, not a project.
Your checklist for Kubernetes operations? Send us your auditor’s or customer’s questions. We’ll show you which of them operations with Clusterward can answer. Ask a question →
Sources and further reading
Frequently asked questions
- Of the measures in Article 21, seven are tangible for operations: access control and management of permissions, multi-factor authentication, cryptography, backups and recovery, handling of security incidents, security in maintenance including vulnerability handling, and supply chain security. Risk analysis, training and personnel security are organizational.