The concept of business process automation has long evolved under the banner of execution speed and operational cost reduction. However, modern risk management realities, particularly the implementation of strict European NIS2 directive requirements, are shifting the focus. Today, operational speed alone is insufficient; evidentiary integrity, or Digital Provenance (the digital origin of data and decisions), is becoming critical. The lack of mechanisms that allow auditors to indisputably prove how, by whom, and based on what logic a decision was made or data was changed in the system, is turning into critical technical debt.
For CTOs, CIOs, system architects, and CISOs of critical infrastructure enterprises, this means a need to rethink approaches to designing corporate solutions. Traditional logging in relational databases no longer satisfies regulatory requirements for data lineage and immutable audit trails.
Why NIS2 changes the rules: from perimeter defense to process evidentiary integrity
The NIS2 directive requires organizations not just to protect the network perimeter, but to implement end-to-end risk management and ensure the evidentiary resilience of business processes. While previously the security of a financial transaction approval process was assessed by the presence of WAF and access control tools, during a NIS2 audit, the key question is different: «How can you prove that this process was not modified from within, and that data did not undergo unauthorized changes on its way from initiation to the final decision?»
Auditing an automated financial transaction approval process requires the ability to reconstruct the full data lineage. However, most companies lacking a built-in Digital Provenance mechanism are forced to manually collect log files from various systems. This approach makes rapid confirmation of process integrity almost impossible.
Anatomy of technical debt: why standard system logs are insufficient for audits
A typical architectural error is using exclusively standard application logs or relational database triggers as the source of an audit trail. From a regulatory perspective, this approach has fundamental flaws:
- Lack of business context: A database technical log records the fact that a row changed but does not explain which business process it occurred in or which specific business rule was triggered.
- Vulnerability to modification: Logging conducted without cryptographic protection or not in WORM storage can be easily modified or deleted by users with privileged rights (e.g., DBAs).
- Non-compliance of actual execution with declared rules: Technical logging does not allow for the automatic detection of unauthorized workarounds (shadow processes) in business logic that arise due to discrepancies between the model and actual user actions.
To eliminate this technical debt, the system architecture must guarantee the immutability of the audit trail and ensure a clear separation of workflow logic from decision-making logic.
Digital Provenance architecture: combining BPMN 2.0, DMN, and immutable audit trails
A reliable governance architecture is based on the use of open executable standards. This avoids hardcoding business rules and creates a single source of truth.
1. Executable BPMN 2.0 standard
The Business Process Model and Notation standard (BPMN 2.0.2, published as international standard ISO/IEC 19510:2013 by the Object Management Group) is an executable standard that simultaneously documents and manages the process. When a process is managed by a process engine (e.g., Camunda), every state of the process instance becomes visible and is recorded automatically, ensuring that real execution complies with regulations.
2. Separating logic with DMN
The Decision Model and Notation (DMN) standard allows business rules to be moved from program code into separate decision tables. For example, separating the logic for calculating credit limits from the process flow logic allows these rules to be updated quickly without the risk of violating workflow integrity. This makes IT audits transparent: the system records not only the result but also the version of the DMN table and the input parameters that led to the automatic decision.
3. Ensuring an immutable audit trail
Blockchain technology is not the only or mandatory way to implement an immutable audit trail. In corporate systems, immutability is achieved at the architectural level through cryptographic transaction hashing, the use of WORM storage, or secure audit logs with strict access control at the row level (Row-Level Security) and attribute level.
Process Mining as a tool for detecting shadow processes and deviations
Process mining allows for the reconstruction of real process flows from event logs, revealing hidden (shadow) routes and bottlenecks not reflected in official diagrams. According to Celonis, the use of process mining often reveals that real processes deviate from documented models in a significant portion of cases.
It is worth noting that process mining is not a tool for active protection against cyberattacks. It is a diagnostic and visibility tool that detects deviations (compliance monitoring) and provides the ability to verify the actual flow of processes during an audit.
Built-in platform-level security: implementing NIS2 requirements using UnityBase and Scriptum
Implementing a Digital Provenance architecture from scratch creates a significant burden on development. A rational approach is to use enterprise platforms where audit and security mechanisms are built into the core.
For building such systems, it is appropriate to use the low-code platform UnityBase. The platform is a joint development by companies of the Intecracy Group alliance (where InBase acts as a key, but not the only, developer). UnityBase offers architectural mechanisms that simplify preparation for a NIS2 audit:
- Domain metadata: A unified metamodel for data, API, and the Admin UI, which makes it impossible to modify data while bypassing application rules.
- Built-in Audit Trail (DataHistory): The platform automatically records any changes to critical attributes, storing the author, time, and previous values to ensure end-to-end data lineage.
- Flexible security model: Support for Role-Based Access Control (RBAC), Row-Level Security (RLS), and Attribute-Level Security (available in commercial EE/DE editions), which allows for clear separation of access rights at the lowest level.
The Scriptum process automation system, which works with the Camunda BPMN engine, is built on the UnityBase platform. Their combination ensures the separation of business logic and workflow, as well as automatic documentation of process instance states. Implementing Digital Provenance thanks to a ready-made stack of mechanisms allows for reducing audit preparation time from weeks to hours.
Maturity levels of Digital Provenance in automated processes for NIS2
| Maturity Level | Logging characteristics | Impact on NIS2 compliance | Technical implementation |
|---|---|---|---|
| Level 0 (Chaotic) | Logging is absent or kept in text files that can be manually modified. No link between business context and technical events. | Critical risk. Inability to prove system integrity to auditors. | Local unstructured log files. |
| Level 1 (Fragmented) | Logging is kept in a database. Basic change audit exists, but data lineage is missing (impossible to reconstruct the decision-making chain). | Low compliance. Significant time spent on incident investigation. | Database triggers, fragmented log tables. |
| Level 2 (Regulated) | BPMN engine is used. Processes are documented, logging is performed at the process step level, but decision rules (DMN) are hardcoded. | Partial compliance. Transparent workflow, but difficult to verify the logic of a specific decision. | BPMN platforms with basic execution history. |
| Level 3 (Evidentiary / NIS2-ready) | Full immutable audit trail. Separation of workflow (BPMN) and business rules (DMN). Automatic data lineage control at the domain model level. | High audit readiness. Quick access to the evidentiary base. | Use of mechanisms like UnityBase (RLS/Audit Trail) and automation systems (Scriptum with Camunda). |
Compliance with the NIS2 directive requires not only organizational security policies but also the implementation of evidentiary integrity directly into the IT architecture. Combining executable BPMN 2.0 and DMN standards with built-in DataHistory mechanisms based on modern low-code platforms eliminates technical debt and creates a reliable foundation of trust in automated solutions.
FAQ
What is Digital Provenance and why is it critical for NIS2 compliance?
Digital Provenance is evidentiary integrity and the ability to trace the origin of data and decisions in a system. For NIS2, this is critical because an organization must be able to technically prove to regulators that no stage of a critical process or state of data was modified without authorization.
How does separating BPMN 2.0 and DMN standards help pass an IT audit?
DMN allows decision-making logic to be moved into separate tables, independent of the process flow (BPMN). This allows auditors to clearly see which version of the rules and which input parameters led to a specific decision in the system without analyzing the source code.
How can an immutable audit trail be ensured in corporate systems?
Immutability is ensured not only by blockchain but also by classic architectural approaches: cryptographic hashing, the use of WORM storage, and built-in history tracking at the domain model level (e.g., through the DataHistory mechanism and Row-Level Security in the UnityBase platform).