VPN Audit & Compliance

Cross-jurisdictional analysis of audit-log requirements for the medOS VPN control plane (Thailand, Japan, Philippines, EU; UK appendix). Drives the design of the audit log schema, retention policy, immutability strategy, and data-residency topology for the new services/identity-vpn service.

Status: research draft. Not legally reviewed. See §6 for items flagged for counsel.

---

1. Executive summary

Scope. services/identity-vpn is a NestJS WireGuard control plane + WebAuthn identity layer. It mediates VPN access for hospital staff and cross-hospital admins to internal medOS microservices and offers a separate TLS tunnel for patient telehealth. The audit events it must produce: vpn.connect, vpn.disconnect, peer.config.issued, peer.config.revoked, acl.changed, auth.failed, mfa.challenge.result, passkey.enrolled, plus device-context attributes (BYOD / shared workstation / hospital laptop).

Key conclusions.

1. Keep the VPN audit log in a separate logical collection (vpn_audit_events) from the EHR audit log, but co-locate it in the same MongoDB cluster, same replica set per jurisdiction, and join via a shared correlationId and subjectRef index. Rationale: the VPN log is operationally a security/cybersecurity log (NIS2, BSI, ISO 27001 controls), while the EHR audit log is a data-protection-compliance log (GDPR Art. 30/32, APPI, PDPA, DPA). They have different retention, different fields, different reviewers, and different replication rules — but every patient-data access via VPN must be traceable from EHR audit back to the originating VPN session.

2. Adopt the strictest envelope. No regulator’s minimum should drive the design; we engineer to the maximum of every jurisdiction we operate in. Concretely:

   • Retention: 6 years baseline for VPN events, 10 years for VPN events that correlate to access of patient records, 20 years for events tied to records of minors in jurisdictions that anchor retention to age of majority.
   • Immutability: append-only collection with per-event Ed25519 signature and hourly Merkle-root anchoring to a separate “audit ledger” collection. Not full blockchain — just hash-chained snapshots, exportable to off-site WORM.
   • Time precision: UTC, millisecond, with monotonic sequence number per node to survive clock skew.
   • PII minimisation in the log itself: store subjectRef (opaque ID into patient/staff registry), not name; store srcIpHash (HMAC), retain raw IP only in the encrypted side-table that NIS2 forensics requires.

3. Data residency. Per-region MongoDB cluster, per-region S3 (or equivalent) WORM archive. JP and EU data must not leave their region without an explicit transfer mechanism (APPI consent / GDPR Chapter V SCCs). A central SOC console reads aggregate metrics + pseudonymised event counts only. Raw audit log content stays in-region.

4. Patient disclosure. Under EHDS Art. 10 (right to know who accessed), Thailand PDPA s.30 (right of access), and (likely) APPI’s disclosure-of-records right, patients can demand an access trail. We MUST be able to render a patient-readable “who looked at my chart” report. For VPN, that means we must persist the subjectRef = patientId linkage from EHR audit to a VPN session, then join the staff-side fields (role, facility, timestamp) for display, while suppressing internal IPs and device fingerprints.

5. What this implies for the schema and topology is summarised in §5.

---

2. Thailand — Personal Data Protection Act (PDPA) B.E. 2562

2.1 Applicable law and supplementary guidance

• Personal Data Protection Act B.E. 2562 (2019) — primary law. Fully in force 1 June 2022.
• Section 37 — security obligation on data controllers; requires “appropriate security measures” and the existence of an examination/audit process for destruction/erasure.
• Section 39 — Records of Processing Activities (ROPA).
• Section 40 — security obligation on processors, including “preparation and maintenance of records of personal data processing activities.”
• PDPC Notification on Security Measures B.E. 2565 (2022) — supplementary guidance on minimum security measures including access controls and logging.
• National Health Act B.E. 2550 (2007), Section 7 — personal health information confidentiality; predates PDPA but still operative.
• Ministry of Public Health (MoPH) Notification on the Operation of Medical Records (B.E. 2564 / 2021) — sets electronic medical record handling expectations for hospitals.
• Medical Council of Thailand (แพทยสภา) Regulation on Medical Records — minimum retention of medical records is generally interpreted as 5 years from last patient visit (case file standard); some hospital networks treat 10 years as best practice. The PDPA itself imposes no fixed minimum.

⚠ Legal review needed: The PDPC has not (as of 2026-05) published a sector-specific “Healthcare Audit Log Notification.” Retention guidance for audit logs is therefore derived by analogy from (a) Section 39 ROPA + (b) MoPH medical-records rules. A Thai healthcare regulatory lawyer should confirm whether 5-year medical-record retention extends to access logs.

2.2 Audit log requirements

PDPA does not explicitly mandate a per-event access log. It mandates:

• Existence of security measures including access control (s.37(1)).
• A “system for examination of deletion/destruction” (s.37(3)) — implies the controller must know when records were last accessed.
• ROPA fields (s.39) including categories of recipients and security measures used.

In practice, logging is implied by the accountability and security obligations and is the only realistic way to demonstrate compliance during a PDPC investigation.

2.3 Retention period

Class	Minimum	Recommended	Notes
ROPA	duration of processing + reasonable period	life of processing + 5 years	s.39 ongoing requirement
Medical records	5 years (MoPH / Medical Council)	10 years	from last visit
Audit log of access to medical records	not specified in PDPA	align with medical records: 10 years	conservative reading
Breach notification records	not specified	5 years	aligns with PDPC investigative window

2.4 Immutability / integrity

PDPA s.37 requires “appropriate” security measures but does not prescribe WORM, hash chains, or signed logs. Industry practice in Thai hospitals references ISO 27001 and (increasingly) ISO 27799. We assume “tamper-evident” satisfies “appropriate.”

2.5 Mandatory log fields (derived)

PDPA never enumerates audit-log fields. Derived from s.39 + ISO 27799 + MoPH expectations:

• actor (staff ID), role, facility
• action (login, record-view, record-modify, export)
• target (patient ID or record ID)
• timestamp
• result (success/failure)
• source (workstation ID, IP)

2.6 Disclosure obligations

Section 30 of PDPA grants the data subject a right of access to their personal data and the sources from which it was obtained. The PDPC has not formally extended this to “who accessed my record at the hospital” — but a reasonable reading combined with s.31 (right to receive information about disclosures to third parties) supports patient access to a sanitized version of the access log.

⚠ Legal review needed: Whether s.30/s.31 forces a hospital to expose VPN-session metadata to a patient on request.

2.7 Cross-border restrictions

• Section 28 — cross-border transfer requires either (a) PDPC-determined adequacy of the destination, (b) appropriate safeguards (BCRs / SCCs filed with PDPC), or © one of the listed derogations (consent, contractual necessity, vital interests, etc.).
• Thailand has not published an adequacy list; consent or BCRs/SCCs are the realistic routes.
• The PDPC issued notifications on cross-border transfer mechanisms in 2023.

2.8 What this means for services/identity-vpn

• Hospital-issued laptop and shared-workstation VPN sessions accessing Thai patient data → log stays in TH region.
• Cross-hospital admin connecting from Singapore to Thai backend → that’s a cross-border access, and the access log entry must record the source country. Consent or BCR justification must be in place before deployment.
• Patient telehealth tunnel can be the same VPN service but must produce a separate audit subtype (vpn.connect.patient) since patient telehealth connections imply different consent and different retention rules.

---

3. Japan — Act on the Protection of Personal Information (APPI) and MHLW Guidelines

3.1 Applicable law and supplementary guidance

• APPI (個人情報の保護に関する法律) — most recent amendments effective April 2022 and April 2023.
• Article 2(3) — special-care-required personal information (要配慮個人情報) explicitly includes medical history.
• Article 28 — cross-border transfer requires consent (with prescribed information disclosure: destination country, destination’s PI-protection regime, transferee’s measures) OR adequacy (EU/UK only at present) OR contractual safeguards meeting PPC standard.
• MHLW “Guidelines for the Safety Management of Medical Information Systems” Version 6.0 (2023) (医療情報システムの安全管理に関するガイドライン 第6.0版) — primary operational standard.
• METI / MIC joint guideline for cloud/service providers handling medical information (医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 2.0) — known as the “3省2ガイドライン” (3-ministry, 2-guideline) framework.
• Medical Care Act (医療法), Article 24-2 — paper medical-record retention ≥ 5 years (from last entry). The MHLW Notification permitting electronic preservation extended this to e-records under defined conditions.

3.2 Audit log requirements

MHLW Guideline v6.0 explicitly requires medical information systems to:

• Record an audit trail automatically for access to medical information.
• Cover create / read / update / archive / delete operations on records.
• Make logs reviewable on a defined periodic basis by an internal information-security officer.
• Protect logs from tampering and unauthorised modification.

3.3 Retention period

Class	Minimum	Recommended	Source
Medical records	5 years (paper)	5 years (e-record)	Medical Care Act Art. 24-2
Operation logs / access logs	not explicitly fixed in MHLW v6.0	commonly implemented as ≥ 5 years to match the underlying record	MHLW v6.0 + industry practice
Breach response records	3 years	5 years	PPC guidance

⚠ Legal review needed: MHLW v6.0 itself does not state an explicit log retention number; the operative norm “log-retention ≥ record-retention” is industry practice. Confirm with Japanese healthcare counsel before locking the schema to a number.

3.4 Immutability / integrity

MHLW v6.0 demands “tamper-prevention” but does not mandate hash chains or WORM. The guideline emphasises that the combination of technical, organisational, and physical safeguards must make undetected tampering implausible. Hospitals with the JAHIS or JAMI certifications meet this through ISO 27001-style controls.

3.5 Mandatory log fields

Derived from MHLW v6.0 and JAHIS standards:

• User ID (and reason / role if accessed under a delegated authority)
• Patient ID (medical record number)
• Operation type
• Date/time (JST; precision ≥ 1 second)
• Source workstation
• Justification for access (in “break-glass” scenarios — strongly implied even when not explicit)

3.6 Disclosure obligations

APPI Articles 33–35 (post-2022 numbering) grant data subjects rights of disclosure, correction, and cessation of use. Hospitals routinely provide access logs to patients on request when the patient asserts a concrete concern (e.g., suspected unauthorised access). The right to a routine, on-demand “who viewed my record” report is not an explicit APPI requirement but is increasingly expected.

3.7 Cross-border restrictions

APPI Art. 28 is the binding rule. Key consequences for identity-vpn:

• Japan does not currently recognise Singapore, Thailand, or the Philippines as adequacy jurisdictions. Only the EU/UK have mutual adequacy with Japan.
• Replicating Japanese VPN audit logs to a Singapore-hosted central SOC console requires either patient/staff consent meeting Art. 28 disclosure requirements, or a contractual safeguard regime that PPC has determined to be equivalent.
• Pseudonymised aggregate metrics (counts, p95 latency, rule-hit counts) without identifiers can flow out without Art. 28 burden, but the line between “pseudonymised” and “personal information” is narrow under APPI — restoration to identification on the source side still keeps the data within APPI scope.

3.8 What this means for services/identity-vpn

• Dedicated MongoDB replica set in ap-northeast-1 (Tokyo).
• Audit log content does not replicate cross-region.
• Central console gets either (a) consent-backed access, or (b) only counts/aggregates pushed by a per-region “metrics exporter” that strips identifiers.
• VPN session logs must record jurisdiction = JP and any access to JP patient records from a non-JP source IP is a critical-severity event that the SOC must review.

---

4. Philippines — Data Privacy Act 2012 and DOH/NPC ecosystem

4.1 Applicable law and supplementary guidance

• Republic Act No. 10173 — Data Privacy Act of 2012 (DPA) — primary law.
• NPC Circular 2023-06 “Security of Personal Data in the Government and Private Sector” — issued December 2023, effective 30 March 2024, compliance deadline 30 March 2025. Supersedes NPC Circular 16-01.
• NPC Advisory 2017-03 on PIA for sensitive personal information.
• DOH Joint Administrative Order 2016-0002 / NPC-DOH Joint Memorandum 2016 establishing the Health Privacy Code.
• National eHealth Privacy Framework (DOH, original 2015, revised 2023).
• PhilHealth Circulars governing eClaims data submission; impose retention on financial-claim records (typically 5 years per BIR overlap, 10 years for PhilHealth-specific records).
• Republic Act 7875 (PhilHealth law, as amended by RA 11223 Universal Health Care Act) — sets retention for contribution and benefit records.

4.2 Audit log requirements

NPC Circular 2023-06 is the single most prescriptive instrument on logs across our four jurisdictions. It explicitly:

• Requires PICs and PIPs to maintain logs of personal-data processing activities.
• Distinguishes “general system logs” from “security logs” (authentication attempts, security incidents). The latter must be retained longer.
• Requires logs to be reviewed periodically (quarterly is the typical implementation interpretation).
• Requires logs to be backed up and archived, with backups potentially retained shorter and archives longer.
• Requires logs to support digital forensics during incident response.

The Health Privacy Code and NPC eHealth Framework reinforce that hospital information systems require audit-log capability, and PIAs must cover logging design.

4.3 Retention period

Class	Minimum	Recommended	Source
Security logs (auth attempts, incidents)	“longer than general system logs” — NPC implementation guidance treats this as ≥ 2 years for general logs	6 years	NPC Circular 2023-06; common DOH PIA reviewer expectation of 5–7 years
General system logs	≥ 2 years (operational best practice cited in NPC FAQ)	2 years	NPC FAQ on Circular 2023-06
PhilHealth claim records	10 years	10 years	PhilHealth implementing rules
Medical records (paper or electronic)	not fixed by DPA; clinical practice norm ≥ 15 years for adults, until age of majority + 10 for minors	15 years adult, 25 minors	Clinical practice + DOH expectations

⚠ Legal review needed: “Longer than general system logs” is not a number. The 6-year recommendation here is engineering judgment, not regulation. Confirm with Philippine counsel.

4.4 Immutability / integrity

NPC Circular 2023-06 requires:

• Logs to be “protected against unauthorised modification.”
• Backup mechanisms.
• Hash-based or equivalent tamper detection is not explicitly mandated but is widely understood as the obvious way to satisfy “unauthorised modification” controls.

4.5 Mandatory log fields

From NPC Circular 2023-06 and DOH eHealth Framework:

• Identity of the user / system
• Date and time
• Activity description
• Affected data subjects (where determinable)
• Result of the activity
• Source IP / device
• For security logs: authentication method used, MFA challenge result

4.6 Disclosure obligations

• DPA Section 16 — right to access, right to know recipients.
• DOH Health Privacy Code reinforces the patient’s right to know who accessed their record.
• NPC has issued multiple advisory opinions confirming that hospitals can be asked to produce access logs to patients in dispute scenarios.

4.7 Cross-border restrictions

• DPA Section 21 — PICs retain responsibility for data transferred internationally, but there is no adequacy regime. Transfers permitted with consent or appropriate contractual measures.
• NPC has been receptive to BCR-style frameworks.
• The Philippines is generally the most permissive of our four jurisdictions for cross-border replication, provided the PIA documents the safeguards.

4.8 What this means for services/identity-vpn

• Per-region cluster in ap-southeast-1 (PH demo currently runs here).
• Implement the explicit “general vs. security log” split that NPC Circular 2023-06 expects — operationally this is achieved by tagging each event with class: 'security' | 'system' and applying different retention TTLs.
• Quarterly automated audit-log review report — PHP can plug into our existing admin UI under /admin/audit-review (not yet built).
• A patient-facing “who accessed my record” view must surface a Filipino-locale string and accept the patient’s RA-10173 access request workflow.

---

5. European Union

The EU stack here is genuinely additive: GDPR is the floor, NIS2 adds cybersecurity-specific duties, EHDS adds health-data-specific access-logging duties, eIDAS 2.0 reshapes the identity layer, and HDS/C5/KHZG/ISO 27799 set the operational expectations in specific Member States.

5.1 GDPR

Article 30 (Records of Processing Activities) — applies always; ROPA must list categories of data, recipients, security measures, transfer mechanisms.

Article 32 (Security of Processing) — requires “appropriate technical and organisational measures.” Logging is implied (and EDPB consistently treats it as expected). The 2023 EDPB Guidelines on right of access (01/2022) clarify that logs evidence compliance.

Articles 33–34 (Breach Notification) — 72 hours to supervisory authority; notification to data subjects if “high risk.” For breach forensics you need detailed access logs going back at least several years.

Article 9 (Special Categories) — health data is special-category; biometric data is special-category when processed for unique identification. WebAuthn passkeys with on-device biometric unlock are an interesting edge case: the biometric template never leaves the device (it’s only used to unlock the local key store), so the relying party (medOS) is generally not “processing biometric data for unique identification” under EDPB’s reading. The relying party is processing the cryptographic public key only. Document this in the DPIA.

⚠ Legal review needed: Whether tap-badge readers on shared clinical workstations cross into “biometric processing.” If the badge stores a biometric template (e.g., for ward-staff fingerprint+badge readers), Article 9 fully applies and explicit consent under Art. 9(2)(a) plus a stronger lawful basis must be established.

Retention for audit logs under GDPR: not numerically fixed. Common Member-State practice:

• DE / BSI: 3 years minimum for general security logs, 6 years for logs that touch health records.
• FR / CNIL: 6 months baseline for connection/access logs in general business contexts; 3 years for health-context per HDS expectations.
• Pseudonymised health-related logs may be retained up to 20 years for secondary use under Member-State exceptions.

5.2 NIS2 Directive (Directive (EU) 2022/2555)

In force across Member States from 18 October 2024. Healthcare is Annex I (essential entity).

• Article 21 — risk-management measures. ENISA implementing guidance is explicit that MFA is expected for privileged accounts and “highly recommended” for all access to network and information systems. Healthcare entities should treat MFA as effectively mandatory.
• Article 21 also requires logging of access, with audit trails sufficient for incident reconstruction.
• Article 23 — incident reporting:
  • 24 hours — early warning to CSIRT/competent authority (significant incidents).
  • 72 hours — initial incident notification.
  • 1 month — final report.

NIS2 logs must be exportable to the national CSIRT in a structured form with timestamps, source/destination, action, result, and policy applied.

5.3 EHDS (Regulation (EU) 2025/327)

In force 26 May 2025. Phased application:

• 26 March 2029 — patient summaries, e-prescriptions, e-dispensation.
• 26 March 2031 — imaging, lab results, discharge summaries.

EHDS-relevant articles for audit:

• Article 8 — patient’s right to view who has accessed their electronic health data.
• Articles 14–16 — EHR system manufacturers must implement an “EU logging software component” (a harmonised, certified module) that records access events.
• Article 50–51 — secondary-use access to health data via Health Data Access Bodies; all such access logged.

EHR systems sold or put into service in the EU must:

• Pass conformity assessment for logging + interoperability.
• Carry a CE marking and EU Declaration of Conformity.
• Be registered in an EU-wide database.

For our VPN service the EHDS-relevant question is not whether identity-vpn is itself an “EHR system.” It almost certainly is not (it’s an authentication and tunnel control plane, not a record-keeping system). But every access to an EHR via the VPN must be loggable in a way that lets the EHR’s mandated EHDS log produce the EHDS-required citizen-facing access view. So our correlationId design must propagate into the EHR access log.

5.4 eIDAS 2.0 (Regulation (EU) 2024/1183)

In force 20 May 2024. EU Digital Identity Wallet (EUDI Wallet) mandate.

• Member States must issue EUDI Wallets within 24 months of relevant Implementing Acts.
• Private service providers required to perform “strong user authentication” — explicitly including healthcare — must accept the EUDI Wallet as an authentication method.

Implications for identity-vpn:

• For patient-facing tunnels in the EU, accepting the EUDI Wallet as one passkey provider becomes mandatory once the relevant Implementing Acts apply.
• The audit log schema must record the authentication method (WebAuthn local passkey, EUDI Wallet attestation, hospital-issued device cert) as a distinct field — not just “MFA passed.”
• Wallet-attested identifiers may include qualified electronic attributes (e.g., physician licence number). When present, store them under actor.qualifiedAttributes[] — do not dump them into a generic notes field.

5.5 HDS (Hébergeur de Données de Santé) — France

Mandatory for hosting French patient health data. The new HDS framework (decree of 26 April 2024, in force 16 May 2024) — informally “HDS 2.0” — is built on ISO 27001 + GDPR + additional health-specific controls.

Audit-relevant HDS requirements:

• Traceability of all access to health data by hosting teams — operator access logs are an explicit certification item.
• Logs must be retained for the duration of the hosting contract + a defined post-contract period.
• HDS auditors test for log integrity in the on-site audit.

identity-vpn deployed in France must either be operated by an HDS-certified host or the hospital itself, with the audit-log archive sitting on HDS-certified storage.

5.6 C5 (Germany — BSI Cloud Computing Compliance Criteria Catalogue) and KHZG

C5 is the BSI’s cloud security catalogue, widely required for German hospital cloud workloads. C5 controls include detailed logging, log integrity, and SIEM integration requirements.

KHZG (Krankenhauszukunftsgesetz, Hospital Future Act, 2020) — provided €4.3bn for hospital digitisation, mandated that 15 % of every supported project goes to IT security. Hospitals receiving KHZG funding must demonstrate:

• ISO 27001 or BSI-Grundschutz baseline.
• Audit-logging capability conforming to § 75c SGB V (statutory IT security duty for hospitals).

For identity-vpn deployed in Germany: align with BSI IT-Grundschutz module ORP.4 Identity and Access Management and module DER.1 Detection of Security Incidents — both call for retained, reviewable logs.

5.7 ISO 27799 and ISO 27789

• ISO 27799:2016 (revised 2025) — Information security controls in health based on ISO/IEC 27002. Section 12.4 requires a secure audit record for every read/create/update/archive of personal health information.
• ISO 27789:2021 — Audit trails for EHRs. Specifies the minimum field set:
  • Uniquely identify the user.
  • Uniquely identify the subject of care.
  • Identify the function performed.
  • Date and time.

Plus required trigger events: record creation, view, update, archival, disclosure, point-of-care access, security-administration changes, etc.

We design the schema to be a superset of ISO 27789’s minimum fields so the same log feeds the EHR audit and the VPN audit with consistent shapes.

5.8 What all of this means for services/identity-vpn (EU)

• Each EU deployment needs a region-local cluster (current planning: eu-central-1 or eu-west-3).
• Audit log must include authnMethod, walletAttestation?, qualifiedAttributes[] to satisfy eIDAS 2.0.
• NIS2 incident-reporting CLI/API must be able to extract logs for the relevant 24h/72h/30d windows and emit a structured CSIRT-format report.
• HDS deployment in France requires HDS-certified storage for both the live audit collection and the archive.
• German deployments need C5 + BSI-Grundschutz alignment; commit to BSI ORP.4 + DER.1 coverage and document it.
• EHDS interop: emit a per-event correlationId (UUIDv7) such that the EHR’s logging component can reference the VPN session that produced an access event.

---

6. United Kingdom (appendix)

UK GDPR + Data Protection Act 2018 + the Data (Use and Access) Act 2025 govern. ICO is the regulator.

Key divergences from EU GDPR relevant to identity-vpn:

Topic	EU	UK
Breach notification	Art. 33 — 72 hours to supervisory authority	Same 72-hour rule via UK GDPR Art. 33 (mirrors EU); ICO has its own portal
Adequacy	EU adequacy list applies	UK maintains its own adequacy list (“data bridges”); EU and UK are mutually adequate post-Brexit (current as of 2026-05)
EHDS	Applies in EU/EEA	Does not apply in UK; instead, NHS Digital / NHS England maintain the NHS Data Security and Protection Toolkit (DSPT) as the de facto standard for UK NHS organisations
NIS2	Directly applicable (transposed)	UK has its own NIS Regulations 2018 + “NIS2-equivalent” updates via the Cyber Security and Resilience Bill (in progress 2025–2026); reporting timelines broadly similar
eIDAS 2.0	Mandatory acceptance of EUDI Wallet	Not applicable; UK has its own digital identity trust framework
Audit log retention	Member-State practice	DSPT expectation: 6 years for access logs to NHS-held records; longer for child records (until age 25, or 8 years post-discharge, whichever later)

For VPN audit in a UK deployment:

• DSPT-aligned retention: 6 years minimum for general access logs; 8+ years for any session that accessed a paediatric record.
• ICO breach reporting integrates with NHS England’s reporting flow via the DSPT toolkit.
• Encryption at rest is explicitly expected (Caldicott Principles + DSPT NDG standard 1).

---

7. Synthesis — unified audit-log schema and topology

7.1 Side-by-side comparison

Axis	TH (PDPA)	JP (APPI + MHLW v6.0)	PH (DPA + NPC C-2023-06)	EU (GDPR+NIS2+EHDS+HDS+ISO 27799)	UK (DSPT)
Audit-log mandate	Implied (s.37 security)	Explicit (MHLW v6.0)	Explicit (NPC C-2023-06)	Implied by GDPR; explicit by NIS2 + EHDS	Explicit (DSPT)
Retention (security logs)	Not specified; 10y recommended by analogy	Not specified; ≥ 5y by analogy to medical records	≥ 2y general, longer for security; 6y recommended	3y DE / 6m–3y FR / 20y pseudonymised	6y (DSPT)
Retention (record-access logs)	Not specified; 10y by analogy	≥ 5y by analogy	6y recommended	3–10y typical; 20y for minors in some jurisdictions	6–8y (or until age 25 for minors)
Immutability	“Appropriate” (s.37)	“Tamper-prevention”	“Protection against unauthorised modification”	ISO 27799 + C5 + HDS imply hash/WORM	DSPT expects integrity controls
Time precision	Not specified	≥ 1 second	Not specified	ISO 27789: precise to seconds	≥ 1 second
Mandatory fields	Derived from s.39 ROPA	MHLW v6.0 + JAHIS	NPC C-2023-06	ISO 27789:2021 superset	DSPT + DCB 0129/0160
Patient access right to “who accessed”	Implied (s.30/s.31)	Implied (APPI Art. 33)	Yes (DPA s.16 + Health Privacy Code)	Explicit (EHDS Art. 8) + GDPR Art. 15	Explicit (DSPT + UK GDPR Art. 15)
Cross-border restriction	s.28 — consent/SCC	Art. 28 — consent/SCC, no SG adequacy	s.21 — relatively permissive	Chapter V — SCCs, adequacy decisions	UK data bridges
Breach notification deadline	72h to PDPC	“Without delay” to PPC (no fixed hours)	72h to NPC	24h early warning + 72h (NIS2 if essential entity)	72h to ICO

7.2 Unified audit-log schema (vpn_audit_events collection)

interface VpnAuditEvent {
  // ── envelope ────────────────────────────────────────────────
  _id: ObjectId;
  eventId: string;            // UUIDv7, time-ordered
  correlationId: string;      // UUIDv7, shared with EHR audit if event led to record access
  schemaVersion: '1.0.0';
  jurisdiction: 'TH' | 'JP' | 'PH' | 'EU-DE' | 'EU-FR' | 'EU-NL' | 'UK';
  region: string;             // AWS region for residency proof
  hospitalId: string;         // multi-tenancy
  facilityId?: string;

  // ── timing ──────────────────────────────────────────────────
  occurredAt: Date;           // UTC, millisecond
  receivedAt: Date;           // when control-plane received the event
  nodeSeq: number;            // monotonic per-node sequence (clock-skew safe)

  // ── actor ──────────────────────────────────────────────────
  actor: {
    type: 'staff' | 'patient' | 'system' | 'admin';
    subjectRef: string;       // opaque ID into staff/patient registry
    role?: string;            // e.g., 'nurse', 'physician', 'cashier', 'super-admin'
    qualifiedAttributes?: Array<{   // for eIDAS 2.0 EUDI Wallet attestations
      type: string;           // e.g., 'physician-licence', 'pharmacist-registration'
      value: string;          // pseudonymous reference, not the raw licence number
      issuer: string;
      verifiedAt: Date;
    }>;
  };

  // ── action ─────────────────────────────────────────────────
  action:
    | 'vpn.connect'
    | 'vpn.disconnect'
    | 'peer.config.issued'
    | 'peer.config.revoked'
    | 'acl.changed'
    | 'auth.failed'
    | 'mfa.challenge.result'
    | 'passkey.enrolled'
    | 'passkey.revoked';
  result: 'success' | 'failure' | 'pending';
  failureReason?: string;     // structured; controlled vocabulary

  // ── target (what was acted on) ─────────────────────────────
  target?: {
    type: 'peer' | 'acl' | 'session' | 'passkey' | 'patient-record';
    ref: string;
    // when an event correlates with a downstream patient-record access:
    patientSubjectRef?: string;
  };

  // ── classification (NPC C-2023-06) ─────────────────────────
  class: 'security' | 'system';   // drives differential retention

  // ── authentication context ─────────────────────────────────
  authn: {
    method: 'webauthn-passkey-byod' | 'webauthn-passkey-tpm' | 'badge-tap-pin' | 'device-cert' | 'eudi-wallet';
    factorsUsed: Array<'possession' | 'inherence' | 'knowledge'>;
    mfaPassed: boolean;
    walletAttestation?: {
      walletId: string;
      attestationFormat: string;
      verifiedAt: Date;
    };
  };

  // ── device context ─────────────────────────────────────────
  device: {
    class: 'byod' | 'shared-workstation' | 'hospital-laptop';
    deviceId: string;         // hashed; reversible only via the encrypted side-table
    tpmAttested?: boolean;
    posture?: 'compliant' | 'non-compliant' | 'unknown';
  };

  // ── network ────────────────────────────────────────────────
  network: {
    srcIpHash: string;        // HMAC-SHA256(srcIp, region-secret)
    srcCountry?: string;      // GeoIP at receive-time
    asn?: number;
    tunnelType: 'wireguard-staff' | 'tls-patient-telehealth';
  };

  // ── integrity ──────────────────────────────────────────────
  prevHash: string;           // SHA-256 of previous event in this node's stream
  hash: string;               // SHA-256 of canonical(this event minus signature)
  signature: string;          // Ed25519(hash) by the node's signing key
  signerKeyId: string;        // key rotation identifier

  // ── lifecycle ──────────────────────────────────────────────
  retentionClass: 'standard' | 'extended' | 'minor-anchored';
  expireAt: Date;             // TTL index; calculated from class + jurisdiction
}

Side tables:

• vpn_audit_ledger — hourly Merkle root over all events, signed and exported to off-site WORM.
• vpn_audit_ipmap — encrypted lookup table from srcIpHash → raw IP, accessible only by SOC for forensics. Separate key, separate retention (NIS2 forensics — typically 18 months).
• vpn_audit_devicemap — encrypted lookup table from deviceId hash → device serial / inventory tag.

7.3 Retention policy (TTL per jurisdiction × class)

Jurisdiction	system log TTL	security log TTL	minor-anchored TTL
TH	5 years	10 years	25 years
JP	5 years	5 years	5 years (no minor extension in APPI)
PH	2 years	6 years	until age of majority + 10
EU-DE	3 years	6 years	10 years
EU-FR	3 years	6 years (HDS)	10 years
UK	6 years	6 years	until age 25 / 8y post-discharge

All TTLs are enforced by a MongoDB TTL index on expireAt. A nightly job promotes events to a longer-retention class if a correlation surfaces (e.g., a vpn.connect event was retroactively associated with a paediatric record access — promote to minor-anchored).

7.4 Immutability strategy

• Write path: application writes are append-only via a service-account that has no UPDATE/DELETE privilege on vpn_audit_events. MongoDB role-based access enforces this.
• Per-event signature: each event is signed with the per-node Ed25519 key when written. The previous event’s hash is included, producing a per-node hash chain.
• Hourly Merkle anchoring: a cron writes a Merkle root over the last hour’s events into vpn_audit_ledger. Root is signed by a separate “ledger” key (different key custodian than nodes), and exported to S3 Object Lock (or air-gap courier media for on-prem).
• Air-gapped sites: off-site export is to physical WORM media (Blu-ray + signed manifest, or HDD with hardware write-protect), couriered weekly. Manifest verified by a separate central node.

7.5 Topology — where logs live

┌─────────────────────────────────────────────────────────────────┐
│  Per-region MongoDB replica set (no cross-region replication)   │
│                                                                 │
│  Collections:                                                   │
│   - vpn_audit_events      (append-only, signed, TTL by class)  │
│   - vpn_audit_ledger      (hourly Merkle anchors)              │
│   - vpn_audit_ipmap       (encrypted, short retention)          │
│   - vpn_audit_devicemap   (encrypted)                          │
│                                                                 │
│   ─────────► local WORM (S3 Object Lock / on-prem WORM courier)│
└─────────────────────────────────────────────────────────────────┘
            │
            │ (only pseudonymised counts + p95 latency)
            ▼
┌─────────────────────────────────────────────────────────────────┐
│  Central SOC console (single region, locale-agnostic)           │
│                                                                 │
│   - hits/min per facility                                       │
│   - failed-auth rate per region                                 │
│   - MFA challenge failure rate                                  │
│   - geographic anomaly flags                                    │
│                                                                 │
│   NEVER stores raw events. Never stores actor IDs.              │
└─────────────────────────────────────────────────────────────────┘

7.6 Why not co-mingle with EHR audit

We considered storing both VPN events and EHR access events in the existing administration-service audit_events MongoDB collection. The arguments against:

1. Different retention drivers. EHR audit is anchored to record retention (5–25 years depending on jurisdiction). VPN audit is anchored to security-log retention (2–10 years). TTL design becomes ugly in a single collection.
2. Different reviewers. EHR audit is reviewed by privacy officers and clinicians on demand. VPN audit is reviewed by the SOC quarterly. Different access controls, different export formats.
3. NIS2 vs. GDPR forensics formats. NIS2’s expected SIEM/CSIRT export schema is not the same as a GDPR Art. 15 response. Forcing one record to serve both is fragile.
4. Different signing keys. Per-node Ed25519 signing for VPN events implies key-management workflows that should not be pushed through the administration service.
5. Performance. VPN events run at 10–100x the volume of EHR audit events under peak load (every keepalive, every roam, every NAT rebind), and we don’t want EHR audit query performance hostage to VPN write throughput.

The compromise — same MongoDB cluster, same region, joinable on correlationId and actor.subjectRef — satisfies “cross-queryable” without paying any of the costs above.

7.7 What this leaves for the services/identity-vpn implementation

1. NestJS module AuditModule exposing auditService.record(event) with synchronous signing.
2. Per-node Ed25519 key custody via AWS KMS (or Vault for on-prem).
3. MongoDB roles: vpn-audit-writer (insert-only), vpn-audit-reader (find, no mutate), vpn-audit-admin (TTL + index management; quarterly use only, behind break-glass).
4. Hourly Merkle anchor cron registered via the existing cron_jobs registry (see docs/architecture/cron-jobs-registry.md).
5. Off-site export adapter with pluggable backends: S3 Object Lock, on-prem WORM courier (signed manifest + Blu-ray writer driver).
6. Patient-disclosure endpoint: given patientSubjectRef, return the joined view across vpn_audit_events and EHR audit_events, sanitised (no IPs, no device fingerprints, no internal staff IDs — show staff role + facility + timestamp).
7. NIS2 SOC export endpoint: given a time window, emit a CSIRT-format structured report.
8. EHDS interop: ensure correlationId propagates through the access token claim so the EHR’s mandated logging component can correlate.

---

8. Open questions / things requiring legal review

Each item below is ⚠ legal review needed — research alone cannot close it.

1. TH: Does PDPA s.30/s.31 obligate a hospital to expose VPN session metadata (timestamp, role, facility) to a patient on request, or only the record-access events?
2. TH: Is the Medical Council’s 5-year medical-records norm the right anchor for VPN audit retention, or should we anchor to a different MoPH notification we haven’t found?
3. JP: MHLW v6.0 does not state a numerical log-retention period. Confirm “≥ 5 years to match Medical Care Act Art. 24-2” is the consensus interpretation among Japanese healthcare counsel.
4. JP: Cross-border replication of pseudonymised aggregate metrics (counts, latency percentiles) to a Singapore SOC — does the PPC consider this an Art. 28 transfer of personal information?
5. PH: NPC Circular 2023-06 says “security logs longer than general.” Is there a defensible defaulted number (we propose 6 years)? Does NPC publish enforcement-action data that anchors this?
6. PH: PhilHealth 10-year retention for claims — does it extend to access logs of staff who viewed claim records?
7. EU-DE: Whether shared-workstation badge-tap readers that store local fingerprint templates trigger GDPR Art. 9 explicit-consent requirements, or whether the BSI-Grundschutz position that on-device-only biometric templates are out of Art. 9 scope holds.
8. EU-FR: HDS 2.0 (decree of 26 April 2024) — does an “identity & access management control plane” deployed alongside a hospital EHR need its own HDS certification, or does it inherit from the hosting platform’s certification?
9. EU-wide: EHDS Art. 8 (citizen access to “who accessed my health data”) — does it reach far enough to demand exposure of the VPN session that enabled the access, or only the record-access event itself?
10. EU-wide: eIDAS 2.0 mandatory acceptance of EUDI Wallet for “strong user authentication” in healthcare — does this apply to staff VPN access, or only to patient identity flows? Likely the latter, but the wording in the Regulation is ambiguous.
11. UK: DSPT retention of 6 years vs. 8 years for paediatric — the “8 years post-discharge” rule is well-known for medical records; does it extend cleanly to VPN session logs or do we need to anchor more conservatively?
12. All: Off-site WORM export via courier media (for air-gapped hospital deployments) — is the chain-of-custody signed manifest sufficient evidence under each jurisdiction’s evidentiary standards in the event of a subpoena?

---

9. References

Primary regulation and guidance consulted during research:

• Thailand: PDPA B.E. 2562 (2019), Sections 28, 30, 31, 37, 39, 40; PDPC Notification on Security Measures B.E. 2565 (2022); National Health Act B.E. 2550 (2007).
• Japan: APPI as amended 2022 / 2023, Article 28 (cross-border), Article 2(3) (sensitive); MHLW “Guidelines for the Safety Management of Medical Information Systems” v6.0 (2023); METI/MIC “Guidelines for Safety Management by Information System and Service Providers Handling Medical Information” v2.0 (3省2ガイドライン); Medical Care Act (医療法) Art. 24-2.
• Philippines: RA 10173 Data Privacy Act 2012; NPC Circular 2023-06 (effective 30 March 2024); NPC Advisory 2017-03; DOH-NPC Health Privacy Code; National eHealth Privacy Framework (rev 2023); RA 7875 / RA 11223.
• EU: GDPR (Regulation (EU) 2016/679), Articles 9, 15, 30, 32, 33, 34; NIS2 Directive (Directive (EU) 2022/2555), Articles 21, 23; EHDS Regulation (EU) 2025/327, Articles 8, 14–16, 50–51; eIDAS 2.0 (Regulation (EU) 2024/1183).
• France: HDS framework (Decree of 26 April 2024, “HDS 2.0”); Agence du Numérique en Santé reference manual.
• Germany: BSI C5 Cloud Computing Compliance Criteria Catalogue; KHZG (Krankenhauszukunftsgesetz) and § 75c SGB V; BSI-Grundschutz modules ORP.4, DER.1.
• ISO: ISO/IEC 27001:2022; ISO 27799:2016 (revised 2025); ISO 27789:2021.
• UK: UK GDPR + Data Protection Act 2018; ICO breach guidance; NHS Data Security and Protection Toolkit (DSPT); Cyber Security and Resilience Bill (in progress).
• EDPB Guidelines: 01/2022 (right of access, adopted v2 April 2023); 03/2020 (health data for scientific research).