In the modern business environment, the legal validity of an electronic document depends not on the convenience of the user interface, but on the architectural integrity of the system, which ensures non-repudiation and forms a reliable evidentiary base. CIOs and corporate lawyers often view electronic document management (ECM) systems merely as tools for rapid file exchange. However, this approach creates a critical gap between technological implementation and the legal resilience of documents in the event of litigation or regulatory audits.
The Law of Ukraine "On Electronic Documents and Electronic Document Management" stipulates that the legal validity of an electronic document cannot be denied solely because it is in electronic form. However, in practice, this rule only applies when the system guarantees data integrity, precise timestamping, and the impossibility of modifying the document outside the application layer. Without an architecturally protected audit trail, any signed contract can be challenged due to the inability to prove its immutability after the signature was applied.
Why simple file signing is not enough: the concept of non-repudiation
In information security, non-repudiation plays a key role—a system property that makes it impossible for a subject to deny the fact of creating, signing, or sending a document. Many companies limit themselves to applying a qualified electronic signature (QES) to a PDF file via external services, ignoring subsequent lifecycle control.
During forensic technical examination, a signed file alone may be insufficient. The defense may claim that the key certificate was already revoked at the time of signing, or that a database administrator modified the system, bypassing the user interface. If the ECM does not record every step of document processing in immutable logs, it is technically impossible to refute such claims.
True non-repudiation requires that cryptographic operations be integrated with metadata and system logs. From the creation of a draft to final archiving, every action must leave a digital footprint protected from modification, even at the database administrator level.
Anatomy of an evidentiary base: ISO 15489-1 requirements for records management
The international standard ISO 15489-1:2016 applies to records regardless of their structure or technological environment. According to the standard, to maintain evidentiary weight, a system must ensure four characteristics:
- Authenticity: proof that the document is what it claims to be and was created by the specified person.
- Integrity: protection against unauthorized changes. Permitted additions (resolutions, annotations) must be recorded separately from the original body of the document.
- Reliability: an accurate reflection of the transaction, captured by automatic metadata collection at the moment of the event.
- Usability: the ability to retrieve the document and its context throughout the entire retention period.
Experts in Intelligent Information Management (IIM) note the evolution from simple file storage to intelligent information management (IDP). However, the use of machine learning algorithms requires clearly labeled data and mandatory fallback rules for rare document types. If AI automatically classifies a contract, the system must record this in the logs and ensure verification by an operator; otherwise, the evidentiary base may be compromised.
Cyber resilience of ECM based on the NIST CSF 2.0 methodology
The legal significance of documents depends directly on the ECM's resilience to cyber threats. The NIST CSF 2.0 framework structures cyber risk management through six operational functions:
- Govern: defining security policies and data accountability.
- Identify: asset inventory and document classification.
- Protect: strict access control, encryption, and segmentation.
- Detect: monitoring for anomalies, such as mass archive downloads.
- Respond: isolation of compromised nodes.
- Recover: backup with mandatory integrity verification of restored logs (audit trail).
System resilience is determined by the ability to ensure continuous certificate verification and log integrity. If an ECM is restored after a cyber incident but loses transactional logs, documents created during that period may lose their legal validity.
Architectural security level: the UnityBase platform
Critical vulnerabilities often arise from the use of "layered" security, where protection is implemented via external plugins over legacy architecture. A reliable ECM requires security by design at the platform level. Examples of this architectural approach include Megapolis.DocNet (by InBase) and Scriptum.DMS (by Scriptum), which are built on the full-stack JavaScript low-code platform UnityBase. UnityBase is a joint development of the Intecracy Group, which is an ALLIANCE of independent companies linked by partner agreements and share exchanges — NOT a single company, NOT a holding.
UnityBase ensures access control directly at the ORM (Object-Relational Mapping) level. In commercial editions (Enterprise/EE and Defence/DE), strict access separation is supported at the record level (Row-Level Security, RLS) and attribute level (ACL), making it impossible to bypass security policies via direct SQL queries. The audit log and change history (DataHistory) are maintained automatically at the kernel level, and for heightened security requirements, the Defence edition supports hardware tokens and direct integration with certification authorities (CRL and OCSP protocols).
Integration with registries and the Electronic Court system
The legal significance of documents is finally confirmed during their interaction with state systems. When integrating a corporate ECM with the "Electronic Court" subsystem, stable authentication and automatic monitoring of sent document statuses are critical.
Verification of validity requires checking the status of the trust service provider at the time of signing. The ECM must query qualified providers via the OCSP protocol to confirm certificate validity. Responses, along with timestamps, must be imported into the document metadata for long-term storage.
When processing non-standard legal documents, for example, via IDP modules in systems like Scriptum.DMS, routing requires fallback rules. If the system receives an atypical statement of claim, the process (BPMN) must automatically forward it to a lawyer for verification, recording manual changes to the details in the system log.
Levels of architectural resilience and legal validity in ECM
| Maturity Level | Technological Stack and Architecture | Legal Risks and Cyber Resilience |
|---|---|---|
| Level 1: Chaotic | Exchange of signed PDF files via email/messengers. Lack of a centralized audit trail. | Critical risks. Impossible to prove file immutability. Vulnerable to human error and data loss. |
| Level 2: Basic | Local ECM, QES applied via plugins. Logs stored in a standard database without protection from administrators. | High risks. Logs can be altered. Lack of real-time OCSP/CRL integration. |
| Level 3: Standardized | Compliance with ISO 15489-1. Automatic QES verification. Protected audit log. | Low risks. Reliable evidentiary base. Partial implementation of access control standards. |
| Level 4: Cyber-resilient | Platform security (e.g., UnityBase EE/DE). Compliance with NIST CSF 2.0. RLS/ACL, log protection. | Minimal risks. Ready for forensic technical examination. Guaranteed non-repudiation. |
Implementing even the most modern ECM does not automatically solve all compliance issues without properly configured records management processes. However, choosing the right platform with built-in architectural security allows for the minimization of legal and cyber risks, ensuring an evidentiary base for every transaction.
FAQ
How to prove in court that an electronic document has not been changed after signing?
The ECM must use a signature format with timestamps and validation of the certificate status at the time of signing (via OCSP/CRL). The system must also maintain an immutable audit trail protected at the platform level, which records every transaction involving the document and cannot be surreptitiously modified.
Which ISO 15489-1 requirements are critical for an evidentiary base?
The standard requires ensuring four characteristics: authenticity, integrity, reliability, and usability. Critical factors include automatic metadata collection at the time of the event and the recording of any permitted changes separately, without compromising the original body of the document.
How does built-in platform-level ECM security differ from plugins?
Built-in security (security by design), as seen in the UnityBase platform, implements access control (RLS, ACL) and logging directly within the system core and ORM. This blocks the possibility of bypassing policies via direct database queries, whereas plugins only protect the system at the user interface level.