A mid-market European insurance SaaS

The company operates a claims-processing and policy-administration platform used by mid-market commercial insurers and managing general agents (MGAs) across the EU. Two years before Stribog was engaged, the platform's engineering team had made a deliberate infrastructure decision unrelated to compliance: they moved off a managed Kubernetes service onto self-operated clusters on Talos Linux, motivated by cost and by a desire to control their own upgrade cadence. That decision turned out to matter more than anyone anticipated — it gave them an immutable, API-driven substrate exactly of the kind auditors like to see. The initial ISO 27001 certification audit, conducted not long after the Talos migration, passed cleanly. What didn't get built alongside the infrastructure was a way to prove, on demand, that the infrastructure stayed the way the certification said it was. The first surveillance audit twelve months later raised two minor observations, both about access review: the auditor asked the team to reproduce the RBAC review evidence from six months earlier, and they couldn't — the original review had been a person running kubectl commands against the live cluster and pasting the output into a spreadsheet, and neither the commands nor the cluster state from that date had been preserved. The second surveillance audit, eighteen months in, raised the same observation again, because nothing had structurally changed — only the spreadsheet's formatting. A minor observation that repeats is treated differently than one that appears once; the certification body's guidance made clear that a third occurrence of the same unaddressed finding would likely escalate to a nonconformity serious enough to put the certificate itself at risk.

The commercial exposure was concrete and near-term. ISO 27001 certification was a named condition in the master service agreements of the company's four largest enterprise accounts — insurers and MGA groups who had written certificate validity into their vendor risk clauses. A suspended or downgraded certificate would not just be an awkward board update; it would trigger a formal vendor risk review at each of those accounts, on contractual remediation timelines the company did not control. The third surveillance audit was now eleven weeks out, and the platform team's own read of the auditor's language from the second cycle was that a repeat occurrence of the same finding would not be waved through as a minor observation again.

A second, quieter drain was compounding underneath the audit-cycle stress: every enterprise prospect in procurement sent a security questionnaire — CAIQ, SIG Lite, or a bespoke spreadsheet modeled on one of the two — asking, in different words, the same question the ISO auditor kept asking: show me that your controls are continuously true, not true on the day someone checked. The company had no dedicated compliance engineer; the VP of Engineering answered these personally, and had done so for eleven questionnaires across the prior two quarters, each taking one to three weeks of his time to research and answer from scratch, because no prior answer was stored anywhere reusable. Two enterprise deals had stalled in procurement specifically waiting on questionnaire responses, and the sales team had quietly started avoiding leading with the platform's Kubernetes posture in early conversations, unsure they could defend the answers under follow-up questioning.

The regulatory backdrop had also shifted since the original certification. DORA's ICT risk-management and incident-reporting obligations now applied directly to the company as a service provider to in-scope (re)insurance undertakings, and GDPR Article 9 exposure was real — a meaningful share of claims data carried health and injury information tied to specific policyholders. The auditor's access-review finding and the DORA/GDPR obligations were, functionally, the same underlying problem wearing different regulatory hats: nobody could show, for a specific date, exactly who could reach exactly what.

The platform team was eight engineers strong, all capable Kubernetes operators, none of them a dedicated security or compliance specialist. Whatever was built had to be operable by that team without adding headcount — a compliance system that required a full-time compliance engineer to run was not a system this team could sustain.

The eleven-week runway to the third surveillance audit set a hard, external deadline that could not move. That ruled out any architecture requiring a long build-and-bake period before it produced usable evidence; whatever was deployed had to start generating audit-relevant history from week one, because the audit would credit history it could observe, not a system that had gone live the week before.

The team had already been burned once by policy enforcement tooling — an early, hastily-added admission webhook from an unrelated vendor evaluation had once rejected a production hotfix mid-incident, and the team's trust in anything that could block a deploy was, reasonably, low. Any new enforcement layer had to prove itself in observe-only mode before it was allowed to block anything, and the rollout had to be demonstrably safe or the team would resist adopting it at all — which would have defeated the point of building it.

Talos was already in place, which was an asset, but the machine configuration had been tuned for operability during the original migration, not against a specific benchmark. Bringing it into alignment with the CIS Kubernetes Benchmark meant touching kube-apiserver flags, etcd encryption-at-rest configuration, and audit-log policy on clusters carrying live claims traffic — changes that had to be validated and rolled out without a maintenance window, since the claims platform had no tolerance for scheduled downtime during business hours across the company's EU customer base.

Finally, the evidence itself had a shape requirement neither the platform team nor the company's leadership had fully appreciated before the engagement: it was not enough to fix the underlying RBAC problem once. The auditor's exact complaint was about reproducibility — the ability to show, for any date within the audit period, what the access posture had been on that date. A one-time remediation would pass the next audit and quietly recreate the same gap two cycles later. The system had to produce history, not just a corrected present state.

The engagement opened with a control-evidence gap audit: every ISO 27001 Annex A control and every applicable DORA ICT risk-management article the company had claimed conformance to, cross-referenced against what actually produced the evidence for it today. The pattern was consistent and, once mapped, obvious: for roughly a third of the controls in scope, evidence existed only as a screenshot or a spreadsheet row, produced manually by whoever happened to be assigned the task that quarter, with no record of the exact commands run or the exact cluster state observed at the time. The gap wasn't the controls themselves — the underlying Talos and Kubernetes configuration was largely sound. The gap was that nothing measured the controls continuously and kept the history.

We deployed KubeVigil — Stribog's open-source Kubernetes security posture tool — against both production clusters for continuous, in-cluster scanning, and wired the same rule set into the CI pipeline as a manifest gate, evaluating every Kubernetes YAML and Helm chart change against the same checks before it merged, not after it reached a cluster. This closed the reproducibility gap structurally: from the day KubeVigil went live, every finding, every remediation, and the date of every posture change existed in a queryable history, rather than in someone's memory of the last time they happened to check.

Kyverno was introduced to enforce, at admission time, the specific controls that had drifted: least-privilege RBAC patterns (no wildcard verbs or resources in namespaced Roles), mandatory data-classification labels on any namespace touching claims data, required non-root and read-only root filesystem contexts, and a ban on unsigned container images. Given the team's prior bad experience with enforcement tooling, every new policy went in set to audit-only — logging violations without blocking anything — first. We ran a full background-scan cycle, reviewed every violation with the platform team, remediated what was a genuine gap, wrote a documented, time-bound exception for the handful of cases that were legitimate exceptions rather than drift, and only then switched each policy to enforce — one policy at a time, never as a single cutover.

CIS Kubernetes Benchmark alignment came next, expressed entirely as changes to the existing Talos machine configuration already under GitOps management: audit-log policy, etcd secretbox encryption at rest, disabling anonymous authentication on the API server, and locking down the kubelet's read-only port. Because the machine configuration was already declarative and already reconciled through the existing pipeline, this was a configuration change with a documented diff and a CI-generated benchmark conformance report — not a re-platforming exercise.

The last structural piece answered the auditor's actual complaint directly: an automated RBAC review. A scheduled job diffs the live RoleBindings and ClusterRoleBindings against a declared least-privilege baseline stored in git, opens a pull request annotating every deviation by severity, and requires a named reviewer's sign-off before it merges. That merged pull request is the access review — dated, attributable, and reproducible for any point in its own git history. It is the artifact the second surveillance audit asked for and never got.

The third surveillance audit took place on schedule, eleven weeks after the engagement began. The auditor's original access-review observation — the one that had recurred across two prior cycles — was formally closed; the RBAC-review pull request history from the intervening months gave the auditor exactly the reproducible, dated evidence that had been missing, and no new occurrence of the finding was raised. For the controls the auditor sampled, evidence was produced during the audit session itself, by running a query against KubeVigil, Kyverno's PolicyReports, or the RBAC-review git history — not assembled in the weeks beforehand.

Representative outcomes across comparable engagements (not precise client figures): Evidence assembly time per sampled control fell to under four hours on average, down from the multi-day, sometimes multi-week effort the manual process required — because the evidence is a query against a system that has been running continuously, not a document built for the occasion.

The specific finding that had recurred across two audit cycles closed and did not reappear; recurring findings across the full control set in scope dropped to zero in the cycle following the engagement.

Security-questionnaire turnaround compressed from one-to-three weeks to one-to-two days for most incoming questionnaires, because the majority of standard CAIQ- and SIG Lite–style questions map directly onto a control the evidence-assembly pipeline already answers. Both stalled enterprise deals cleared procurement within a month of the new process going live.

Both production clusters run under continuous KubeVigil scanning and Kyverno enforcement, with CI-side manifest scanning blocking new drift from entering either cluster in the first place.

The Talos-based Kubernetes platform, unchanged in its fundamentals — this was a posture and evidence engagement, not a re-platform. The KubeVigil deployment, the Kyverno policy set, the RBAC-review automation, and the hash-chained audit archive are all operated by the existing eight-person platform team; no new headcount was added, and no Stribog dependency remains in day-two operations. The company did create one new, explicit role — a part-time compliance owner drawn from the existing team — to triage the weekly KubeVigil digest and sign off on RBAC-review pull requests, formalising work that had previously been an unstructured, uncredited burden on the VP of Engineering. The control-mapping document is maintained as a living artifact, updated by the platform team whenever a new control comes into scope, rather than treated as an engagement deliverable frozen at handoff.