TL;DR: Most enterprise platforms ship "audit logs". A regulator does not ask for an audit log. A regulator asks whether the record can be proven, and whether the proof holds when an administrator, an integration, a backup restore, or a determined attacker has had access to the system. AesirX ComplianceOne now ships Immutable Audit Trails: every protected compliance event in the platform is cryptographically linked to a privacy-preserving proof, executed through the AesirX Proof Service on Concordium. No personal data leaves ComplianceOne. The proof layer proves integrity, not content. This article explains why immutability is now a regulatory expectation in Vietnam (with the explicit "ghi nhật ký kiểm toán chi tiết, đầy đủ và bất biến" wording in QĐ 8297/QĐ-BCA-A05), what the difference is between an audit log and an immutable audit trail, how ComplianceOne implements both direct and batched proof modes while preserving per-event verifiability, and what an Integrity Pack actually contains when an auditor or law firm asks the harder question.
This article is written for DPOs, CISOs, compliance managers, internal audit leads, legal counsel, and digital transformation leaders in regulated industries. It is especially relevant for banks, telcos, payment platforms, e-commerce groups, and multinational subsidiaries operating under PDPL and Decree 356, parallel cybersecurity reporting regimes, and international frameworks such as ISO 27001, SOC 2, GDPR, NIS2, and DORA.
The audit log that nobody could prove
A bank in Ho Chi Minh City closes its annual ISO 27001 surveillance audit on a Friday. The lead auditor accepts the access-review evidence, the policy-approval timeline, the incident records, and the data-mapping sign-offs. On Monday a different engagement opens: a complaint by a former customer alleges that their personal data was accessed by a privileged employee outside any authorised process, three months earlier. The DPO pulls the audit log. The relevant access events are there. The actor is named. The timestamp looks consistent. The file looks complete.
Then the lawyer asks the harder question. Can the bank prove that this audit log was not edited, restored from a backup, or assembled retrospectively? Can it prove that nothing was removed? Can it prove that the screenshot the bank just exported is the same record the system held three months ago?
The technical answer, in most enterprise platforms, is that the audit log is hard to alter but it is not provably unaltered. The application enforces append-only writes at the UI layer. The database can sometimes still be touched by privileged operators. Backups can be restored. Exports can be assembled. In the absence of an external anchor, the audit log is an internal claim of integrity, not an external proof of integrity.
“An audit log tells a story. An immutable audit trail proves the story was not rewritten.”
when the stakes get high. It is also what most existing audit-log designs were never built to answer.
Why this is now a Vietnamese regulatory direction, not a marketing concept
Vietnam's regulatory environment is moving toward stronger documentation, stronger evidence, and stronger accountability across the data-protection, cybersecurity, and financial-services regimes at once. Among the clearest signals is Quyết định 8297/QĐ-BCA-A05, which spells out the operational expectation in direct language: "Ghi nhật ký kiểm toán chi tiết, đầy đủ và bất biến". Audit logs that are detailed, complete, and immutable. The same criteria expect API access to be fully logged and reviewed periodically.
That wording is not aspirational. It is part of the standard against which real systems are now expected to perform.
PDPL and Decree 356 add their own evidence pressure. Article 22 of PDPL, with the cross-border mechanics in Decree 356 Articles 18 and 20, expects organisations to maintain accurate transfer records and update them when material changes occur. Article 23 of PDPL with Decree 356 Article 28 expects breach notifications on Mẫu số 08 within the statutory window. Article 27 expects accurate processing registers. None of these articles work if the underlying audit record is provably mutable.
International frameworks reinforce the same direction. ISO 27001:2022 Annex A.8.15 expects that "logging facilities and log information shall be protected against tampering and unauthorised access". SOC 2 Common Criteria CC7.3 expects organisations to "evaluate security events to determine whether they could or have resulted in a failure". GDPR Article 5(2) builds the entire framework on the controller's ability to demonstrate compliance. NIS2 expects evidence of incident detection and response capability. DORA Article 17 expects ICT-related incident records to be preserved and made available to competent authorities.
The market is converging on a posture that an internal audit log is a starting point, not the answer. The question is what comes next.
The difference between an audit log and an immutable audit trail
I find it useful to be precise about three properties when comparing the two designs.
The first property is append-only behaviour. An audit log is append-only when the application enforces that writes only add rows. ComplianceOne already does this for all 39 of its module-level audit pipelines, with sequence numbers and SHA-256 hash chaining on the central case-audit collection. That gives you internal integrity within the platform.
The second property is external anchoring. An audit log is externally anchored when its integrity can be verified outside the platform that produced it. Without external anchoring, internal append-only is a claim that the platform's owner has to be trusted on. With external anchoring, the integrity claim becomes independently checkable by an auditor with no access to the platform.
The third property is selective disclosure. The proof must not require putting personal data, dossier content, or attachments outside the customer-controlled environment. A naive blockchain anchoring design that uploads event payloads is unacceptable for personal data. The proof layer needs to anchor a hash of the canonical event, not the event itself, and it needs to do that without revealing the actor or the data subject in any clear-text way on the public layer.
An immutable audit trail satisfies all three properties at once. ComplianceOne's design implements all three: the existing audit pipelines remain append-only, the new proof layer anchors a privacy-preserving payload externally on Concordium via the AesirX Proof Service, and the on-chain content is reduced to hashes and references. The clear-text record stays inside ComplianceOne where it belongs.
“The proof layer proves integrity, not content.”
That separation is the operating principle.
What ComplianceOne actually protects
ComplianceOne does not promise to anchor every system action that ever happens. That is the wrong design. Many actions are operationally important but do not raise a regulatory question. Anchoring all of them creates noise, cost, and a false sense of completeness.
The platform instead works from a Protected Event Taxonomy. A protected event is one that could matter in a regulator's question, an auditor's sample, a law firm's discovery request, a board's accountability review, or a regulator's compelled-production order. Examples follow.
In the data-protection and regulatory-workflow domain: DPIA created, DPIA approved, transfer assessment approved, authority filing prepared, authority filing submitted, rights request received, rights request fulfilled, deletion completed, lawful basis review completed.
In the incident and breach domain: incident created, incident escalated, severity updated, breach notification prepared on Mẫu số 08, authority notification submitted, remediation sign-off completed, post-incident review approved.
In the governance and evidence domain: policy approved, evidence package generated, board report exported, internal review completed, external auditor export created, control review completed.
In the vendor and outsourcing domain: vendor onboarded, vendor risk approved, contract status changed, remediation task signed off, transfer mechanism recorded.
In the access and administrative domain: privileged access events, role changed, permission granted or revoked, sensitive record opened, attachment downloaded, configuration changed, credential rotated.
In the privacy-monitoring and verification domain: privacy scan completed, monitoring evidence generated, age verification completed, country verification completed, access decision recorded.
The taxonomy ships with default classifications for every event class, and each customer can override on a per-class basis. A bank that cares disproportionately about privileged-access events can elevate them to direct-proof tier. A retailer that runs millions of session events daily can leave login and logout events on batched proofing. The default ships sane; the override exists for organisations that have made specific risk decisions.
One event, one proof relationship, two delivery modes
The product invariant is that every protected event has its own proof relationship. That is the headline customers, regulators, and auditors should hold us to.
The implementation behind that invariant uses two delivery modes.
The first is direct proof mode. A protected event triggers its own proof execution. This is the right mode for high-value events: approvals, breach notifications, authority filings, board exports, privileged-access actions, vendor risk sign-offs. Each event becomes its own anchored receipt. The cost per event is higher, the assurance per event is the strongest.
The second is batched proof mode. Multiple protected events are grouped into a Merkle tree. The Merkle root is anchored on Concordium once per batch. Every leaf in the tree, meaning every individual protected event, receives an inclusion path. With the leaf hash, the inclusion path, and the anchored root, anyone can verify that the specific event was part of the anchored batch. This is the right mode for high-volume operational classes: sessions, attachment access, ROPA edits, status changes, routine monitoring outputs.
The product invariant holds in both modes. In direct mode the proof relationship is a single anchored receipt. In batched mode the proof relationship is the leaf hash plus the inclusion path plus the anchored root. Either way, the regulator's question "can you prove this specific event was recorded and not later altered" gets a verifiable answer per event.
“Anchor what matters, prove what matters, control the cost.”
The customer chooses the trade-off per event class through the per-org Protected Event Taxonomy. The platform handles the operational mechanics behind that choice.
Why Concordium
Concordium is not an arbitrary blockchain choice. It is one of the few blockchains designed from the ground up for regulated identity flows and zero-knowledge-proof-capable verification.
For a compliance platform, three Concordium properties matter directly.
The first is the identity-native architecture. Where most public blockchains were built without identity in mind, Concordium was. That alignment matters when an audit trail involves regulated actors, regulated decisions, and regulated organisations.
The second is the privacy-preserving zero-knowledge-proof capability. We do not need to expose what was decided, who approved, or what data subject the event referenced. The proof layer can confirm integrity without those details ever leaving ComplianceOne.
The third is the regulatory-environment fit. Concordium's design choices are coherent with how a serious regulator thinks about evidence: identity is meaningful, privacy is preserved by construction, anchored facts are verifiable, and the architecture does not assume open public disclosure of operational data.
This is also consistent with how AesirX already uses Concordium in adjacent products. In AesirX Consent Management Platform, Concordium underpins privacy-preserving Verify and Access flows including age and country verification. The new Concordium ID app strengthens the same direction with modern identity-based proof flows. Privacy Scan and Privacy Monitoring already produce proof-oriented transaction trails. Immutable Audit Trails in ComplianceOne extend the same architectural direction into regulated enterprise compliance operations.
The result is one consistent proof story across the AesirX product portfolio, with Concordium as the trust and proof layer and ComplianceOne as the operational compliance layer.
No personal data on-chain. No exceptions.
This is the design rule I will not bend.
The proof layer never receives names, contact details, raw case content, attachments, dossier content, free-text rationale, or identity attributes beyond what the integrity proof strictly requires. The actor identity in the canonical proof payload is reduced to a hash. The data subject identity is never present. The object identity is reduced to a hash. The change delta is reduced to a hash. The schema version is part of the hash so a v2 payload cannot collide with a v1 payload over the same event.
The customer's operational records remain inside ComplianceOne, in the customer-controlled environment, under the customer's RBAC, retention, and access controls. Concordium sees a hash and a receipt reference. That is enough to prove that a specific canonical event existed at a specific moment and was not later altered, without ever revealing what the event contained.
This is what makes the architecture safe to deploy under PDPL Article 39 (data localisation considerations), Decree 13 procedural rules, GDPR Article 5(1)(c) data-minimisation, and ISO 27001 Annex A.8.10 information-deletion expectations at once. The proof layer's privacy contract is part of the design, not bolted on.
Integrity Packs: turning proof into something an auditor can actually use
A proof system has to produce something an auditor, a law firm, a DPO, an internal audit team, a board committee, or a regulator can read.
ComplianceOne produces an Integrity Pack for that. The pack covers a date range and an optional module filter and contains, at minimum: the period of coverage, the count and breakdown of protected events, direct-proof and batched-proof statistics, the inclusion paths for batched events, the proof receipt references, the chain verification references, the verification results, the redacted machine-readable JSON manifest, and the human-readable PDF summary.
The pack is generated by extending the platform's existing evidence-pack flow rather than creating a parallel concept. That matters operationally. Customers who already use ComplianceOne's evidence-pack export for surveillance audits get the immutable-audit-trail summary as part of the same pack. The auditor does not have to learn a new artifact.
The act of generating the Integrity Pack is itself a protected event. The pack therefore carries a proof reference for its own creation. An auditor can verify the pack's own integrity, not just the integrity of the events inside it. That recursion is intentional.
For an auditor reading the pack, the operational answer flows directly:
- Here is the period.
- Here is the protected event.
- Here is the receipt reference.
- Here is the verification result.
- Here is the chain reference if you want to corroborate independently.
That is the kind of evidence base modern compliance has been moving toward for years. We now make it concrete.
Real workflows under the new design
I will walk through three.
The first is a DPIA approval. A privacy team prepares a DPIA. A DPO reviews and approves. Under the new design, the approval event is classified Tier A in the default taxonomy. ComplianceOne builds the canonical proof payload (no personal data, only canonical event metadata and hashed deltas), submits it through the AesirX Proof Service, and stores the proof receipt against the event. Six months later, an auditor asks whether this DPIA was approved on the date the platform claims. The DPO does not have to argue. The Integrity Pack contains the receipt and the verification reference. The chain confirms.
The second is a breach notification on Mẫu số 08 within the PDPL Article 23 statutory window. The DPO assembles the notification, the legal counsel approves the wording, the senior responsible officer signs, the form is submitted via the appropriate channel. Each of those is a protected event. Each one has its own proof relationship in direct mode because the regulatory weight of these events justifies the assurance. The Integrity Pack later shows the entire breach-response timeline as a chain of proof references, not a chain of email screenshots.
The third is vendor risk approval. A high-risk processor finishes onboarding. The risk approval gate is a Tier A protected event. Three years later the contract is reviewed. The risk approval, the subsequent reassessments, the contract amendments are all proof-linked. The internal audit function or the regulator's inspectors have a defensible record without requiring the original DPO or risk owner to still be in their seat.
The pattern is consistent across these scenarios. The platform produces operational records the way it always did. The new layer turns the most regulator-relevant of those records into cryptographically verifiable evidence without changing how the user works.
Operational shape: optional, configurable, and grounded in cost control
Three properties make this deployable in practice rather than aspirationally.
The first is that Immutable Audit Trails is an optional add-on. The 39 existing audit pipelines in ComplianceOne keep working unchanged. Customers who do not enable the add-on see the platform exactly as it is today. Enabling the add-on adds a layer; it does not replace the layers underneath.
The second is per-org configurability. The Protected Event Taxonomy ships with sensible defaults and is overridable per event class. Privacy controls (whether the actor IP and user-agent are logged, whether privileged-access events are proofed) are explicit toggles. Organisational scope choices (whether a parent group runs the proofing for child orgs or each org runs independently) are explicit.
The third is commercial control. The platform meters proof usage and operates on a prepaid credit model. Customers buy credit packages in fixed sizes. Hard caps and warning thresholds prevent runaway proofing. Auto-pause on cap protects the budget without ever blocking the underlying audit write. The proof layer is best-effort; the source audit is canonical and always succeeds. A pending proof is never a reason for a workflow to fail.
That last point is worth restating. The user workflow is never blocked by the proof layer. The audit write commits, the proof is queued, and confirmation arrives asynchronously. If the AesirX Proof Service has a transient outage, the queue absorbs the load and drains when service is restored. The architecture is designed to make this invisible to the people doing the actual compliance work.
The shift
What changes for compliance teams when the audit trail itself becomes provable?
For the DPO, the shift is from defending integrity to demonstrating it. When a regulator or a complainant tests whether a record was assembled retrospectively, the DPO has a verifiable answer rather than a procedural assurance.
For the CISO, the shift is from "we have logs" to "we have evidence". The Annex A.8.15 expectation about protecting log information against tampering becomes provable, not just policy.
For internal audit, the shift is from sampling integrity to verifying it. The Integrity Pack converts what used to be a manual evidence-assembly exercise into a single export.
For external auditors, the shift is from trusting the platform owner to verifying the chain. Concordium acts as the independent verifier; the platform is no longer the only party attesting to its own integrity.
For boards and risk committees, the shift is from "we run a system" to "we operate within a defensible evidence architecture". The reporting story changes accordingly.
“The future of compliance is not more paperwork. It is better proof.”
The next generation of compliance platforms will be judged by whether their audit trails are merely descriptive or actually defensible. ComplianceOne now ships the second.
Closing thought
Immutable Audit Trails are not the end state of compliance technology. They are a step toward an evidence architecture that is fit for the regulatory direction of the next decade in Vietnam, in Southeast Asia, in the EU, in the UK, and in every jurisdiction where regulators are asking organisations to prove rather than declare.
For now, the deployment posture is straightforward. If your organisation already operates ComplianceOne, you can enable the add-on per organisation, configure the taxonomy to your risk appetite, purchase a credit package matched to your event volume, and start producing Integrity Packs that hold up under regulator-grade scrutiny.
If you are still operating on shared drives, email approvals, and screenshots, the gap to a defensible evidence architecture is no longer a technology problem. The platform exists. The proof layer exists. The decision is operational.
If you want to see what an Integrity Pack actually contains, or how the Protected Event Taxonomy maps onto your specific industry's protected events, the team at AesirX is happy to walk through it. Visit https://aesirx.io/compliance-one for the current product page or get in touch for a working session against your own taxonomy.
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO @ AesirX.io
Laws and standards referenced
- Vietnam: Law on Personal Data Protection (PDPL), Articles 22, 23, 27, 39
- Vietnam: Decree 356/2025 (Decree 356), Articles 18, 20, 28, with Mẫu số 03a / 03b / 08
- Vietnam: Quyết định 8297/QĐ-BCA-A05 (security criteria for transmission activities, immutable audit log requirement)
- Vietnam: Decree 13/2023, Decree 53/2022, Law on Cybersecurity (where cybersecurity reporting overlaps)
- International: ISO 27001:2022 Annex A.8.10 and A.8.15
- International: SOC 2 Trust Services Criteria CC7.3
- International: GDPR Article 5(1)(c) and 5(2)
- International: NIS2 incident detection and response evidence expectations
- International: DORA Article 17 ICT-related incident reporting
Disclaimer
This article is operational guidance from a platform vendor, not legal advice. Specific regulatory positions, especially around PDPL Articles 22, 23, 27, the Decree 356 procedures, and the QĐ 8297/QĐ-BCA-A05 criteria, should be confirmed with qualified Vietnamese counsel for your specific industry and supervisor.
