EDC, eConsent, case management, monitoring support — vendors serving clinical trials run into requirements an ISMS alone does not answer. Sponsors and sites want, on top of security evidence, a separate assurance: that records produced by the system will stand up as evidence before a regulator.
That assurance is the subject of Japan's ER/ES guidance on electronic records and electronic signatures. Where an ISMS governs the mechanism for protecting information, ER/ES governs the evidentiary reliability of records. The two overlap, but they are not the same, and handing over a certificate does not end a sponsor's audit.
This article covers what ER/ES demands, how to design the audit trail, how GCP fits, and exactly how far ISMS documentation carries you.
Disclaimer: General information only. Interpretation of ER/ES guidance, the GCP Ordinance, and their operation is governed by MHLW and PMDA publications. Confirm application to a specific trial or system with the sponsor, the site, and specialists. Interpretation of the standard is governed by the standard and the accreditation and certification bodies.
Three Layers of Requirement
| Layer | What it demands | Who checks it |
|---|---|---|
| Information security | Confidentiality, integrity, availability | Certification bodies, customer security audits |
| Record reliability (ER/ES) | Records are authentic, legible, and retained | Sponsor audits, regulatory inspection |
| Clinical trial conduct (GCP) | Conduct and records conform to the standard | Sponsor monitoring and audit, regulatory GCP inspection |
From the vendor's side, the job is to put your customer in a position to answer what the regulator asks them. When an inspector asks how a data point was entered, who changed it and when, and why — the answer rests on system features and system records.
This is what separates this domain from ordinary B2B SaaS: part of your customer's regulatory compliance is carried by your system. That is why sponsors ask for validation records and audit trail specifications on top of a security check sheet.
The Three ER/ES Requirements
In 2005 Japan's MHLW issued guidance on the use of electromagnetic records and electronic signatures in applications for approval and licensing — commonly the ER/ES guidance.
| Requirement | Meaning | What the system must do |
|---|---|---|
| Authenticity | Records are accurate, the responsible author is clear, and deliberate or accidental alteration is prevented or detectable | Individual accounts, authorisation control, audit trail, tamper detection |
| Legibility | Content can be output or displayed clearly whenever needed | Screen display, report output, export in submission formats |
| Retainability | Records remain restorable throughout the retention period | Media and format degradation measures, migration plans, backup and restore |
These three are the same frame used for electronic retention in healthcare generally. They look like confidentiality–integrity–availability but do not map cleanly.
- Authenticity resembles integrity, but adds attribution — who is the responsible author
- Legibility has no direct ISMS counterpart. Being able to produce output is itself the requirement
- Retainability resembles availability, but assumes retention measured in years to well over a decade
Retainability is the heavy one for a SaaS vendor. Records must survive after a trial closes, across system generations, format changes, and the vendor's own continuity. Settle the terms for data return and migration at end of service in both the contract and the procedure.
Where electronic signatures are used, the identity of the signer, the object and moment of signature, and the meaning of the signature (approval or verification) must all be recorded. Do not leave signatures as a bare click — record what the signer is asserting.
What the Audit Trail Must Capture
The audit trail is the centre of ER/ES implementation. Weakness here stops an audit regardless of how solid everything else is.
| Element | Content | Common gap |
|---|---|---|
| Who | An identifier resolving to an individual | Shared accounts, so no individual can be identified |
| When | Timestamp, with timezone and clock synchronisation assured | Server clock drift; no timezone recorded |
| What | The record and the field affected | Record-level logging only, so the field is unknown |
| How changed | Value before and value after | Only the new value retained; the original is lost |
| Why | Reason for change | Free-text field left empty in practice |
| Protection | The audit trail itself cannot be altered or deleted | Administrators can delete audit trail entries |
The two most common design defects are losing the prior value and having a privilege that can delete the trail. The latter arises wherever administrators or vendor maintenance staff can reach the production database directly. Privileged access is an ISMS topic too, but in trial systems "it cannot be deleted" is itself the requirement — append-only storage, a separate destination, write-once integrity checks.
See Audit Logs and Trails and Access Control and Privileged IDs — written for hospitals, but the reasoning transfers.
GCP and the Vendor's Responsibility
GCP binds sponsors and investigational sites, not system vendors directly. It reaches vendors through three routes.
- Outsourcing does not transfer the sponsor's responsibility, so sponsors demand enough evidence from you to discharge their own duty
- Retention obligations sit with the sponsor and the site, and where your system holds the records, their compliance depends on your features and operations
- System suitability is examined during inspection — your verification records are what answers "has this system been verified to work as intended?"
| Sponsor's obligation | What the vendor supplies |
|---|---|
| Proper management of suppliers | Quality and security briefing materials, ISMS certificate, audit cooperation |
| Retention of records | Retention period and format specifications, data return and migration procedure, continuity statement |
| Assuring data reliability | Audit trail specification, authorisation design, change records |
| System validation | Validation plan, execution, and report records; per-release verification |
| Handling deviations and defects | Reporting routes, incident history, corrective action records |
The worst state is producing validation records only when asked. Make accumulating verification evidence with each release the normal operating mode, or you will be reconstructing months of it after an audit notice arrives. This integrates naturally with ISMS change management — build record creation into the release process.
Note that academic clinical research is governed differently from regulated trials; fix which regime applies before designing.
Where ISMS Stops
| ER/ES or GCP requirement | Covered by ISMS | What must be added |
|---|---|---|
| Access control, individual accounts | Almost fully | Annex A access control maps directly |
| Records of granting and revoking rights | Almost fully | ISMS operating records can be shown as-is |
| Capturing the audit trail | Partly | Logging is common, but before/after values and reason are product requirements |
| Protecting the audit trail | Partly | Beyond log protection, needs a design administrators cannot delete |
| Authenticity (clear authorship) | Partly | Signature semantics and their recording are product design |
| Legibility (output and display) | Not covered | No ISMS counterpart — implement as a product feature |
| Retainability (long-term, format) | Partly | Beyond backup, needs format migration plans and return procedures |
| System validation | Not covered | Connects to change management, but plan, execution, report are separate |
| Separation per trial | Partly | Addressable in risk assessment, but per-trial separation is a product requirement |
| Continuity and data return | Partly | Beyond BCP, contractual return terms must be explicit |
In short: an ISMS supplies half the foundation, and everything bearing on evidentiary reliability must be built as a product requirement. Put the other way, with an ISMS in place you reuse access control, change management, supplier management, and incident response, and narrow the ER/ES-specific work to audit trail, legibility, and validation.
Document it as an "ER/ES policy" and a "validation procedure" sitting beneath the ISMS documentation set, riding on shared document control, training, corrective action, and internal audit. This is the same shared-layer pattern as in SaMD, ISMS and QMS. If you also serve hospitals, see Integrating ISMS Documents with the Three-Ministry Guidelines. On scope, see Designing ISMS Scope for a Healthcare Company; for the buyer's view, Demarcating Responsibility.
Conclusion
- Three distinct layers apply: security, record reliability (ER/ES), and trial conduct (GCP)
- ER/ES turns on authenticity, legibility, and retainability — which resemble but do not match C, I, and A
- The audit trail needs who, when, what, before and after values, and why — and a design administrators cannot delete
- GCP does not name the vendor, but the sponsor's duty is discharged with vendor-supplied evidence
- Build validation records into the release process; reconstructing them retrospectively is not realistic
- ISMS covers half the foundation, letting you narrow ER/ES work to audit trail, legibility, and validation
Pottech supports ISMS certification with a focus on healthcare. Where non-standard requirements stack on top, as here, the design question is how to layer them onto ISMS documentation. Support for quality process construction and security-aware project management is available as an option.
See ISMS Certification Support or contact us. The overall picture is in What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Pharmaceuticals and Medical Devices Agency (PMDA)
- Pharmaceutical information | MHLW
- e-Gov Laws and Regulations Search
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
Note: ER/ES and GCP notices and their operation are revised over time, and required record granularity and retention vary by trial and product. Confirm current content and specific application with MHLW and PMDA publications and with specialists.