The Missing Layer: How Ontology Bridges Regulation and Infrastructure

Two languages, one risk

Every enterprise runs on two parallel descriptions of itself. One is written in the language of regulation: obligations, articles, control objectives and attestations. The other is written in the language of technology: assets, identities, configurations, vulnerabilities and attack paths.

Both describe the same risk, yet they are maintained by different teams, in different tools, on different timelines. The board asks “are we compliant with DORA?” and the SOC asks “which of these thousands of findings matters?” Rarely does anyone hold a model that answers both questions at once.

This article argues that the missing piece is not another framework or another scanner. It is a shared semantic layer, an ontology, that connects what regulation requires to what the infrastructure actually is. For the first time, AI makes that layer practical to build and keep current.

The fragmentation problem

The compliance layer and the infrastructure layer have grown apart, and the number of frameworks keeps widening the gap. In Strike Graph's 2025 survey, 42.6% of organizations manage four or more frameworks at once, 54% expect that number to grow, and only 4.4% are highly confident they can scale compliance (Business Wire). Coalfire found almost 70% of organizations manage at least six frameworks (Security Magazine).

The two layers differ in almost every dimension that matters:

The result is a familiar paradox. An organization can pass an audit while a critical, exploitable path to a crown-jewel system stays open. And a SOC can patch thousands of findings without being able to show the board which regulatory obligation is now better met.

Why crosswalks and GRC tools have not closed the gap

Most of the industry's answer so far has been the crosswalk: a table that maps control A in one framework to control B in another. Crosswalks reduce duplicate audit work, but they map documents to documents. They say nothing about which server, identity or cloud account actually implements a control, or whether that control is working today.

Research has flagged this limit for years. Fenz and Neubauer observed that traditional risk-management software provides a limited degree of automation when mapping security knowledge onto a company's concrete situation (Information and Computer Security, 2018). A Vilnius Tech study of existing security ontologies found none covered more than a third of the standards tested (Ramanauskaitė et al., 2013).

Even machine-readable formats do not help if nothing feeds them from the environment. FedRAMP reports that in 2025 it processed more than 100 Rev5 authorizations and not one used OSCAL (FedRAMP RFC-0024). The OECD describes the root cause well: organizations repeatedly interpret natural-language rules and translate them into their own systems (OECD OPSI).

Three structural gaps remain:

• No shared vocabulary. “Asset”, “critical function” and “control” mean different things to an auditor, an architect and a SOC analyst.
• No live binding. Mappings stop at the control catalog and never reach the configuration, identity or exposure that proves or disproves the control.
• No reasoning. A spreadsheet cannot infer that one misconfigured identity weakens a DORA obligation, an ISO 27001 control and a NIS2 measure at the same time.

Ontology: one model both layers can read

An ontology is a formal model of the things in a domain and how they relate, precise enough for a machine to reason over. Unlike a crosswalk, it does not map framework to framework. It maps every framework, and every piece of infrastructure, to the same set of shared concepts.

For exposure and compliance, the chain an ontology must connect looks like this:

1. Regulation or framework (DORA, NIS2, ISO 27001, NIST CSF 2.0, SEC rules)
2. Requirement (a specific article or clause, with its obligation)
3. Control objective and control (normalized once, shared across frameworks)
4. Implementation (the policy, configuration or tool that realizes the control)
5. Asset and identity (servers, cloud resources, applications, users, service accounts)
6. Exposure (vulnerability, misconfiguration, excessive privilege, external reachability)
7. Attack path and business impact (which critical function an adversary could reach)

Typed relationships make the chain usable. NIST IR 8477 defines relationship types such as “supports”, “equivalent” and “integral to” for exactly this purpose (NIST IR 8477). MITRE D3FEND shows the pattern at the technical end: it links attacker techniques to countermeasures through a shared ontology of digital artifacts, and publishes a mapping to NIST SP 800-53 controls (D3FEND mappings).

Once the chain exists, questions that used to take weeks become queries. Which DORA obligations depend on this unpatched VPN gateway? Which exposures, if fixed, raise ISO 27001 and NIS2 coverage at the same time? What changed in our control evidence since the last audit?

AI makes unification practical

For most of the past decade, the ontology idea was held back by two costs. The first was translation: someone had to read each regulation and convert it into structure. The second was maintenance: every revised framework and every changed environment meant redoing the mapping by hand. Both costs were high enough that only a few programs ever built the model. AI changes the economics of both.

Research already shows the direction. Muth and Margraf (2025) combine large language models with knowledge graphs to support semi-automated IT-Grundschutz certification, covering protection needs, modelling and control checks. PrivComp-KG uses an LLM and retrieval-augmented generation to find the policy passages that correspond to regulatory rules, then queries the graph to assess each vendor. A 2025 survey of ontologies, knowledge graphs and LLMs in cybersecurity reaches the same conclusion: these models are most useful when grounded in a structured representation of the domain.

The limits are real. The NIS 2 method in arXiv 2307.01211 showed that NLP could build a usable ontology from a directive, but it still needed manual analysis to complete the work. AI does not remove expert judgment from the mapping. It moves experts from typing mappings to validating them.

Demand is already there. In Strike Graph's 2025 survey, 67.6% of respondents use AI in some capacity for compliance and 72.5% plan to add AI features within 12 months, yet only 10.6% have adopted advanced, agentic systems. The main brake is trust: 63% cite potential errors and 50.5% cite data security as their greatest concerns (Business Wire). Those concerns point to what makes unification work with AI. A model that is explicit, traceable to source clauses and verifiable against live telemetry gives AI something to be accountable to.

AI contributes in three roles:

1. Translate. AI reads a regulation and proposes requirements and their relationships, each linked to the exact clause it came from.
2. Connect. AI proposes which assets, identities and configurations implement each control, based on discovered data.
3. Explain and act. AI answers questions against the graph, drafts evidence, and prioritizes exposures by regulatory and business impact, showing its reasoning.

This is also why agents need a model underneath them. An agent that reads regulation without seeing the environment can only draft. An agent that reasons over a shared ontology can verify.

Regulators are already moving toward machine-readable, model-based compliance

The direction of travel is clear: regulators and standards bodies are converging on structured, relational models of their own rules, and asking for evidence from the environment rather than from documents.

The common thread: a regulation becomes useful to a machine only once it is expressed as concepts and relationships. The remaining step, which no regulator will take for you, is binding those concepts to your own infrastructure.

How it comes together inside the organization

An ontology changes the operating model more than the tooling. Every function works from the same graph, each through its own lens.

In practice, the loop runs continuously:

1. Ingest each applicable regulation and framework once, normalized into shared control concepts.
2. Discover assets, identities and dependencies, and bind them to the business functions they support.
3. Link each control to the implementations and telemetry that prove it.
4. Map exposures to the controls they weaken and the attack paths they open.
5. Prioritize remediation by combined business, threat and regulatory impact.
6. Re-evaluate automatically on every material change, which is what DORA Article 8(3) requires.
7. Report the same facts to the board, the regulator and the SOC, each in its own language.

AI shortens steps 1 and 2 from months to days, while people keep approval of every mapping. The cultural shift matters as much as the technical one. Compliance stops being an annual project that interrupts engineering, and becomes a by-product of running a well-understood environment.

The RedRok perspective: a universal exposure and compliance model

RedRok was built on the premise that exposure management and compliance are the same problem seen from two sides. RedRok 2.0 puts an ontological model of the corporate network at the core of the platform: assets, identities, dependencies, controls and exposures, held as one connected graph rather than as separate inventories.

From CMDB to a universal model

The CMDB became the system of record for IT by giving every team one inventory of configuration items. RedRok applies the same idea one level up. It aims to be the system of record for exposure and compliance: one universal model that every framework, tool and team reads from.

The difference is what the model holds. A CMDB records what exists. The RedRok ontology also records what it means: which business function an asset supports, which control protects it, which exposure weakens that control, and which obligation is at stake as a result. It is kept current by continuous discovery, not by manual updates.

The next layer: the Compliance Agent

The Compliance Agent adds regulation as a new layer on top of the ontology. Its role is to do, continuously and at scale, the translation work that GRC teams do by hand today. It is expected by the end of Q4 2026.

The Compliance Agent will:

• Ingest a regulation or framework, such as DORA, NIS2, ISO 27001 or NIST CSF 2.0, and break it into individual requirements.
• Map each requirement to the controls, assets and configurations in the ontology that fulfil it.
• Evaluate posture against each requirement from live data, and produce evidence and gap lists.
• Maintain mappings as frameworks are revised and as the environment changes, re-assessing on every material change.

Because every framework maps to the same model, a single exposure instantly shows its impact across all of them, and a single fix shows its benefit across all of them.

People, process and technology, together for the first time

Security programs have always been described as people, process and technology. In practice, each has run on its own track. A universal model is what finally lets them meet.

See your exposure through the same model.

A 30-minute demo, then a scoped pilot on one business unit. We reply within one business day to set a time.

References and further reading

Standards, regulation and government

• European Union. Regulation (EU) 2022/2554 (DORA), Article 8: Identification.
• FedRAMP. RFC-0024: FedRAMP Rev5 Machine-Readable Packages, and Initial Outcome notice (2026).
• NIST. IR 8477: Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines (2024).
• NIST. Open Security Controls Assessment Language (OSCAL).
• MITRE. D3FEND knowledge graph and mappings to NIST SP 800-53.
• Mohun, J. & Roberts, A. (OECD, 2020). Cracking the Code: Rulemaking for Humans and Machines.

Academic research

• Muth, L.R. & Margraf, M. (2025). An Approach for a Supporting Multi-LLM System for Automated Certification Based on the German IT-Grundschutz.
• Fenz, S. & Neubauer, T. (2018). Ontology-based information security compliance determination and control selection on the example of ISO 27002. Information and Computer Security, 26(5).
• Fenz, S., Goluch, G., Ekelhart, A., Riedl, B. Information Security Fortification by Ontological Mapping of the ISO/IEC 27001 Standard. TU Wien.
• Ramanauskaitė, S. et al. (2013). Security ontology for adaptive mapping of security standards.
• An automated method for the ontological representation of security directives (NIS 2 ontology), arXiv 2307.01211.
• Guiding cybersecurity compliance: An ontology for the NIS 2 directive (NIS2Onto) (2025).
• A survey of ontologies, knowledge graphs and LLMs in cybersecurity, arXiv 2510.16610 (2025).
• Wang, W., Sadjadi, S.M., Rishe, N. (2024). A Survey of Major Cybersecurity Compliance Frameworks. IEEE BigDataSecurity.
• MITRE (2021). Toward a Knowledge Graph of Cybersecurity Countermeasures.

Industry data

• Strike Graph. 2025 State of AI in Compliance Report.
• Coalfire, via Security Magazine.