Projects / 08
DORA VigilOR / CAL Engine
Exploratory research into expressing cybersecurity control requirements as structured data rather than documents, with continuous evidence and assessment.
Overview
We investigate how cybersecurity control requirements under regulatory frameworks such as DORA can be expressed, tracked and evidenced as structured data rather than as documents. The question is a modelling one: what shape does a control requirement need to have before software can reason about it?
Control requirements today are usually held as prose in policy documents and spreadsheets. Prose cannot be queried, cannot be linked to the systems it constrains, and cannot indicate whether the evidence supporting it is current. Every gap in that chain is closed manually, repeatedly, by people.
The research treats the requirement, the control that implements it, the systems in scope and the evidence that supports it as related records with defined relationships, and asks what becomes possible once they are.
The problem
Compliance work is dominated by evidence logistics rather than by security decisions. Evidence is collected in bursts before an assessment, assembled by hand, and stale by the time it is reviewed. The resulting picture describes a moment that has already passed.
Because the mapping between a requirement and the systems it applies to lives in a document, it degrades quietly as the estate changes. A control that was accurate when written becomes fiction without anything signalling the change.
The result is a widening gap between documented posture and actual posture — and, importantly, no way to measure the size of that gap, which is the part this research is most interested in.
Architecture
The architecture separates the requirement model, the control model, the scope model and the evidence store. Requirements are represented generically as structured records with identifiers, obligations and relationships, so the same machinery can carry requirements from different frameworks without being written for any one of them.
- Requirement records
- Structured representations of control obligations, framework-agnostic, with explicit relationships to the controls that implement them.
- Control mapping
- Links between requirements, implementing controls and the systems in scope, maintained as data so that changes in scope are visible.
- Evidence collection
- Automated gathering of evidence artefacts with the timestamp, source and collection method attached, so that freshness is a property of the record.
- Continuous assessment
- Repeated evaluation of whether current evidence supports a control's stated state, producing a status that decays when evidence goes stale.
The design is deliberately generic. Encoding the specific structure of any one regulation into the engine would make it accurate for that regulation and useless for the next revision of it.
Security model
The evidence store is the sensitive component. It aggregates a description of an organisation's control weaknesses in one queryable place, which makes it a more attractive target than any individual system it describes.
- Trusted
- The requirement and control models and the integrity of the evidence store, which must be append-only for collected artefacts if the record is to mean anything.
- Untrusted
- Evidence content collected from systems. It reflects what a system reported, which is not the same as what is true of that system.
- Explicitly not claimed
- That automated evidence collection establishes compliance. It establishes what was observed, when, and by which method — a strictly weaker statement, and the distinction is the point.
Assessment decisions are treated as human decisions supported by data, not as outputs of the engine. Automating a judgement that has regulatory weight is outside the scope of this research.
Current status
The work is experimental. The requirement, control and evidence data model has been sketched and tested against generic examples in a lab. It has not been applied to a real regulatory programme, reviewed by compliance practitioners at any depth, or used to support an actual assessment.
There is no product, no assessment service and no compliance offering associated with this research.
Limitations
One limitation is that regulatory requirements are written in natural language with deliberate interpretive scope. Turning them into structured records means committing to one interpretation, and the commitment itself is a risk the model cannot represent.
A second is that automated evidence tends to capture what is easy to collect rather than what best demonstrates a control. Measuring the wrong thing consistently produces confident, misleading assurance.
A third is that continuous assessment shifts effort rather than removing it: maintaining collectors, mappings and scope definitions is ongoing work, and if that maintenance lapses the model degrades in the same way documents do.
A fourth is that we are engineers, not regulatory specialists. Any interpretation of a framework in this research needs review by people qualified to give it, and until then the work should be read as a data modelling exercise.
Roadmap
- Stabilise the framework-agnostic requirement and control data model.
- Define evidence freshness semantics, including how a control's state decays when evidence ages.
- Prototype automated collection for a small set of technical controls in the lab.
- Model scope drift so that changes in the estate invalidate affected mappings automatically.
- Seek review from qualified compliance practitioners before extending interpretation work.
Detail
Topics
- governance
- control mapping
- evidence collection
- continuous assessment
- compliance engineering
- DORA