Organizations today rarely struggle with a lack of security requirements.
They struggle with too many of them.
NIS2, DORA, ISO 27001, SOC 2, the EU AI Act, industry-specific regulation, internal policies and customer requirements increasingly overlap. Each brings its own terminology, structure and expectations, but underneath they often ask variations of the same questions:
- What systems do you operate?
- What risks affect them?
- Which controls are in place?
- Who is responsible?
- Can you prove it?
Yet most compliance processes still treat each framework as a separate exercise, and that is becoming the real problem.
The same organization, described again and again
Consider something as simple as access management. An organization may need to demonstrate how privileged access is approved, provisioned, reviewed and revoked for an ISO 27001 audit. Similar information may later be required for NIS2 compliance, a customer security assessment, an internal audit or another regulatory obligation.
The underlying reality has not changed. The same systems exist. The same people are responsible. The same procedures are followed. The same logs, tickets, policies and records provide the evidence.
What changes is the question.
Traditional compliance processes repeatedly reconstruct this reality from scratch. People complete questionnaires. Documents are uploaded into different repositories. Evidence is collected again. Controls are mapped between frameworks. Spreadsheets are created. Consultants interview the same people about information the organization already provided somewhere else. The result is an enormous amount of duplicated work.
The problem is not that the organization does not know how it operates . It is that its knowledge is fragmented.
Compliance information already exists
Most of the information needed to understand an organization’s security and compliance posture already exists somewhere. It may be found in policies, procedures, architecture documents, asset inventories, risk registers, contracts, audit reports, tickets, system configurations, meeting records or the knowledge of individual employees. But these pieces rarely form a coherent model.
- A policy may describe how something should work.
- A configuration may show how it actually works.
- A ticket may demonstrate that a control was performed.
- An audit report may identify an exception.
- And an employee may know that the process changed three months ago.
Individually, these are documents and data points, but together they represent organizational knowledge.
This distinction matters because compliance cannot ultimately be demonstrated by answering questions. It has to be demonstrated by understanding what actually happens inside the organization and connecting that reality to the requirements that apply to it.
Evidence changes the question
This is why we believe compliance should start with evidence rather than questionnaires.
Instead of asking someone:
“Do you periodically review privileged access?”
we should be able to determine:
- What is the organization’s defined process?
- Who is responsible for performing the review?
- Which systems are covered?
- When was the last review performed?
- What evidence demonstrates that it happened?
- Are there contradictions between the documented process and the available evidence?
And only then: Does this satisfy the relevant requirement? This changes compliance from a declaration into an evidence-based assessment and also makes the answer reusable.
If the organization has already established how privileged access management works, another regulatory framework should not require the organization to explain the entire process again. The new requirement should be evaluated against knowledge that already exists.
From control mapping to organizational understanding
Much of traditional GRC is built around mapping.
- Requirement A maps to Control X.
- Control X maps to Requirement B.
- Requirement B maps to another framework.
Mapping is useful, but it has an important limitation: it describes relationships between regulatory concepts. It does not necessarily describe the organization implementing them. Two companies can have exactly the same control mapped to exactly the same ISO 27001 requirement while implementing that control in completely different ways. What matters is not only knowing that two requirements are similar. What matters is understanding how a particular organization satisfies them. That requires a different model.
A compliance system should understand relationships between regulations, controls, business processes, information systems, people, risks and evidence. Once those relationships are understood, a regulatory requirement becomes something that can be evaluated against the organization’s existing knowledge. That is fundamentally different from filling in another questionnaire.
AI makes a different approach possible
Until recently, building and continuously maintaining this kind of organizational knowledge was difficult and expensive. Most of the relevant information is unstructured. It lives in documents written for humans, not databases designed for compliance software. Modern AI changes this. Large language models can analyze policies, procedures, technical documentation and other evidence and identify relationships that previously required substantial manual work.
But simply adding an AI assistant to an existing questionnaire does not solve the underlying problem.
The more important opportunity is to use AI to build and maintain an evidence-backed understanding of the organization itself. Such a system can learn how processes work, which systems support them, who is responsible, which controls exist and what evidence supports those conclusions. New regulatory requirements can then be evaluated against that knowledge. Instead of asking the organization to start again, the system can begin with what is already known.
Compliance becomes a continuous process
This also changes the concept of a compliance assessment.
A traditional assessment has a beginning and an end. Questions are answered. Evidence is collected. Findings are recorded. A report is produced.
Then the organization changes.
A new system is introduced. A supplier changes. Someone leaves. A control is redesigned. A regulation is amended. The assessment slowly becomes a description of the past.
If compliance is based on continuously maintained organizational knowledge instead, the model can evolve with the organization.
- A new piece of evidence can affect several requirements.
- A changed process can trigger reassessment across multiple frameworks.
- A newly applicable regulation can be evaluated against information the organization already has.
Compliance stops being a sequence of isolated projects and becomes a continuously updated understanding of the organization’s security and regulatory posture.
Evidence over opinion
This is the idea behind IVERIOS.
We believe the next generation of GRC platforms should not primarily be systems for managing questionnaires, controls and mappings – they should be systems for understanding organizations.
IVERIOS is being built around a persistent organizational knowledge layer: connecting requirements with processes, systems, responsibilities, risks and the evidence that supports them.
The objective is simple.
An organization should not have to explain the same reality every time somebody asks a different compliance question.
It should explain it once, support it with evidence and continuously improve that knowledge.
Everything else — compliance assessments, risk analysis, audits, regulatory intelligence and security improvement programs — can build on top of it.
Evidence over opinion. Understanding over mapping.
