How Are Version and Audit Trail Preserved in E-Signed Report Revisions?

What should be done when an e-signed report is revised?

Do not modify the signed file. Open a new revision with the reason for the change; preserve the previous signed version, its digest value and the verification evidence. Pass the new version through technical approval again and sign it, and record the link between the two versions in the audit trail.

Thus the current report is easy to find; the old copy does not silently disappear or look like the new version. The e-signature supports the integrity of the signed version. When the content changes, instead of carrying the old signature to the new file, a new signature cycle is required.

With what structure is the revision record preserved?

Short answer: under an unchanging report identity, every published version must be a separate, immutable object; the versions must be linked to each other with “previous” and “supersedes” links.

ISO/IEC 17020:2026 is the current edition that introduces new provisions on the control of data and information for inspection bodies. Its counterpart in software is not to store the report file alone, but also to keep under control the record, decision, access and version links that produce it. The organization's applicable requirements must additionally be evaluated against its own scope and transition plan.

Which events should the audit trail record?

Short answer: the information “who changed what, when?” alone is not enough. The before and after of the change, its justification, the affected version, the authorization result and, if the operation fails, the error state must be recorded together.

• Opening of the revision request, its justification and the source record
• Creation of the draft and the fields carried over from the previous version
• Field and annex changes; secure references for the previous and new values
• Technical review, return, approval and segregation-of-duties checks
• The digest value of the file submitted for signature and the signature operation result
• The certificate, revocation status, time stamp and the result of the verification policy used
• Publication, portal visibility, download and external distribution events
• The old version transitioning to the “superseded by a new revision” status

The audit trail should carry the application user, reliable time, event type, object identity, result and justification fields. Administrator privileges must not grant the right to silently rewrite history; a log entry that needs correction must be explained with a new counter-record. In events containing personal data, access must be restricted by role and need.

How are the old and new signatures verified?

Each version must be verified independently. Even if the old version's signature is valid, this does not mean the version is still current; the new version being current does not invalidate the old signature evidence either.

The BTK explains that the secure electronic signature makes it possible to determine whether the signed data was subsequently altered; and that the verifying party must check the qualified certificate, its validity or revocation status and usage restrictions. ETSI EN 319 102-1 V1.4.1 defines the validation process, while ETSI TS 119 102-2 V1.4.1 defines the structured reporting of the validation result. The application result must distinguish at least valid, invalid and indeterminate/insufficient evidence ; it must not count a service failure as a success.

1. The file digest and signature container of the requested version are matched.
2. Signature integrity, certificate chain, status at the time of signing and usage limitations are evaluated.
3. If any, the time stamp and long-term validation evidence are checked.
4. The result is linked to the version record with the validation time, policy/version and error description.
5. A separate business rule determines the current, superseded, cancelled or draft status.

What do the time stamp and archive package protect?

The time stamp helps prove that the electronic data existed before a certain time; on its own it is not version management or archiving. For future validation, the signed file, certificate chain, revocation status evidence, time stamp, validation report and the applied policy must be preserved together.

The BTK Electronic Signature Usage Profiles Guide distinguishes validation-data-bearing, long-term and archive electronic signature formats. The archive strategy should also treat the renewal of evidence to be done when cryptographic methods or policies become outdated as a recorded operation. Renewal does not change the old report content; it adds a new, dated protection evidence to the existing evidence package.

How is the old version shown on the portal and in distribution?

The current revision should be highlighted; the old version should remain findable for the authorized user and explicitly show the “superseded by a new revision” status.

• An old URL or verification record must not silently download the new file.
• Show the user the report identity they are viewing, its revision, publication date and currency status.
• Provide a secure link to the current revision; do not disclose the justification of sensitive changes to everyone.
• If notification or recall is required for recipients of the old copy, create recipient-based tasks.
• A distribution failure must not be closed as if the delivery had been made.

For the fields of the public verification view the report QR verification page guide .

How should authorization and personal data security be established?

The authorities to open a revision, change content, give technical approval, sign, publish and access history must be bound to separate roles. The KVKK requires technical and administrative measures to prevent unlawful access to personal data and to ensure data protection; rather than a single security model, it requires measures proportionate to the risk of the work and the data.

Therefore the audit trail must not be a file everyone can read. The authorization matrix, strong authentication, access logs, immutable backups, restore tests and incident investigation procedures must work together. The retention period must be determined by the report type, contract, applicable legislation and the purpose of data processing, and must not be treated as universal and indefinite.

Which scenarios should be tested in a VizyonTech pilot?

the Vizyon Periyodik solution in a single report family, test negative scenarios alongside the normal revision. The success criterion is not merely producing a new PDF, but the system preventing the publication of the wrong revision and a closure with missing evidence.

1. Try to modify a signed file in place; the system should require a new revision to be opened.
2. Send it for approval without a change justification; the workflow should stop.
3. Change the file digest before signing; the signing operation should be cancelled.
4. Examine the verification result when certificate status cannot be retrieved; the result should remain indeterminate.
5. Open the verification page of an old revision; it should show that it is not current and the link to the new revision.
6. Track the notification task and delivery proof for a distributed old copy.

For the broader approval and e-signature architecture guide to digitizing the periodic inspection process as well.