// approach
Four phases, no surprises in audit
We stay with a system for its whole life, not only through validation. Each phase produces documents agreed with the Quality Unit before moving to the next, so nobody discovers at the end that something else was needed. Data integrity is checked in every phase, not at the finish line.
-
PHASE 01
Assessment & classification
It starts by looking at what is there. System inventory, GAMP classification, GxP impact, associated risk and how the data stands against ALCOA+.
// activities
- Census of computerised systems
- Classification by GAMP category
- Determination of GxP impact
- Risk analysis by critical function
- Initial check against the nine ALCOA+ attributes
- Assessment of the vendors involved
// output
- → system inventory
- → risk assessment
- → validation plan
- → gap analysis
This phase determines what everything else will cost. Getting it wrong means over-documenting trivial systems and neglecting critical ones.
-
PHASE 02
Specification
What the system must do is written down before it is configured. Requirements are approved by the Quality Unit: this is where the misunderstandings that would otherwise surface in testing get avoided.
// activities
- Gathering user requirements
- Drafting functional specifications
- Configuration and design specifications
- Building the traceability matrix
- Formal review and approval
// output
- → URS
- → functional specification
- → design specification
- → traceability matrix
A requirement that cannot be tested is not a requirement. Every URS entry must be able to become a verifiable test.
-
PHASE 03
Testing & qualification
Execute and record. Installation, operation, performance: every protocol is executed and deviations are managed formally, not tidied up afterwards.
// activities
- Installation qualification (IQ)
- Operational qualification (OQ)
- Performance qualification (PQ)
- Deviation management and closure
- Verification of requirement coverage
// output
- → executed protocols
- → deviation log
- → validation summary report
- → release for use
A documented and resolved deviation is a sign of control. An unrecorded deviation is a finding.
-
PHASE 04
Operation & review
The longest phase and the most neglected. Systems change, users change, vendors ship updates: without active management, compliance erodes without anyone noticing.
// activities
- Change control with impact assessment
- Incident and problem management
- Periodic system review
- Audit trail review
- Decommissioning and historical data
// output
- → change control records
- → periodic review report
- → audit trail review
- → decommissioning plan
At decommissioning, data must stay readable for the full retention period. That is planned in advance, not when the server is switched off.
Three rules we do not bend
// proportion
Documentation effort follows risk. A category 1 spreadsheet does not get the same treatment as an electronic batch record, and the reverse holds too.
// traceability
Every requirement leads to a test, every test to a result, every deviation to a recorded decision. If it is not traceable, in an audit it did not happen.
// approval first
Nothing is built before requirements are approved. Redoing a qualification costs far more than agreeing a specification.
Where are you in the cycle?
Whether you are starting from scratch, recovering a legacy system or answering a finding, the first step is always understanding what is already there.