Met is not evidenced
The normal case in container environments is not a missing control. It is a control that works but cannot be evidenced. That difference decides the audit.
„Our backups run every night and report success."
Evidence: screenshot of the dashboard, state unknown
„Restored on 14 March, 3 h 12 min, two deviations recorded."
Evidence: restore record with date, scope, duration, owner
Audits fail on documentation, not on technology
In most container environments we see, the controls in §30 (2) BSIG are already largely met. Access runs through a central identity system, images come from an own registry, backups run at night.
The auditor does not ask whether that is the case. They ask what proves it.
Then the busywork starts. Screenshots, spreadsheets, input from four teams, a state that is stale by the time it is collected. It ties up for weeks exactly the people who should be running the platform, and next year it starts again.
What declarative infrastructure changes
A declaratively operated platform inverts the relationship: evidence emerges as a by-product of operations, not as a project before the audit.
The target state is code
What should apply lives in Git, not in a policy document describing what should apply. That difference decides whether a control can be audited at all.
The change history writes itself
Every change goes through a pull request with four-eyes review. A complete change record exists without anyone maintaining one.
Deviation is measured
Drift between the Git target and the cluster state is a metric with a time series, not a claim in an annual report. Effectiveness is evidenced continuously instead of sampled once a year.
The question every intro call starts with
When did you last actually perform a restore?
Not: when did the last backup complete successfully. But: when did you last restore from that backup, measure the duration, record the deviations and sign the report?
A backup success message is not evidence of recoverability. It proves that a write operation completed, not that your operations come back up.
The criterion is binary, it is verifiable within hours, and hardly anyone can meet it. We make it an acceptance criterion of our work.
Three steps, each one bookable on its own
1. Platform compliance assessment
2–3 weeks · 8–12 person-daysA current-state review across all ten measure areas. You receive:
- ▸Control matrix — every requirement in §30 (2) against the actual state of your clusters
- ▸Evidence register — for every control that is met, where the proof actually lives. The part nobody writes internally.
- ▸Prioritised action plan — by risk and effort, not by completeness
- ▸Two-page management summary — for the board and internal audit, without Kubernetes vocabulary
2. Implementation contract „evidenced platform"
3–6 months · modules of 15–25 person-daysWe implement the action plan. Every module has an acceptance criterion you either pass or fail. No status reports.
3. Operations and continuous evidence
12 months · monthlyThe core of this is the quarterly evidence report: compliance rate per control with history, drift and mean time to correction, ageing of open findings, number of manual interventions on the cluster.
You are not buying operations here. You are buying the report you would otherwise compile yourself every quarter. Operations is the precondition for it.
The five areas with the highest technical share
§30 (2) BSIG lists ten measure areas. Five of them are decided at the platform layer — that is where we work, and where the evidence an auditor accepts is produced.
Area 3 · Continuity
What we implement: Backups to a separate target with immutable retention, full cluster rebuild from Git, RTO and RPO on the workload instead of in a spreadsheet
What you can produce afterwards: Restore record with date, scope, measured duration and deviations
Area 4 · Supply chain
What we implement: Own registry, registry allowlist enforced by admission policy, image signatures verified at admission, SBOM per artifact
What you can produce afterwards: Policy report with share of verified images, SBOM archive, dependency inventory
Area 5 · Vulnerabilities
What we implement: Scanning in the pipeline and continuously in the registry, admission rule per severity, documented and time-boxed exception process
What you can produce afterwards: Vulnerability dashboard with ageing of open findings, time series of patch duration
Area 8 · Cryptography
What we implement: mTLS inside the cluster, automated certificate management with expiry monitoring, no plaintext secrets in Git, logged key rotation
What you can produce afterwards: Certificate inventory with lifetimes, rotation records
Area 9 · Access control
What we implement: Access exclusively via OIDC, RBAC bound to groups rather than individuals and fully in Git, break-glass with alerting, effective offboarding
What you can produce afterwards: RBAC state as a versioned file with history, evidence that offboarding takes effect
What we explicitly do not do
This list is here because it is in every contract we sign. We would rather cut the scope up front than in a dispute.
- ✕Building or running an information security management system
- ✕Guidance towards ISO 27001 certification
- ✕Risk register, assessment methodology, information security policy
- ✕Legal advice, applicability assessment, questions of interpretation
- ✕Incident reporting towards the BSI, crisis team, external communication
- ✕Awareness and training programmes including management training
- ✕Supplier assessment, contract clauses, review of subcontractors
- ✕Voice, video and emergency communication across the organisation
- ✕HR processes and background screening
If you need someone for that: we work alongside ISMS consultancies and auditors and take on the technical part of their project. Tell us who owns it on your side. We agree the interface up front, not during delivery.
Is this a fit?
- ✓You run container or cloud workloads in production, not on a roadmap
- ✓Your company has 200 to 2,000 employees and no dedicated compliance function for the platform layer
- ✓You operate in energy, software and SaaS, health IT or logistics
- ✓Your information security officer carries the pressure and needs someone for the technical side
- ✕You still need to establish whether §30 BSIG applies to you. That is a legal question, not a technical one.
- ✕You want to build an ISMS. Then you need an ISMS consultancy first, and possibly us afterwards.
- ✕You are a cloud provider, data centre service provider or managed service provider. For those categories, EU Implementing Regulation 2024/2690 takes precedence under §30 (4) BSIG, with its own catalogue.
- ✕You operate a critical installation. Additional obligations apply, which is a different project.
Who does this
Two partners, around twenty production clusters. Kubernetes and GitOps from operations, not from a deck. Whoever writes the proposal does the work — no handover to a junior team after signature.
Our debugging and pattern articles are open in the blog. Read two of them before you contact us. It is the most honest proof of competence we can offer.
For ISMS consultancies, auditors and system integrators
If you own the management system and hit the platform layer in a project: we take the technical part and do not touch yours. The list above is our business model, not politeness.
How we work: joint presence at the client, both names on the table, clearly cut scope in the contract. We do not do pure white label.
What decision makers and security officers ask first
What does §30 BSIG require technically from a Kubernetes environment? +
§30 (2) BSIG lists ten measure areas, from risk analysis through backup and supply chain to access control and multi-factor authentication. The text is technology-neutral. In a container environment the deciding question is therefore not the list but which artifact evidences a control: a policy report, a restore record, an RBAC history.
Is our ISO 27001 certificate enough? +
An existing management system is widely considered to cover large parts of the organisational requirements. It says little about whether the controls in your clusters are technically effective and whether you can evidence that per control. That is the gap we close. Whether the certificate suffices in your case is for your information security officer or legal counsel to judge.
What is the difference between a control being met and being evidenced? +
Met means the control works. Evidenced means you can show an auditor what proves it, with a state, a generation timestamp and a history. In container environments the second part is almost always the problem. A screenshot is a snapshot; a policy report with a time series is evidence.
What is a logged restore test? +
An actual restore from backup, with measured duration, recorded deviations and a named owner. Backup success messages only prove that a write operation completed. Auditors ask for it because the criterion is binary: either there is a record with a date, or there is not.
Does this apply to cloud providers and managed service providers? +
For certain digital providers, among them cloud computing services, data centre services and managed service providers, EU Implementing Regulation 2024/2690 takes precedence under §30 (4) BSIG, with a considerably more detailed catalogue. If you fall into those categories we tell you in the intro call, before writing a proposal.
How long does an assessment take and what do you need from us? +
Two to three weeks from access to clusters and repositories, eight to twelve person-days of effort. On your side it takes one contact from the platform team, two meetings and read access. The result is the control matrix, the evidence register and a prioritised action plan.
Does a technical implementation partner replace the information security officer? +
No, and that is not a courtesy. Risk register, assessment methodology, policy, reporting process and management review stay with them. We deliver the technical implementation at the platform layer and the artifacts they use to populate their evidence.