English
日本語
中文
한국어
The conventional model treats computer system validation as a quality department exercise: templates written at global headquarters and executed once at go-live. That model breaks down in Japan and South Korea, where inspections are document-driven, evidence is often requested in the local language, and day-to-day IT operations are frequently outsourced to in-country partners who touch validated systems every week.
In practice, IT owns more of the validation workload than most organization charts admit: patch decisions, cloud update assessments, and the change records inspectors read first. This article works through the validation discipline itself as it runs in these two markets: scoping the estate with GAMP 5 categories, executing IQ, OQ, and PQ, assembling the documentation package an inspection will test, handling revalidation triggers, and settling ownership when IT is outsourced.
Which Systems Need Validation: Applying GAMP 5 Categories to the IT Estate
Any system that creates, modifies, or stores records affecting product quality or patient safety sits inside the validation boundary. The GAMP 5 framework classifies software into four categories: infrastructure (Category 1), non-configured products (Category 3), configured products (Category 4), and custom applications (Category 5). Validation effort scales with the category and the risk the system carries.
The framework’s current edition, published by ISPE in 2022 (GAMP 5 Second Edition, ISPE, 2022), extends the original risk-based approach to cloud services, agile development, and supplier-managed platforms, which is where most of a modern Medical Device company’s estate now lives. For a typical operation in Japan or South Korea, the inventory that matters includes the manufacturing execution system, the laboratory information management system, the electronic quality management system, complaint handling, calibration and maintenance tracking, label control, and the ERP modules that release products. It also includes the unglamorous layer: spreadsheets with macros that calculate acceptance criteria are Category 4 or 5 software in GAMP terms, and they surface in audits precisely because nobody classified them.
Interfaces deserve explicit scoping decisions. Where a device or its supporting systems exchange data with hospital infrastructure, the validation boundary covers your side of the interface: the integrity of what your system sends and how it handles what comes back. Drawing that line in the validation plan, system by system, prevents the two failure modes that waste the most effort: classifying everything as Category 5 and drowning in protocols, or classifying optimistically and explaining the gap to an inspector.
IQ, OQ, and PQ in Practice: What Each Qualification Stage Proves
Installation qualification (IQ) proves the system is installed and configured as designed. Operational qualification (OQ) proves each function behaves as specified under defined conditions, including error handling and access control. Performance qualification (PQ) proves the system supports the real business process with real users, data, and workflows. Together they convert requirements into inspectable evidence.
The three stages only work as a discipline when traceability holds: PQ tests trace to user requirements, OQ tests to functional specifications, IQ checks to design and installation specifications. A traceability matrix that connects every mandatory requirement to an executed test is what turns a folder of protocols into a defensible argument that the system is fit for its intended use.
The reference point for how much testing is enough has shifted. The FDA finalized its Computer Software Assurance guidance in September 2025 (FDA, 2025), endorsing unscripted testing for lower-risk functions and the reuse of supplier test evidence in place of scripted protocols for everything. For a multinational running systems that serve Japanese and Korean operations alongside US ones, the practical question is which regulator will read the file. A lean, risk-argued assurance package satisfies the FDA’s current position; Japanese document reviews reward completeness and explicit rationale. The workable compromise is to adopt risk-based test depth but document the risk reasoning formally, so the same package survives both reading styles. The trade-off is real: scripting everything roughly doubles validation hours on a configured system, while a lean package demands a written risk assessment strong enough to carry the weight the scripts used to carry.
The Documentation Package an Inspection Will Test
A defensible validation package contains a validation plan, user requirements specification, risk assessment, supplier assessment, traceability matrix, executed IQ, OQ, and PQ protocols with deviation records, and a validation summary report. In Japan and South Korea, inspectors work document-first, so the package itself, not a live demonstration, is the product validation that has to be delivered.
Japan’s PMDA conducts both on-site and document-based inspections of manufacturing sites in Japan and overseas (PMDA), and Japan’s Ministry of Health, Labor and Welfare has maintained a dedicated guideline on the management of computerized systems since 2012, covering documentation across development, validation, operation, security, backup, and retirement (ECA Academy, 2012). In South Korea, KGMP approval is required for Class II, III, and IV devices (Pacific Bridge Medical), and MFDS auditors test whether records meet ALCOA expectations: attributable, legible, contemporaneous, original, accurate. The regulatory obligations behind these expectations are a subject of their own, covered in our guide to medical device compliance for IT in Japan and South Korea.
Language is an execution decision, not a footnote. Inspectors in both markets can and do request local-language material, and operating staff need SOPs they can actually follow. Translating the full package is expensive and rarely necessary. The pattern that works: keep protocols and raw test evidence in English as the system of record, and maintain the validation summary report, key SOPs, and the system inventory bilingually. That costs a few days per system and saves the pre-inspection scramble.
Revalidation Triggers: Patches, Cloud Updates, and Vendor-Pushed Change
Revalidation is triggered by any change that can alter validated functionality: operating system and security patches, application upgrades, configuration changes, infrastructure migrations, and vendor-pushed SaaS updates. The proportionate response is risk-assessed regression testing scoped to the affected functions, executed under change control. A full IQ, OQ, and PQ rerun is the exception, not the rule.
Cloud platforms are where this discipline gets tested. A SaaS vendor releases on its own schedule, so the control point moves from approving each change to governing the vendor relationship: reviewing release notes against your risk assessment, testing high-impact changes in a sandbox tenant before they reach production, and running a periodic review that confirms the validated state still holds. GAMP 5’s second edition treats supplier-managed change as a first-class scenario for exactly this reason.
The estate-level version of the problem is scheduling. A patch approved globally still has to be assessed against each validated system it touches: the same Windows update is routine on an office laptop and a change-controlled event on the PC driving a test rig in a Yokohama plant. Someone in each country has to make that call inside the patch window and record it. The trade-off runs in both directions. Freezing validated systems to avoid revalidation accumulates unpatched vulnerabilities, itself an audit finding. Assessing every change at full depth builds a backlog that stalls the patch cadence. A tiered model, where GxP impact determines assessment depth, is the only version that survives contact with an eight-market estate.
Who Owns Validation When IT Is Outsourced In-Country
Regulatory accountability for validation stays with the license-holding Medical Device company and cannot be transferred to an IT vendor. What can be delegated is execution: drafting protocols, running test scripts, collecting evidence, assessing changes, and maintaining infrastructure qualification. The split has to be written into the contract and quality agreement before the first audit, not reconstructed during it.
The common setup in Japan and South Korea is a US or European multinational with a small in-country IT presence and day-to-day operations delivered by a local partner. That works, provided the quality agreement answers four questions precisely: who classifies each change against the validated-system inventory, who executes qualification work on infrastructure, who signs test evidence, and who is accountable for the audit trail staying intact. The supplier itself becomes part of the validation argument: GAMP 5 expects a documented supplier assessment, and an inspector can ask how the outsourced engineer executing IQ scripts was qualified to do so.
The trade-off is between audit burden and headcount. Delegating execution to a partner means auditing that partner and keeping quality approval in-house, which demands a vendor with GxP-literate engineers in Tokyo and Seoul, not a general-purpose helpdesk. Keeping execution internal means hiring validation-capable IT staff in both countries, in languages your headquarters does not work in. Most multinationals land on the first model, run under a quality agreement, connected to the wider regional architecture described in our guide to IT for Medical Device companies operating across APAC and supported by IT compliance and deployment services with engineers in-country.
Frequently Asked Questions
What is computer system validation in a Medical Device company?
Computer system validation is the documented process of proving that a system affecting product quality or patient safety does what it is intended to do, consistently. It covers planning, requirements, risk assessment, IQ, OQ, and PQ testing, and a summary report, and it remains in force through change control for the life of the system.
What is the difference between computer system validation (CSV) and computer software assurance (CSA)?
CSA is the FDA’s risk-based evolution of CSV for production and quality system software, finalized in 2025. It shifts effort from scripted testing of everything toward critical thinking: scripted tests where risk is high, unscripted testing and supplier evidence where risk is low. The obligation to establish fitness for intended use is unchanged.
Do IQ, OQ, and PQ apply to cloud and SaaS systems?
Yes, with adjusted scope. IQ verifies the tenant configuration and integration points rather than physical installation, OQ tests configured functionality, and PQ confirms the business process works in the tenant. Supplier assessment carries more weight because the vendor controls the platform, and vendor-pushed updates must be governed under change control.
How often should validated systems be reviewed or revalidated?
Event-driven revalidation happens whenever a change can affect validated functionality. On top of that, a periodic review, commonly every one to three years depending on GxP impact, confirms the system still matches its documentation, the audit trail works, access lists are current, and accumulated small changes have not eroded the validated state.
Does validation documentation for PMDA or MFDS inspections need to be in the local language?
There is no blanket requirement to translate the full package, but inspectors in Japan and South Korea can request local-language material, and operating staff need usable SOPs. The practical standard is English protocols and evidence as the system of record, with the validation summary, key SOPs, and system inventory maintained bilingually.
Does systemsGo support computer system validation for Medical Device companies in Japan and South Korea?
Yes. With engineers in Tokyo and Seoul, systemsGo executes the IT side of validation for Medical Device companies: infrastructure qualification, IQ, OQ, and PQ execution support, patch and change assessment on validated systems, and bilingual documentation support, operating under the client’s quality agreement and working alongside the client’s quality team.
If your validated systems in Japan or South Korea are maintained by teams who have never read your validation plan, the gap will surface at inspection. In both countries, systemsGo provides GxP-aware IT execution under your quality agreement.