CPOB and computerised systems: what Indonesian GMP asks of digital production records
CPOB requires electronic production records to satisfy the ALCOA+ data integrity principles: attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring and available. In practice that means an audit trail that cannot be switched off, per-user access control, and documented validation that the system performs as claimed.
What changes when records move into a system
Paper batch records have a property that is easy to overlook until paper is replaced.
Paper is hard to alter without leaving a mark.
Crossings-out are visible. Handwriting is recognisable. A missing page leaves a hole in the numbering.
An electronic system has none of that by default.
A number can be changed with no trace at all, unless the system was deliberately built to leave one.
So when production records move into a system, CPOB requires things it never asked of paper.
Not because systems are considered less trustworthy. Because a property that used to be inherent in the medium now has to be engineered on purpose.
BPOM’s CPOB guidance governs good manufacturing practice for medicinal products in Indonesia, and is aligned with the PIC/S approach on computerised systems.
That section is where plants moving off paper most often turn out to be weak.
ALCOA+, translated into system behaviour
Data integrity principles are usually summarised as ALCOA+.
The acronym is easy to memorise. The meaning only becomes clear once each letter is translated into something a system actually does.
| Principle | What it demands | What it looks like in a production system |
|---|---|---|
| Attributable | Clear who did it | Every action bound to one user identity, with no shared accounts on floor terminals |
| Legible | Readable, and stays readable | Records readable for their full retention period, across system version changes |
| Contemporaneous | Recorded when it happened | Timestamps from the system, not retyped by an operator afterwards |
| Original | The first record, not a copy | Raw equipment data retained, not only its processed result |
| Accurate | Correct and complete | Out-of-range values refused at the point of entry, not corrected later |
| Complete | Including repeated results | Retests recorded with their reason, rather than overwriting the earlier result |
| Consistent | Sequence makes sense | Timestamps ordered and drawn from a single time source |
| Enduring | Survives the retention period | Not dependent on media or devices that can be lost |
| Available | Retrievable when needed | Batch records producible during inspection without a special recovery process |
The two rows that most often become findings are Attributable and Contemporaneous.
Both come down to working practice rather than software features.
The three most common findings
1. Shared accounts on floor terminals
This almost always starts with a reasonable justification.
A terminal in the production area is used by many operators. Repeated logins slow the work down. Gloves make password entry awkward.
So one shared account per line gets created.
From that point, every record produced by that terminal loses its attributability.
The system records “OPERATOR_LINE3”. There is no way to establish who that was.
For CPOB purposes this weakens all records from that terminal, not merely some of them.
The remedy is practical. Fast login, sessions that lock themselves, and electronic signatures requested only at steps that genuinely need them.
Compliance should not depend on people being willing to absorb friction.
2. An audit trail that exists but answers nothing
Nearly every system claims to have an audit trail.
What separates them is whether it can answer an inspector’s question.
A useful audit trail records the value before and after a change, who made it, when, and why.
A useless one records that a record was “modified” at a point in time.
The difference only becomes apparent when an inspector points at a value and asks why it changed.
The answer has to be in the system, not in someone’s memory.
One further requirement is frequently missed.
The audit trail must not be disableable.
If an administrator can turn it off, there is no way to prove it was running when a given record was created.
The capability alone is the problem.
3. Validation that stops at go-live
System qualification through IQ, OQ and PQ is often treated as a project with a completion date.
But validated status only holds for as long as the system remains as it was when validated.
Every configuration, version or process change calls for an impact assessment.
What you need to show is not merely that validation was once performed.
You need to show that the system running today is still in a validated state.
This is what makes the ability to promote configuration between environments worth considerably more than its operational convenience. Development to testing to production, with a change history and the ability to roll back.
Where vendor responsibility ends
There is one expensive misunderstanding.
Buying a “compliant” system does not make the plant compliant.
What a vendor can supply is a system capable of meeting the requirements, together with documentation supporting that.
What a vendor cannot supply is evidence that the system works correctly for your specific processes, in your configuration, with your data.
| Vendor responsibility | Plant responsibility |
|---|---|
| The system can produce a complete audit trail | The audit trail is actually enabled and periodically reviewed |
| Access control exists and is configurable | Rights match roles, are reviewed, and are revoked when not needed |
| An electronic signature mechanism is provided | Procedures define who signs what, and with what meaning |
| Development and testing documentation is available | IQ, OQ and PQ qualification is executed at your site |
The question worth asking a prospective vendor is not “is your system compliant”.
It is this:
“Show me the audit trail for a single changed value, then show me the function cannot be switched off.”
The first invites a marketing answer.
The second can only be answered by demonstration.
A note on the references
CPOB guidance is issued and periodically updated by BPOM, including the sections covering computerised systems.
Comparable requirements apply under CPOTB for traditional medicines and CPKB for cosmetics, with scope adjusted accordingly.
Guideline editions and annex numbering change over time.
For the requirements applying to your product category and marketing authorisation, consult the current CPOB edition from BPOM directly.
This article covers what those requirements mean for a production system. It is not a substitute for regulatory advice.
Where VECHR MES fits
VECHR MES records every production action with the user identity, the system timestamp and the process context.
Attribution is a consequence of how the data is created, not of how diligently a form is filled in.
The audit trail is append-only and cannot be disabled from within the application, administrators included.
Access control is enforced server-side on every action rather than hidden in the interface. Permissions cannot be bypassed by calling the API directly.
Electronic signatures are hash-chained. Each signature is bound to the content of the record it signs, so any subsequent change breaks the chain and becomes visible.
Electronic batch records export as independently verifiable documents. A hash from a printed record can be checked without logging into the system, which means verification does not depend on trusting the system that issued it.
To keep validated status intact, configuration can be promoted from development through testing to production with a change diff and the ability to roll back.
The equivalent mechanisms under the FDA framework are covered in 21 CFR Part 11 for manufacturers.
Frequently Asked Questions
How does CPOB relate to 21 CFR Part 11?
They address the same problem from different jurisdictions. 21 CFR Part 11 is the FDA rule in the United States. CPOB is BPOM guidance in Indonesia, aligned with the PIC/S approach. The principles are closely similar. Records must be attributable, cannot be altered silently, and must be verifiable. A system designed to satisfy one generally satisfies most of the other.
Can the audit trail be disabled for performance reasons?
No. An audit trail that a user can switch off, administrators included, is effectively not an audit trail. There is no way to prove the function was active when a given record was created. The ability to disable it is itself a finding, regardless of whether it was ever actually used.
Who is responsible for validation, the vendor or the plant?
The split is fairly clear. The vendor is responsible for the system being built correctly and documented. The plant is responsible for demonstrating that the system works correctly for its specific processes in its own configuration. A vendor cannot validate your process, and vendor documentation does not replace qualification at your site.
Do electronic signatures have to be biometric or certificate-based?
Not necessarily. The requirement is that a signature is unique to one person, cannot be reused by anyone else, is bound to the record being signed, and carries the meaning of the signing. Performed, checked, or approved. A properly controlled user ID and password combination can satisfy this, provided credentials are never shared.
Can spreadsheets be used for CPOB-regulated records?
Technically possible, but rarely worth the cost. A spreadsheet has to be validated like any other system, and satisfying audit trail and access control requirements without additional layers is close to impossible. Most spreadsheet-related findings trace back to the same root. No way to prove which cell changed, when, and by whom.