top of page

Documentation is one of the most important, and often overlooked, elements of an effective quality management system. Whether supporting laboratory testing, manufacturing operations or medical device activities, documentation provides the instructions needed to perform work consistently and the records needed to demonstrate that requirements have been met.


When documentation is poorly controlled, organisations can face audit findings, difficulty investigating issues and challenges demonstrating compliance. A well - designed documentation system helps ensure that information is accurate, accessible and retained for the period required.


Define the documentation your Organisation needs


An effective QMS begins with defining the documentation needed to support organisational activities and compliance obligations.

 

The documentation structure should reflect the organisation’s activities, process complexity, regulatory obligations and personnel competence. More documents do not necessarily mean better control. The aim is to provide sufficient detail for personnel to perform their work consistently and demonstrate that requirements have been met.


While Chapter 4 (Documentation) of the PIC/S GMP Guide, ISO 9001, ISO 13485, ISO/IEC 17025 and ISO 15189 share common documentation principles, each sets out distinct requirements. Organisations should establish documentation systems that meet the standards and regulatory requirements applicable to their activities.


A practical structure might include:

Document Type

Purpose

Examples

Policies and system documents

Describe commitments, scope and how the system operates

Quality policy, Quality Manual, Site Master File

Plans

Define an approach, responsibilities and planned activities

Validation Master Plan, Audit Plan

Instructions

Explain the requirements and steps to follow

SOPs, work instructions, test methods, specifications

Templates and forms

Provide a consistent structure for capturing information

Equipment check forms, batch record templates

Records and reports

Preserve evidence, results and conclusions

Completed forms, batch records, certificates of analysis, validation reports

External documents

Provide requirements or information used in operations

Standards, supplier manuals, regulatory guidance

 

A blank form provides a controlled recording format. Once completed, it becomes a record and needs protection as evidence of the activity.


In practice, organisations often assume that more documentation results in better control. However, excessive or overly complex documentation can increase maintenance requirements, create training burdens and make it harder for personnel to locate the information they need.


Instructions describe the work - records demonstrate it


GMP Chapter 4 distinguishes between instructions and records or reports. An approved procedure explains the expected process, while the resulting records show how it was performed.


For example, an equipment cleaning SOP may describe the cleaning agent, method and acceptance criteria. The cleaning record captures the equipment identity, date, person performing the work and relevant checks. If an unexpected result occurs, the record should provide information and support investigation.


Instructions should be clear enough to guide the intended user. Records should be detailed enough to reconstruct relevant activities and understand the decisions made.


Control documents from creation to withdrawal


Document management is a lifecycle process. Writing and approving an SOP/document is only part of the work.


1.     Create and identify - Give documents a clear title and unique reference, define the format and identify the revision. Use language appropriate to the people performing the task. Include responsibilities, steps, acceptance criteria and recording requirements where needed.

 

2.     Review and approve - Check technical accuracy, suitability and consistency with related documents. Define who can review and approve each document type. Approval should be completed before a document is released for use.

 

3.     Release and make accessible - Establish the effective date and make the current approved version available where the activity occurs. Arrange any necessary training before personnel use the revised instruction.

 

4.     Review and change - Define review arrangements and triggers, including changes to processes, equipment, specifications or applicable requirements. Record what changed and consider its effect on associated forms, training and other procedures.

 

5.     Withdraw and preserve - Prevent unintended use of obsolete instructions while preserving the versions needed to interpret historical records. A superseded procedure may still be needed to understand how work was performed at an earlier date.


Many document control issues do not arise during document creation. They occur later when reviews are missed, obsolete versions remain accessible, or associated documents and training records are not updated following a change.

 

Protect records through good documentation practices


A record should allow another person to understand what happened, when it happened, who performed the work and what outcome was obtained.


Practical recording controls include making entries when work occurs, using legible and durable recording methods, identifying the person making the entry and ensuring corrections preserve the original information. Unused fields and missing entries should be addressed through defined rules.


For manual records, the form needs enough space for clear entries. For electronic records, the system needs controls appropriate to its intended use, including permissions and traceability of relevant changes.


A completed record should not become freely editable simply because it is stored in a shared folder. Changes need to remain identifiable, and confidential health information requires protection in accordance with applicable regulatory obligations.


Retention should be defined by document or record type. For example, under the ISO 13485 provisions, records are retained for the organisation defined device lifetime or the period specified by applicable regulatory requirements, with a minimum of two years from device release. Retention requirements vary significantly between industries and record types.


Relevant obsolete manufacturing and testing documents must also remain available for the required period. A single retention period applied to every file may therefore be unsuitable.


Connect document control to data governance


Document control manages instructions and records. Data governance also considers how the information within those records is created, processed, checked, used and preserved.


This lifecycle approach can be translated into six practical questions:


1.Creation – Is the original information captured accurately with its context?

2.Processing – Can calculations and transformations be traced back to the source data?

3.Verification – Are completeness, consistency and accuracy checked?

4.Decision making – Can the evidence supporting a quality decision be retrieved?

5.Retention – Will data remain protected, readable and accessible for the required period?

6.Disposal – Is destruction authorised and controlled once retention obligations have been met?


Controls should reflect the importance of the data and the opportunity for undetected alteration or loss. For example, data used to support a product release decision deserves particular attention.


Paper, electronic and hybrid systems need defined controls


Changing the medium changes how controls are implemented. It does not remove the need for reliable documentation.


A hybrid arrangement might involve an electronic master template, a paper working copy and a scanned completed record. The organisation should define which version is authoritative, how issued copies are controlled, whether scans are complete and how the original records are retained.


FDA guidance recognises that paper and electronic components can coexist when the underlying record requirements are met and the content and meaning are preserved.


A paper printout or PDF does not automatically preserve every element of an electronic record. FDA specifically cautions against assuming printouts always satisfy pharmaceutical record requirements.


For hosted or outsourced services, define responsibilities for access, preservation, retrieval, backup, recovery and the return of records when the service ends.


Common documentation challenges


Common issues identified during audits and quality system reviews include:

  • Multiple versions of the same document being available for use

  • Uncontrolled templates used to generate records

  • Missing evidence of document approval

  • Undefined retention periods

  • Inadequate control of externally sourced documents

  • Electronic records that lack appropriate access or change controls


Addressing these issues early can significantly improve both compliance and operational efficiency.


Put the process into a practical SOP


A Document Management SOP should explain how the organisation manages document identification, ownership, preparation, review, approval, release, access, revision, external documents, obsolete versions, retention and disposal.


The procedure should match how people actually work and make their responsibilities clear. An eQMS can support approvals, version control and retrieval, but effective control also depends on suitable procedures, system setup and personnel training.


Conclusion

 

Finally, effective document management is not simply about maintaining procedures and forms. It is about ensuring that personnel have access to accurate information, quality decisions can be supported by objective evidence, and records remain trustworthy throughout their lifecycle. Regardless of whether an organisation uses paper-based systems, an eQMS or a hybrid approach, the principles of control, traceability and accessibility remain fundamental.

 

References and scope


This article draws on ISO 9001 clause 7.5, ISO 13485 clauses 4.2.1–4.2.5 and GMP documentation guidance. It is a practical overview, not a clause-by-clause demonstration of conformity. Sector specific requirements and retention periods need to be assessed separately.

Digital platforms like eQMS, LIMS, MES, EMS, clinical data systems, and automated lab equipment, are now foundational to modern regulated operations. To realise the full benefit of these systems without introducing regulatory or data integrity risk, organisations must adopt a structured, risk‑based approach that ensures systems remain fit for their intended use throughout their entire lifecycle.


The framework outlined in GAMP 5 developed by the International Society for Pharmaceutical Engineering (ISPE), provides widely recognised guidance for achieving this objective. GAMP 5 promotes a lifecycle-based and risk-driven methodology to computerised system validation, helping organisations balance compliance requirements with operational efficiency.


Systems that are clearly defined and well specified are significantly easier to implement, support, and maintain. This results in improved reliability, reduced downtime, and lower long-term operational costs. Applying GAMP 5’s lifecycle and risk-based principles enables organisations to implement and manage computerised systems more effectively and efficiently.


Key benefits of this approach include but not limited to

· Reduced time and cost required to achieve and maintain regulatory compliance

·  Earlier identification and resolution of defects, minimising impact on project timelines and budgets

·    More efficient and cost-effective operation and maintenance of systems

·    Stronger change management processes that support continual improvement

·   Greater ability to adopt innovative technologies while maintaining regulatory compliance


What is a Computerised System?

GAMP 5 defines a computerised system as a system consisting of hardware and software components together with the controlled functions or processes they support. This includes associated procedures, people, equipment, and documentation required for the system to operate effectively within a regulated environment.


Computerised systems encompass a broad range of applications, including but not limited to:


·       Document Management Systems

·       Electronic Quality Management Systems (eQMS)

·       Laboratory Information Management Systems (LIMS)

·       Automated laboratory equipment

·       Manufacturing Execution Systems (MES)

·       Process control systems

·       Clinical trial data management systems

·       Environmental Monitoring Systems (EMS)

·       Warehousing and distribution systems

·       Adverse event reporting systems


What is Computerised System Validation (CSV)?


A common misconception is that computerised system validation focuses only on testing digital systems. However, according to GAMP 5 Computerised System Validation (CSV) is a broader concept.


CSV is defined as achieving and maintaining compliance with applicable GxP regulations while ensuring that systems remain fit for their intended use throughout their lifecycle.


This is achieved through:

·   The adoption of validation principles, approaches, and lifecycle activities within a structured framework of validation plans and reports

·  The application of appropriate operational and procedural controls throughout the life of the system


GAMP 5 Lifecycle Approach


A core principle of GAMP 5 is the application of a lifecycle approach to the implementation and management of computerised systems. This lifecycle model ensures that system requirements are clearly understood and that activities are performed in a structured manner from system conception through development, release, operational use, and eventual retirement.


Rather than viewing validation as a one-time activity performed before system release, GAMP 5 emphasises that validation is a continuous process that spans the entire lifecycle of the system.


The typical lifecycle of a computerised system includes the following stages:


1. Concept and Planning

At this stage, the need for the system is identified and the scope of the project is defined. Key activities include defining business requirements, considering costs and benefits. An initial risk assessment or GxP assessment should be performed at this stage.


2. Project Phase

The project phase involves planning, supplier assessment and supplier selection. Business requirements are translated into functional and technical specifications. The system architecture, interfaces, and data flows are defined to ensure the system meets its intended purpose.


The system is then developed, configured, or installed according to the defined specifications. Documentation and configuration controls are established to ensure traceability.


Testing activities are performed to demonstrate that the system meets defined requirements and performs as intended. This may include installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ) or performance verification.

 

3. Operation

Once testing is successfully completed, the system is released for operational use. Procedures, training, and operational controls are implemented to ensure the system continues to function as expected.


During the operational phase, the system is maintained through change control, periodic review, incident management, and ongoing monitoring to ensure continued compliance and performance.


4. Retirement

The last phase is the final retirement of the system. It involves decisions about data retention, migration, or destruction, and the management of these processes.


By following a structured and risk-based validation approach, organisations can ensure that computerised systems consistently perform as intended while maintaining confidence in the integrity of their data and processes.


Key Principles of GAMP 5


The guidance outlined in GAMP 5, is built around several core principles that support efficient and compliant implementation of computerised systems in regulated environments.


These principles encourage organisations to apply a pragmatic and risk-based approach to validation activities.


1. Product and Process Understanding

A clear understanding of the product and the process being supported by the computerised system is essential. Organisations should ensure that system requirements are aligned with business processes and regulatory obligations to ensure the system is fit for its intended use.


For some manufacturing systems, process requirements depend on a thorough understanding of product characteristics. For these systems, identification of Critical Quality Attributes (CQAs) and related Critical Process Parameters (CPPs) enable process control requirements to be defined.


2. Lifecycle Approach within a QMS

Computerised systems should be managed using a structured lifecycle approach that covers planning, specification, design, configuration, verification, release, and ongoing maintenance. This ensures systems remain controlled and compliant throughout their operational life.


3. Scalable Lifecycle Activities

The validation strategy for a system should be defined in a validation plan and follow established policies and procedures. Validation activities should be scaled according to the level of risk associated with the system. Systems that have a direct impact on product quality, patient safety, or data integrity require more rigorous controls than systems with minimal regulatory impact. The outcome of supplier assessments should also be considered when defining the validation strategy.


4. Science-Based Quality Risk Management

Risk management principles should be applied to identify, assess, and control risks throughout the system lifecycle. This helps organisations focus validation efforts on areas that have the greatest potential impact on patient safety and product quality.


5. Leveraging Supplier Activities

Where systems are supplied by vendors, organisations should leverage supplier documentation, testing, and quality management systems where appropriate. This reduces duplication of effort while maintaining assurance that the system meets regulatory expectations.


6. Collaboration Between Business, IT, and Quality

Successful implementation of computerised systems requires collaboration between business process owners, IT specialists, and quality professionals. Cross-functional collaboration ensures that systems meet operational needs while maintaining compliance with GxP requirements.


Conclusion

By adopting a risk-based validation approach, leveraging supplier knowledge, and maintaining strong collaboration between business, IT and quality functions, organisations can achieve an effective balance between regulatory compliance and operational efficiency. This approach strengthens data integrity and system reliability while enabling organisations to confidently adopt new technologies as part of their digital transformation strategies.

bottom of page