AI Testing Talks: Ontology-Enhanced Multi-Compliance Capability

As organisations face an increasing number of regulations, standards, customer requirements and supply-chain obligations, managing cybersecurity compliance is becoming more complex.
In our latest AI Testing Talks session, we were joined by Antal Futó, Deputy Chief Security Advisor at Deutsche Telekom IT Solutions HU, to explore how ontology-based, machine-readable definitions can connect controls, assets, risks, services, suppliers, business processes and regulatory requirements – helping organisations build a more structured approach to multi-compliance cybersecurity governance.
More at https://exactpro.com/events/ai-testing-talks-webinar-25-september-2026

Transcript

1. Engineering Multi-Standard Compliance with Ontologies and AI How to build an efficient security foundation?
2. Antal Futó Security Manager I am an engineer in the information security business, who creates management systems, frameworks and concepts for secure IT.
3. Agenda ▪ Handle complexity ▪ AI and automation ▪ Get things done
4. „Quality is the degree to which a work product satisfies stated and implied requirements” ISTQB CT-AI syllabus (Dussa-Zieger et al., 2021)
5. Mindmaps show the way into the future Cybersecurity ontology could efficiently handle multi-standard compliance requirements. Key questions we will address: Ontologies + Knowledge graphs ▪ Complexity of the current status, ▪ AI and automation, ▪ Collaboration, and ▪ Roadmap Automatization + AI Cybersecurity + multi-standard compliance
6. Handle complexity
7. Maps reduce cognitive load
8. Security obligations multiply—and propagate REGULATORY VOLUME LAWS • STANDARDS • CONTRACTS ≈200+ NIS2 CRA DORA ISO 27001 customer terms Regulatory bodies in EU alone for telecommunications Customer Product Supplier Component Broad regulatory volume. Draghi competitiveness report Cloud Open source Every link can add implied security requirements. RESILIENCE IMPACT 54% of large organizations cite supply-chain interdependencies as the #1 barrier to cyber resilience. WEF Global Cybersecurity Outlook 2025 Which requirements reach a software project indirectly?
9. NIST IR 8477: the standard on mapping CORE CONCEPTUAL MODEL WHY MAPPING IS HARD set structural functional Documents Elements Concepts Relationships Mappings standards • regulations frameworks • guidance clauses • controls outcomes action • object context equivalent • broader supports • depends direction • scope evidence • rationale TERMINOLOGY GRANULARITY CONTEXT + PURPOSE Same words can differ; different words can align. Clause boundaries rarely match concept boundaries. Scope, actors and purpose change the relationship. A good mapping is a reviewable, directional claim—not a one-to-one lookup.
10. One crosswalk starts with 14,229 candidate pairs ISO/IEC 27001:2022 — ANNEX A 93 controls CIS CONTROLS v8.1 × 153 safeguards ILLUSTRATIVE PAIR-SCREENING MATRIX Each position asks: “What relationship, if any?” • no relationship • review FULL PAIRWISE SCREEN = 14,229 candidate pairs to assess WHAT THE EXPERT ACTUALLY DOES 14,229 candidate pairs ↓ MOST Rapidly rejected as “no relationship” ↓ HUNDREDS Still require semantic identification and classification Representative sample—not to scale The hard cases turn on granularity, context, direction and evidence—not keyword similarity.
11. A hub cuts 19,900 mappings to 199—but updates never stop MAPPING ARCHITECTURE VERSION MAINTENANCE FULL PAIRWISE ILLUSTRATIVE ASSUMPTION 200 × 199 ÷ 2 19,900 standard-to-standard mappings 200 ÷ 4 50 updates / year ≈ one standard changes every week CENTRAL REFERENCE 200 − 1 1 revision per standard every 4 years 199 Central Reference UPDATE direct mappings to one hub 99% fewer direct maps Revalidate its mapping to the central standard. central standard Full pairwise UPDATE Potentially revisit all 199 direct mappings. —but semantic review still remains. At scale, mapping is a continuous operational process—not a one-time project.
12. AI and automation
13. Harness the power of ontologies „The value of data is the insight which comes when different bits of data are joined together. For that process to provide value, the world must contain all sorts of kinds of information of different types, and it must be linked together. Linked data involves using ontologies.” Tim Berners-Lee
14. LLMs propose the mapping; experts decide what becomes truth MACHINE WORKSPACE HUMAN DECISION + GOVERNANCE 1 2 3 4 CONSTRAIN GENERATE VALIDATE PUBLISH NIST-based schema Scope + source versions Allowed relationship types Extract concepts Propose type + direction Attach evidence + rationale Check meaning, scope, granularity and direction Accept • edit • reject Approved assertions enter the ontology / map Corrections guide the next run LLM OUTPUT Element A → Element relationship: B supports direction: A→B evidence: exact text status: CANDIDATE The model produces a traceable assertion for review—not a compliance decision. TRACE EVERY CLAIM NO AUTOMATIC ACCEPTANCE RE-RUN WHEN VERSIONS CHANGE
15. Ontologies let agents uncover implied requirements 1 ONTOLOGY ADDS MEANING 2 AGENT TRAVERSES MEANING 3 PROJECT GETS REQUIREMENTS A shared vocabulary links clauses, assets, actors and outcomes. The agent follows validated meaning—not text similarity. The project receives candidate requirements with a reasoned path. Concepts • scope Typed functional relations Bind facts to concepts Follow paths • test scope • collect evidence Source • rationale • uncertainty Human approval before adoption ILLUSTRATIVE AGENTIC REASONING FACT Cloud handles sensitive data MEANING provider → supplier sensitive data → asset FUNCTION assurance → risk monitoring → detection Meaning makes implied requirements explainable and traceable. REQUIRE supplier check • clauses access logs • incident notice
16. Get things done
17. Roadmap to the future Readable by machines Transforming our data • OSCAL from NIST • Machine readable from start Interpretable by machines Explorable by humans Processable by humans Defining connections Interface for reading Interface for editing • Access to the audience • Easier adoption • Enabling customization • Use in daily operations • Accelerated by AI • Reaching semantic/ontology level description Our project is here
18. Quick win: publish the control catalogue in OSCAL REUSE WHAT ALREADY EXISTS PDF • XLSX • existing control lists The content is useful, but its structure is trapped in pages, cells and local conventions. STANDARDIZE ONCE OSCAL CATALOG REUSE IMMEDIATELY AI AI AGENTS Explicit fields + IDs Traceable relationships A standard machine-readable control model catalog ├─ metadata ├─ groups → controls └─ params • props • links • parts ↔ TOOLS + PIPELINES Validate + transform Import / export + APIs FIRST PROJECT DELIVERABLE Normalize once. Reuse everywhere. stable IDs • explicit fields • links XML | JSON | YAML Later OSCAL artifacts reuse the same identifiers. Useful in week 1—and the shared machine-readable source for every later stage.
19. Design the ontology from both directions WHAT EXISTS IN THE SOURCES? INTERNAL + EXTERNAL MATERIAL Catalogues • asset models Standards • MITRE • OSCAL SHARED SEMANTIC CONTRACT WHAT MUST TOOLS CONSUME? PLANNED CONSUMERS source semantics GRC • SIEM • reports APIs • AI agents • graph / search ONTOLOGY DISCOVER ELICIT consumer needs classes / concepts properties + value types relationships + identifiers granularity • provenance • versions RECONCILE canonical concepts + definitions mappings + constraints identifiers + serialization / API choices required entities + fields accepted IDs + formats queries • events • validations API / import / export contracts validate against real sources test against real consumers Fit both sides early: fewer one-off adapters, clearer mappings and easier integrations later.
20. Context and contracts make agent workflows reliable 1 2 3 4 Disambiguate before mapping Choose models that read JSON Keep PDFs for wider context Specialize agents; standardize I/O Homonyms resolve only when terms carry domain, source and surrounding context. Test that the model can navigate nested JSON while preserving fields, IDs and relationships. Structured data speeds navigation; PDFs still provide rationale, exceptions and narrative. Give each agent one focused role and a shared input/output schema for dependable handoffs. STANDARDIZED INPUT / OUTPUT WORKING PATTERN JSON structure + PDF context context-rich evidence E M V Extract Map Validate reusable output Meaning comes from context; scale comes from machine-readable structure and consistent contracts.
21. Collaboration is key ▪ Enable consensus making ▪ Customization on different layers ▪ Reduce the cognitive load of change ▪ Quick reaction time ▪ Built for continuous improvement
22. Establish a design methodology Design principles of our methodology: ▪ methodology approach Read the opinion paper ▪ scope ▪ development style ▪ ontology language ▪ ontology engineering framework ▪ plan Quality Assurance https://zero-outage.com/category/opinion/
23. Questions?
24. Thank you!