Computer System Validation — Step by Step for Business Central
Computer system validation (CSV) is the documented process by which an organisation demonstrates that a computerised system does what it is designed to do, consistently and reliably, within defined operating conditions. For regulated manufacturers using Business Central, CSV is not optional — it is a regulatory requirement under EU GMP Annex 11, FDA 21 CFR Part 11, and sector-specific guidance that references GAMP 5.
This guide describes the CSV process for Business Central in a regulated manufacturing context, step by step. It is written for the people who must execute the validation: ERP project leads, QA managers, IT directors, and the consultants who support them.
Where CSV applies
CSV applies to computerised systems used in GxP activities — processes that are subject to Good Manufacturing Practice, Good Laboratory Practice, Good Clinical Practice, or similar regulatory frameworks. For Business Central, the question is: does the system process, store, or transmit GxP-relevant data? If yes, CSV applies.
GxP-relevant data in a typical BC implementation includes: batch and lot records, quality inspection results, approval workflows for GxP decisions, deviation and CAPA tracking, equipment calibration records, and change control approvals. Financial and HR data processed in the same BC tenant is typically not GxP-relevant and does not require validation.
The V-model
CSV follows the V-model: a structured sequence of specification and testing phases where each testing activity verifies the corresponding specification. The left side of the V is specification; the right side is testing; the bottom is the system itself.
The V-model ensures that testing is directly linked to requirements. A test without a corresponding requirement is not a validation test. A requirement without a corresponding test leaves a gap in the validation evidence.
Document hierarchy
Validation Strategy Document (VSD): the top-level document defining the overall validation approach, system boundary, risk framework, and responsibilities. Written before any other validation work begins.
User Requirements Specification (URS): describes what the system must do, in business language. Written by the business users and QA, not by IT or the vendor. The URS is the basis for all downstream testing.
Functional Specification (FS): describes how the system will meet the URS requirements. For BC standard functionality, vendor documentation (Microsoft's) substitutes for much of the FS. For custom extensions, integrations, and configured workflows, a project-specific FS is required.
Design Specification (DS): describes the technical architecture, where this level of detail is needed. For SaaS systems like BC, the DS is typically minimal — Microsoft manages the infrastructure.
Installation Qualification (IQ): documents that the system is installed correctly and that the environment matches the specification. For BC SaaS, the IQ covers tenant configuration, extension versions, integration connections, and user access configuration.
Operational Qualification (OQ): documents that the system operates as specified under normal conditions. OQ test protocols are written against the FS and URS. Each test case references the requirement it verifies.
Performance Qualification (PQ): documents that the system performs reliably under real business conditions. PQ is typically conducted with actual business users running realistic scenarios.
Validation Summary Report (VSR): the closing document summarising the validation activities, evidence, deviations, and conclusion. Signed by the validation owner and QA. The VSR formally closes the validation.
Scoping a BC CSV project
The most common mistake in BC CSV projects is incorrect scope definition. Over-scoping wastes resources on validation activities that provide no regulatory value. Under-scoping leaves genuine GxP risks undocumented and untested.
Scope definition starts with a risk assessment. Each BC module, configuration item, and extension is assessed for its potential impact on GxP data or processes. High-impact items receive full validation treatment. Low-impact items receive reduced testing proportional to their risk level.
A well-scoped BC CSV project validates: the lot and batch tracking configuration, the approval workflow configuration for GxP processes, the Change Log configuration and protection, the permission set configuration and access control, and the integration interfaces that transmit GxP data.
Periodic review
Validated status is not permanent. It must be maintained through periodic review — typically annual — that confirms the system remains in its validated state, all deviations and changes have been documented and assessed, and no new risks have been introduced since the last review. The periodic review report is part of the ongoing validation documentation package.
Common mistakes
Under-scoping: excluding modules or configurations that handle GxP data to reduce validation effort. This creates regulatory exposure.
Over-testing: writing hundreds of test cases that do not correspond to URS requirements. This produces large test documentation with low regulatory value.
Missing change control: failing to establish a change control procedure before the system goes live. Changes made after validation without documented change control impact the validated status of the system.
Retrospective testing: writing test cases after executing the tests, based on what was observed rather than what was required. This is not acceptable validation evidence.
Treating SaaS updates as non-events: Business Central SaaS updates automatically every six months (major waves) and monthly (minor updates). Each update requires a prospective impact assessment before the update is applied. A formal update management procedure must be in place before the first post-validation update cycle.
Maintaining CSV during SaaS updates
For Business Central SaaS, managing updates within a validated system requires a documented update assessment procedure. Before each major wave, the validation owner reviews the Microsoft release notes, assesses the impact on validated functionality and GxP configurations, and determines whether revalidation, regression testing, or documentation update is required. Minor updates are typically assessed using an abbreviated procedure. All assessments and decisions are documented and retained as part of the ongoing validation package.
Download the step-by-step computer system validation guide for Business Central as a PDF using the link below.