Validating a SharePoint Quality Register

Worked Example: Validating a SharePoint Quality Register
A scalable GxP approach for replacing Excel registers while retaining paper records as the authoritative GMP source.
This example represents a proposed risk-based approach. The final validation strategy should be appropriate to the organisation's procedures, regulatory context and intended use.
Return to Blog
The Use Case
What Are We Validating?
A SharePoint List configured as a deviation register. The paper system remains the authoritative GMP record. The SharePoint List provides structured support for process management and quality oversight.
The Paper Record Remains Responsible For
Recording the deviation and investigation
Documenting root-cause analysis
Recording impact and risk assessments
Approving the investigation and closure
Retaining signatures and supporting evidence
The SharePoint List Supports
Deviation identification and status tracking
Process ownership and due-date monitoring
Risk categorisation and deviation-type classification
Root-cause trending and management reporting
Resource prioritisation
The paper file remains the official GMP record. However, the SharePoint List contains GxP-relevant metadata used to support quality oversight and management decisions.
Validation Strategy
One Overview, Six Core Deliverables
The objective is to assemble sufficient evidence that the configured register is fit for its intended use. Documents should work together, with information referenced rather than repeatedly copied.
01
User Requirements Specification
Define intended use, required functions, users, data and boundaries.
02
Functional Risk Assessment
Identify credible failure scenarios and assess controls.
03
Configuration Specification
Document the controlled configuration implementing requirements.
04
Validation Plan
Define scope, approach and supplier reliance rationale.
05
Verification Protocol and Evidence
Provide objective evidence of fitness for intended use.
06
Validation Summary Report
Summarise completed evidence and document the basis for release.
Supporting Operational Controls
Access Management
Procedures
Training
Periodic Review
Change Control
Data Reconciliation
Document 1
User Requirements Specification
Purpose: Define the intended use, required functions, users, data and boundaries of the solution. Requirements should describe what the organisation needs, not every capability available in SharePoint.
The SharePoint Deviation Register will record structured summary information relating to paper-based deviation records. It will support status tracking, due-date management, trending, management review and quality resource prioritisation. The SharePoint List will not replace the approved paper deviation record or provide electronic approval of the deviation investigation.
Critical thinking applied: Requirements concentrate on intended use, critical data, access, traceability to the paper record and reporting reliability. Low-value platform requirements should not be added merely to increase document size.
Data Criticality
Not Every Column Has the Same Importance
Criticality should be based on how information is used, not simply whether it appears in a GxP-related system. A field used to allocate investigation resources may require stronger controls than a descriptive administrative field.
Process-Control Data
Deviation owner
Status
Due date
Closure date
Errors could reduce process visibility or delay follow-up actions.
Quality-Intelligence Data
Deviation type
Risk category
Main root-cause area
Process area
Product or site classification
Errors could produce misleading trends or affect decisions about quality resources.
Administrative Data
Internal notes
Meeting review date
Non-GxP display labels
Errors are less likely to affect quality decisions directly.
Document 2
Functional Risk Assessment
Purpose: Identify credible failure scenarios associated with the intended use and determine whether existing or proposed controls reduce risk to an acceptable level.
Example Assessment Structure
The FRA focuses on reliability of process tracking, consistency of classification, accuracy of reporting, register availability, protection against inappropriate changes and traceability to the paper record.
Critical thinking applied: The source investigation remains on paper, but inaccurate register metadata can still influence GMP-relevant decisions. Avoid failure scenarios that do not relate to the actual intended use.
FRA Coverage
What Should the FRA Consider?
Risk ratings should consider both the continued availability of the paper source record and the use of register data for management decisions. The paper source reduces some risks, but does not eliminate risks relating to trending, oversight, timeliness or resource allocation.
Incorrect Classification
Deviation type, risk category or root-cause area is incorrectly selected, affecting trends and resource decisions.
Missing Record
A paper deviation is not entered into the register, reducing visibility of the quality event.
Incorrect Status
The register shows a deviation as closed while the paper process remains open.
Incorrect Due Date
Management receives inaccurate information about overdue investigations.
Unauthorised Modification
A user changes classification or status without appropriate authority.
Lost Traceability
The electronic entry cannot be matched to the corresponding paper file.
Incorrect Report Output
Filters, mappings or dashboard logic produce misleading quality metrics.
Inappropriate Deletion
A register entry is removed, reducing visibility of a corresponding quality event.
Document 3
Configuration Specification
Purpose: Document the controlled configuration that implements the approved requirements and risk controls. This is configuration, not custom software development. Screenshots may support the specification but should not replace clear, reviewable configuration details.
Critical thinking applied: The specification should document settings that affect intended use, quality decisions, data integrity, security, traceability and reporting. Power Automate and Power BI connections must also be documented if used.
Document 4
Validation Plan
Purpose: Define how assurance will be established and how the validation package will be scaled to the solution's risk, complexity and novelty.
Proposed Scope — Include
Deviation register configuration
Critical data fields and controlled classifications
Permissions and version history
Required views and reporting outputs used for quality decisions
Register-to-paper traceability
Applicable Power Automate notifications
Exclude or Leverage
Microsoft's underlying software-development processes
Physical data-centre qualification
Generic testing of standard SharePoint functions unrelated to intended use
Repetition of supplier testing without a defined risk-based reason
Critical thinking applied: "Do not re-test Microsoft" should not mean "Microsoft is automatically compliant." The organisation remains responsible for its intended use, configuration, data, access model, processes, reporting and its decision to rely on supplier activities.
Document 5
Verification Protocol and Evidence
Purpose: Provide objective evidence that the configured register meets approved requirements and that important risk controls operate as intended. Testing should trace to requirements and risk controls without creating unnecessary duplication.
1
Create a deviation with all mandatory information.
2
Attempt to save a record without a required field.
3
Confirm only approved risk and root-cause values can be selected.
4
Update status and confirm the previous value remains available through history.
5
Confirm an authorised user can edit; a read-only user cannot.
6
Trace an electronic entry to the corresponding paper deviation.
7
Compare a report or dashboard sample with the underlying list data.
8
Confirm a closed deviation retains required summary and classification data.
Appropriate Evidence
Test record identifiers, screenshots where useful, exported results, permission results, direct comparison with source data, tester name and date, and documented deviations with resolution.
Critical thinking applied: More attention should be given to critical classifications, access controls, traceability and reports used for quality decisions. Testing should demonstrate fitness for intended use, not attempt to exercise every possible SharePoint function.
Document 6
Validation Summary Report
Purpose: Summarise the completed evidence and provide the documented basis for release. The report should state why the solution is considered fit for use, referencing detailed evidence rather than repeating every requirement or test step.
Example Content
Intended use confirmed
Validation deliverables completed
Requirements verified
Risk controls implemented and tested
Configuration baseline approved
Deviations assessed, resolved or accepted
Residual risks accepted by authorised stakeholders
Procedures and training available
Register approved for operational use
Outstanding actions identified where applicable
Suggested Approvals
Process Owner
System Owner
Quality Assurance Representative
The Report Should Not
Repeat every requirement in full
Copy all test steps from the protocol
Restate every risk entry
Instead, it should reference the detailed evidence and clearly document any limitations, residual risks and conditions of use.
Critical thinking applied: A concise, well-referenced summary report demonstrates proportionate governance. Bulk does not equate to rigour.
Operational Controls
Validation Is Not the End of Control
A validated configuration can become unreliable if classifications, permissions or reports change without control. Operational governance may provide more long-term assurance than repeatedly generating validation documents.
Procedures
Who creates and updates entries
When classifications are entered
How register data is reconciled with paper records
How errors are corrected
Training
The paper record remains authoritative
The meaning of controlled classifications
Responsibilities for timely and accurate data entry
Access Management
Register owners, editors and read-only users
Access approval and periodic review
Access removal on role change
Change Control
Changes to columns, choice values and permissions
Changes to views, reports and automations
Changes to intended use
Periodic Review
Continued fitness for intended use
Access, configuration changes and data quality
Incidents and reporting reliability
Effort Planning
Why the Deviation Register Requires the Greatest Relative Effort
The first implementation establishes validation templates, SharePoint register design standards, naming conventions, permission groups, controlled classification principles, risk assessment models, standard verification tests and operational procedures. These are reusable assets.
Percentages are illustrative planning assumptions, not prescribed validation requirements. The first register should be viewed as the development and validation of a reusable quality-register framework, not merely the validation of one list.
Framework Reuse
Adding a CAPA Register: Reuse the Framework, Assess the New Intended Use
The CAPA register should not be approved solely because the deviation register was validated. The organisation must still confirm intended use, assess new risks, document CAPA-specific configuration and verify CAPA-specific requirements.
Reusable Framework Content
SharePoint platform description
Supplier reliance rationale
Validation templates and permission model
Version-history expectations
Common data-integrity risks
Common access tests
Common change-control process
Training framework and periodic review method
CAPA-Specific Content
CAPA intended use and lifecycle
CAPA source and ownership
Action due dates and effectiveness-check requirements
CAPA status values and classifications
CAPA-specific reporting
Process-specific risks
Process-specific verification
Reuse is justified where the platform, governance, controls and verification methods remain equivalent. New assessment is required where the process, data, reports or quality decisions differ.
Scalable Model
Relative Effort for Subsequent Registers
The illustrative comparison below uses the initial deviation register as 100 effort units. Actual effort depends on process differences, reporting complexity, automation, local procedures, document templates and review cycles.
Factors That Could Increase CAPA Effort
Electronic approvals or complex workflow logic
Effectiveness-check automation
Multiple linked lists or system integration
Calculated GxP decisions
Power BI transformation or calculated measures
Data migration from an existing register
Factors That Support Greater Reuse
Common register template and permission groups
Standard configuration specification
Standard test library
Common reporting patterns
No custom code; simple notifications only
Consistent operational procedures
Governance Model
Validate the Framework, Then Configure and Verify Each Register
A more defensible principle than "validate once" is: establish the common framework once, then perform proportionate assessment and verification for each configured use case.
For Every New Register
01
Define intended use
02
Identify process-specific requirements
03
Assess new and changed risks
04
Document configuration
05
Verify critical functions and controls
06
Approve for operational use
Scope Boundaries
When the Lightweight Approach Is No Longer Enough
Risk is determined by intended use and reliance, not by the Microsoft product name. A SharePoint List may be low complexity, but the controlled process built around it can become more significant as automation and decision-making increase.
Reassess When the Solution Introduces
Electronic approval of GMP records or electronic signatures
Complete electronic investigations
Automated risk classification or product-impact decisions
Automated CAPA effectiveness decisions
Complex workflow branching or custom code
System-to-system integration
Automated regulatory reporting
Replacement of the paper source record
When any of these conditions apply, a more extensive validation strategy is likely to be appropriate. The organisation should revisit its risk assessment and consider whether the lightweight register approach remains adequate.
Final Takeaway
Proportionate Assurance, Not Minimal Assurance
Paper Remains Authoritative
The paper form remains the official GMP record. SharePoint provides process management and quality intelligence, not a replacement for controlled records.
Metadata Matters
Reportable metadata can influence GMP-relevant decisions. Validation therefore focuses on data consistency, traceability, access and reporting reliability.
Build Once, Reuse Thoughtfully
The initial deviation register establishes a reusable quality-register framework. A CAPA register reuses common controls but still receives process-specific assessment and verification.
Scale to the Risk
Documentation is scaled according to intended use, risk, complexity and novelty. The goal is not document volume; it is demonstrable fitness for use.
The goal is not to prove that SharePoint works. The goal is to demonstrate that the organisation's configured register, supporting processes and controls provide reliable information for their defined GxP use.