Skip to content

Resilience

Resilience Made Easy: The Path from GRC Filing Cabinet to Agentic Workspace

Why we're not building KaitoSec as a GRC filing system, but as an agentic workspace for continuous resilience, and what that means for the information security officer's daily work.

By Chris Müller · Published 5 August 2026 · Updated 3 September 2026 · 9 min read

Resilience Made Easy. That's the vision we're building toward. Two clocks are ticking against every company at once, and both are speeding up. NIS2 has applied in Germany since December 2025 with no transition period, BSI Grundschutz++ (BSI's next-generation baseline) becomes certifiable in January 2027, and in parallel, the time from vulnerability disclosure to first exploit has shrunk from 771 days (2018) to 84 days (2020), 6 days (2022), hours (2024), and now minutes (2025). Annual audits and quarterly spreadsheet updates can't keep pace with either rhythm anymore. We're solving this differently: scalable, agentic, with a workspace that works alongside you instead of just documenting after the fact. That's Resilience Made Easy.

Why Does GRC Hit Its Limit?

GRC tools are built for a specific purpose: to capture the current state of policies, risks, and controls, and derive action items from that snapshot. They document an information security officer's daily work after the fact instead of becoming part of it.

That shows in the age of the systems themselves. Most tools in use today date from 2008 to 2016, and their data models have only been superficially modernized since, never rethought. Their footprint in a company's security culture is correspondingly weak. In practice, these tools are often operated by just two or three people, while the rest of the organization knows them, at best, from audit prep.

What's missing are the connections that actually capture resilience: interfaces to cloud environments, IAM, ticketing, and HR systems, the places where the real state of access rights, responsibilities, and open issues actually lives. Without that integration, the GRC tool stays a byproduct. The real work happens elsewhere, in spreadsheets, in email threads, in tickets run in parallel to the tool. What's missing is a holistic approach that builds in this integration from the ground up, instead of treating it as an afterthought.

Maintaining compliance can't be a spiral of ever more effort. It has to fit seamlessly into daily work instead of adding another burden on top of it. This is where GRC and resilience part ways.

In practice, GRC comes down to building a paper trail. You gather evidence for an audit, document implementations, and check off controls as done. What's left afterward is a filing folder, not a behavior. Resilience means something else: continuous operational capability that isn't just documented but lived and built into daily work.

This distinction doesn't stop at information security. It reaches straight into continuity. Staying operational in a real crisis requires a BCMS held to the same standard as the ISMS, a state that holds up under pressure too.

That requires breaking down silos. A separate information security officer's silo next to a separate business continuity manager's silo produces two truths about the same organization, and two truths quickly turn into document drift. That means registers diverge, and changes in one place go unnoticed in the other. The alternative is a shared data foundation that ISMS, BCMS, and additionally DSMS and AISMS all build on. They share the underlying reality once instead of maintaining it four times over, separately, and that's exactly what prevents drift between domains.

In concrete terms: every control has an owner, a due date, and auditable evidence. The CISO, information security officer, data protection team, and executive management all see the same status, each at the depth their role calls for. Where risks, controls, assets, and contingency plans used to sit redundantly in separate domains, the records are now linked. A single change immediately shows which risks, controls, and contingency plans are affected and who needs to act next. This approach needs a tool built from the ground up for linked data.

This structural gap collides with a second, bigger problem: the sheer number of different frameworks.

Multi-Framework Complexity, and How Cross-Mapping Resolves It

Anyone responsible for information security today is juggling an entire stack of frameworks. German standards like IT-Grundschutz meet European requirements like NIS2 and international standards like ISO 27001, which has become the reference point especially for the Mittelstand. Internationally connected companies can no longer avoid covering multiple regulatory regimes at once, because customers, supply chains, and subsidiaries rarely sit in just one jurisdiction.

The same control gets copied into separate files for ISO 27001, NIS2, DORA, and BSI. Once for each standard, every time by hand, every time with the risk that one version goes stale while another gets updated. The problem gets worse as the number of relevant frameworks grows, and with it, the number of files that need to be maintained in parallel.

The real problem is the redundancy between frameworks. At their core, most cross-industry standards demand the same system:

  • Plan
  • Do
  • Check
  • Act

Without cross-mapping, that means doing the same requirement twice or three times over. With cross-mapping, the chaos turns into a clear overview.

The budget pressure behind this is real, and it's quantified. The German federal government estimates the annual compliance cost from NIS2 alone at around 2.3 billion euros. That burden falls disproportionately on the Mittelstand, whose resources for regulatory work are already stretched thin. DORA tightens the situation further, demanding continuous evidence instead of annual audits. The same basic tension between obligation and capacity repeats with every new framework, and simply checking boxes barely resolves it anymore. Part of this budget goes to expensive external consultants who resolve this exact redundancy manually, project by project, instead of fixing it structurally.

This is exactly where cross-mapping comes in. KaitoSec maintains one baseline standard in full, and every additional standard gets mapped only through its gaps to that baseline. Cross-mapping is the mechanism behind it. A single control covers multiple requirements across different standards at once, instead of being maintained separately for each framework.

In concrete terms: 93 Annex A controls from ISO 27001:2022 come preloaded. The same controls also feed BCMS, DSMS, and AISMS. Four management systems from a single point of maintenance. The Statement of Applicability (SoA) is generated from that, instead of being manually pieced together from spreadsheets.

This principle carries down to the evidence layer. Evidence from XML, Excel, PDF, and API data can be linked into workflows for NIS2, Grundschutz++, ISO, and GDPR. The source gets maintained once and used wherever it applies. A firewall log or a training record doesn't need to be uploaded four times just because four standards ask for it.

For a full picture of the frameworks covered, the framework overview has it: ISO 27001, BSI Grundschutz++, NIS2, DORA, and GDPR are mapped and deduplicated. The result of this architecture is a direct lever. Multiple standards get implemented faster because no control has to be maintained twice. This linked data foundation is also the basis for the actual workbench where the work gets done.

What Agentic Workspace Actually Means

KaitoSec is the workbench, the place where and with which the work happens. The risk register, action plan, and approvals live in one place instead of scattered across folders and inboxes. Agentic means this workbench actively works alongside you. It automates individual steps, suggests, and drafts, saving real time over manual upkeep.

The vision behind it is an orchestrator hub. Data from different sources flows together, stays controllable, and the team is part of the process instead of standing outside it. That's the clear line separating this from spreadsheets and legacy GRC tools, which manage data in silos and treat automation as an afterthought at best.

Behind that is a stance, not a feature list. Model independence. Whether Anthropic, OpenAI, or a local model behind your own firewall, the choice is yours. No forced AI upsell, no vendor lock-in. That's only possible because, under the surface, every standard draws on one shared structure.

Use Cases

KaitoSec maps controls, risks, and evidence into a single shared model. Open work items and accepted risks show up straight from the live status, instead of being reconstructed from scratch for every meeting.

From the early access program, an information security officer confirms exactly this effect:

“We replaced three spreadsheets and a shared drive with one system. ISO 27001 and NIS2 finally live in the same place, and the readiness overview shows exactly what's still open.”

A compliance manager, also from the early access program, highlights a different point: how fast the rollout was.

“Setup was faster than with any GRC tool we've tested. Within a week we had a real risk register and a reporting flow that our management actually reads.”

These statements aren't isolated. As of the current product state, KaitoSec's Knowledge Hub includes 40 articles, 30 templates, 100 answered questions, and 35 guide chapters across five topic areas: data protection, BCMS, TPRM, ISO 27001, and BSI Grundschutz. That depth comes from the same subject-matter work that underpins the cross-mapping.

Part of this approach is aimed squarely at the public sector. The Community Edition is a free, self-hosted variant for government agencies and public bodies across DACH. It's an offer to an audience that often has to get by without a budget for commercial GRC software, but holds itself to the same standard of traceability as any other organization.

An Offer, Not a Promise

KaitoSec is early. If you get on board today, you don't get a product with 10 years of market presence and an exhaustive feature list. You get a stance. We build in the open, together with the people who actually use the platform. That's the current state of the art.

GRC should be a tool you work with, not a filing cabinet you maintain. I believe in this path from filing cabinet to agentic workspace, and I'm building it together with the people who'll work with it tomorrow. Do you share this vision?

  • Resilience
  • Agentic Workspace
  • ISMS
  • BCMS
  • NIS2
  • Grundschutz++
  • Cross-Mapping

Back to the blog