Standard Operating Procedure

Validation of Spreadsheet Applications

This is an example of a Standard Operating Procedure. It is a proposal and starting

point only. The type and extent of documentation depends on the process environment.
The proposed documentation should be adapted accordingly and should be based on
individual risk assessments. There is no guarantee that this document will pass a
regulatory inspection.

Publication from
www.labcompliance.com
Global on-line resource for validation and compliance
Copyright by Labcompliance. This document may only be saved and viewed or printed
for personal use. Users may not transmit or duplicate this document in whole or in part,
in any medium. Additional copies and licenses for department, site or corporate use can
be ordered from www.labcompliance.com/solutions.
While every effort has been made to ensure the accuracy of information contained in
this document, Labcompliance accepts no responsibility for errors or omissions. No
liability can be accepted in any way.
Labcompliance offers books, master plans, complete Quality Packages with validation
procedures, scripts and examples, SOPs, publications, training and presentation
material, user club membership with more than 300 downloads and audio/web
seminars. For more information and ordering, visit www.labcompliance.com/solutions

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 2 of 14

Company Name:

Controls:
Superseded Document

N/A, new

Reason for Revision

N/A

Effective Date

Jan 1, 2004

Signatures:
Author

I indicate that I have authored or updated this SOP according to

applicable business requirements and our company procedure:
Preparing and Updating Standard Operating Procedures.
Name:
Signature:
Date:

Approver

I indicate that I have reviewed this SOP, and find it meets all
applicable business requirements and that it reflects the
procedure described. I approve it for use.
Name:
Signature:
Date:

Reviewer

________________________________
________________________________
________________________________

________________________________
________________________________
________________________________

I indicate that I have reviewed this SOP and find that it meets all
applicable quality requirements and company standards. I
approve it for use.
Name:
Signature:
Date:

________________________________
________________________________
________________________________

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 3 of 14

1. PURPOSE
Quality standards, regulatory agencies and some company policies require software
used for evaluation of critical data to be properly validated. Spreadsheet
applications are considered as software and should be validated to demonstrate
suitability for their intended use. The purpose of this operating procedure is to
ensure that Spreadsheet applications are validated during their development and
installation and periodically reevaluated during operation.

2. SCOPE
Validation of Spreadsheet applications used in regulated environments. Examples
are Excel Spreadsheets. The procedure applies whenever firms develop
Spreadsheet applications with and without VBA scripts.

3. GLOSSARY/DEFINITIONS
VBA - Visual Basic for Applications, Macro programming language for Microsoft
Office Products.
Note: For other definitions, see www.labcompliance.com/glossary.

4. REFERENCE DOCUMENTS
4.1. Validation Master Plan for Equipment and Computer Systems.
(Not part of this SOP, example can be ordered from
www.labcompliance.com/books/masterplan.htm)
4.2. SOP ###: Risk-Based Validation of Equipment and Computer Systems.
Available through: www.labcompliance.com/solutions/sops.
4.3. SOP ###: Change Control of Software and Computer Systems.
Available through: www.labcompliance.com/solutions/sops.
4.4. SOP ###: Development and Use of Spreadsheets in GxP/Part11
Environments.
Available through: www.labcompliance.com/solutions/sops.

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 4 of 14

4.5. SOP ###: Development and Maintenance of Test Scripts for Equipment
Hardware, Software and Systems.
Available through: www.labcompliance.com/solutions/sops.
4.6. SOP ###: Training for GxP, 21 CFR Part 11 and Computer Validation.
Available through: www.labcompliance.com/solutions/sops.

5. RESPONSIBILITIES
5.1. User
5.1.1. Defines user requirements.
5.1.2. Tests prototypes for usability.
5.1.3. Performs functional testing.
5.1.4. Proofreads user information.
5.1.5. Writes bug reports and enhancement requests.
5.2. Developer
5.2.1. Understands the user's environment and workflow.
5.2.2. Writes design specifications.
5.2.3. Reviews design specifications.
5.2.4. Writes code.
5.2.5. Reviews code.
5.2.6. Develops installation procedure.
5.2.7. Writes user information.
5.3. Validation Group
5.3.1. Prepares and maintain inventories of Spreadsheets.
5.3.2. Approves test procedures.
5.3.3. Develops programming standards and naming conventions.
5.3.4. Reviews test protocols.
5.4. Quality Assurance
5.4.1. Develops test plan.
5.4.2. Approves test protocols.
5.4.3. Approves release of Spreadsheet applications.

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 5 of 14

6. PROCEDURE
The extent of Spreadsheet validation depends on its complexity and on the impact
of the Spreadsheet on product quality. Any step can be passed over as long as
there is a sufficient explanation that the skipped step has no relevance for the
Spreadsheet accuracy.
6.1. Requirement Specifications (User)
Use steps in Attachment 7.1 to document URS.
6.1.1. Describe the task, how the problem is solved now and how the new
Spreadsheet will solve it more efficiently.
6.1.2. Describe user requirements (what the user wants to do with the
Spreadsheet), computer requirements (computer hardware, operating
system), regulatory requirements (GLP/GMP/GCP, 21 CFR Part 11) and
security requirements.
6.1.3. Specify minimum hardware and software requirements.
6.1.4. Describe the required skill level of the end users.
6.1.5. Describe how extensively and for long the Spreadsheet is intended to be
used.
6.2. Functional Specifications (Developer, review by user)
6.2.1. Describe the Spreadsheet in terms of the functions it will perform, and
write it in such a way that it is understood by both software developers
and by users.
6.2.2. Review the functional description against the requirement specifications.
References may be given to the user documentation.
Functional specifications are written by the developer. Note: Requirements from
6.1 and functions from 6.2 may be combined in one list. In this case the
complete list is written by the user and reviewed by the developer.
6.3. Design Specification (Developer)
6.3.1. Define how specified functional, security and regulatory specifications
can best be implemented.
6.3.2. Discuss alternative solutions, if any. Use programming standards and
naming conventions from your organization if available. Define file
structure, e.g., whether to use one Excel workbook with multiple sheets
or several single-sheet workbooks.
6.3.3. Define how to handle errors, e.g., how the application detects and deals
with errors.

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 6 of 14

6.3.4. Discuss the Spreadsheet design with at least one other competent
person.
6.3.5. Develop a matrix that references the design elements to
requirement/functional specifications. Use Attachment 7.2.
6.3.6. Review the design specifications against the requirement/functional
specifications. Use Attachment 7.3.
6.3.7. Document formulas or algorithms used within the program for data
analysis, processing, conversion or other manipulations.
6.4. Implementing the Code (Developer)
6.4.1. Write the code according to design specifications from 6.3 and by using
programming standards from your organization if available.
6.4.2. Annotate the code using documentation standards from your organization
if available. Annotation must be such that other people whose education
and experience are similar to the programmer can understand it.
6.4.3. The code documentation must clearly state the Spreadsheet title, revision
number and file name.
6.5. Structural Testing (Developer)
6.5.1. Testing includes structural code testing (white box testing, code review)
as well as functional testing (black box testing). Tests should be
traceable to user requirements and functional specifications. Structural
testing should be done by the programmer and at least one other person,
preferably another programmer.
6.5.2. Develop a matrix that references the source code elements to the design
specification. Use Attachment 7.4.
6.5.3. Check the code for mechanical errors (syntax) and logical errors (correct
implementation of formulas).
6.5.4. At least one other programmer should check the code as described in
6.5.3.
Note: For larger projects, structural testing should firstly be done by individual
developers and afterwards by a team.
6.6. Functional Testing (User)
6.6.1. Functional testing tests the program functions (black box testing). Tests
should be traceable to user requirements and functional specifications.
Test plans should be prepared by the validation group and approved by
the QA department. Functional testing should be performed by
anticipated users.

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 7 of 14

Note: Functional test person and the programmer must be different

persons.
6.6.2. Develop a test plan to test the Spreadsheet for all functions.
6.6.3. Develop a matrix that links functions to be tested to functional
specifications. Use Attachment 7.5.
6.6.4. Develop test cases and test data sets with known inputs and outputs.
6.6.5. Use test templates with the purpose of the test, the functions to be tested,
the test steps or methodology, the expected results and acceptance
criteria. Use Attachment 7.6.
6.6.6. Test protocols must clearly state the Spreadsheet title, revision number
and file name.
6.6.7. Tests should describe the test environment and the execution of tests.
6.6.8. Develop test cases and data test sets that can be used for current and
future testing and that simulate as much as possible the real-life
environment (life testing).
6.6.9. Include test cases with normal data across the operating range, boundary
testing and unusual cases (wrong inputs, stress testing etc).
6.6.10. Include procedures to verify calculations.
Note: This is not necessary for calculations as provided by the standard
software, e.g., Excel.
6.6.11. Include anticipated users of the software in the test program and
perform part or all of the tests in a typical users environment.
6.6.12. Specify how errors found will be classified and documented and what
corrective action will be taken.
6.6.13. Specify release criteria before the test starts.
6.6.14. Results should be documented and reviewed and approved by the
programmers, users and quality assurance departments.
6.6.15. Prepare a test summary sheet with all tests, results and suggested
corrective actions. Use Attachment 7.7.
6.7. Installation and Operational Checks Prior to Routine Use (User)
After the Spreadsheet application has been released, it should be distributed
and installed for routine use. Software should be verified for proper installation
and the installation process should be documented.
6.7.1. Install the Spreadsheet according to installation instructions.

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 8 of 14

6.7.2. Verify proper software installation. As a minimum, make a printout of the

file directory with all files and file sizes. Compare the listing with a
reference document as provided by the programmer.
6.7.3. Perform operational checks according to the test procedures supplied
with the Spreadsheets documentation.
6.7.4. Document installation and test results.
6.8. Ongoing Performance Checks During Routine Use
6.8.1. Specify type and frequency of checks as well as expected results and
acceptance criteria.
6.8.2. Develop test data sets for ongoing performance checks.
6.9. Error Tracking System and Response System
6.9.1. Develop a formal feedback system to report any problems and requests
for enhancements to the developer of the software.
6.9.2. A team consisting of user(s) and developer(s) should document, evaluate
and classify the problem or enhancement proposal and make proposals
for a solution.
6.10. Configuration Management, Change and Version Control
6.10.1. Develop a procedure for clear identification of each Spreadsheet and
any revision thereof by title and revision number.
6.10.2. Develop a procedure to initiate, authorize, develop, implement, test,
document and approve any changes to the software. Follow SOP 4.3.
6.10.3. Develop and maintain a historical file of changes and version numbers.
6.11. User Documentation and Training
6.11.1. The user documentation should describe the programs functionality,
formulae used for calculations and how to operate and test the program.
6.11.2. Describe which functions are implemented to meet the specified security
requirements, for example, limited authorized access to the system, the
program and data.
6.11.3. Specify the educational, experience and training requirements for the
operators of the program.
6.12. Records
All of the following should be retained:
6.12.1. Validation project plan.
6.12.2. Requirement specifications.
www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 9 of 14

6.12.3. Functional specifications (can be combined with requirement

specifications).
6.12.4. Design specifications.
6.12.5. Design reviews.
6.12.6. Code (e.g., VBA script).
6.12.7. Code reviews.
6.12.8. Functional testing.
6.12.9. Validation summary.
6.12.10. Installation procedure.
6.12.11. Installation records.
6.12.12. Test protocols.
6.12.13. Training records.
6.12.14. Change control procedure.
6.12.15. Error feedback and enhancement requests and response.
6.12.16. Operating manual.
6.13. Storage and Archiving
6.13.1. Archive documents as described in section 6.12.
6.13.2. Specify where documents should be archived to ensure easy access by
the operator during operation of the software and for inspections.
6.13.3. Document for how long documents should be archived.
6.14. Approvals
6.14.1. Approval of the validation protocol by the programmers, users and
quality assurance departments.
6.14.2. Approval of the requirement specification document, design
specification document and the test plan by the programmers, users and
quality assurance departments.
6.14.3. Approval and authorization of any changes to the software by the
programmers, users and quality assurance departments.

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 10 of 14

7. ATTACHMENTS
7.1. Attachment User Requirement Specifications
7.1.1. Introduction
7.1.1.1. The Application:
Describe the application.
7.1.1.2. Current Procedures and Limitations:
Describe current procedure and limitations.
7.1.1.3. The Plan to Overcome Current Limitations:
Describe how the new Spreadsheet will improve the process.
7.1.1.4. Operators:
Describe the type of operators who will use the Spreadsheet.
7.1.1.5. Hardware and Software Environment:
Describe current PC hardware, software and networking
environment.
7.1.2. Specifications
Specifications should describe:
7.1.2.1. Tasks the program should perform.
7.1.2.2. Usability and aesthetics.
7.1.2.3. Plausibility/limits of data entry.
7.1.2.4. Security/data integrity and traceability functions.
7.1.2.5. Check for potential process or equipment problem.
7.1.2.6. Computer hardware and software.

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 11 of 14

7.2. Attachment Design Specification

Matrix with Design Specifications vs. URS
Number

User Requirement

Design (e.g., formula)

7.3. Attachment Design Review

Matrix with Design Specifications vs. URS
Date:
Number

Design (e.g., formula)

Reviewer

Name:
Signature:
Date:

Comment

________________________________
________________________________
________________________________

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 12 of 14

7.4. Attachment Code Review

Date:
Number

Reviewer

Code Section

Name:
Signature:
Date:

Comment

________________________________
________________________________
________________________________

7.5. Attachment Functional Testing

Matrix with Functions to be tested vs. URS
Number

User Requirement

Test

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 13 of 14

7.6. Attachment - Test Cases for each function. Test cases should include
boundaries, high load and stress testing (unexpected entries).

Spreadsheet Title:
Revision Number:
File Name:
Test Number:
Specification:

Purpose of Test:

Test Environment (PC hardware, peripherals, interfaces, operating

system, Excel version):
Test Execution:
Step 1:
Step 2:
Step 3:
Expected Result:
Acceptance Criterion:
Actual Result:
Comment:
Criticality of Test:
Low 0

Medium 0

High 0

Test Person:
Printed Name: __________ Signature: __________ Date: ________

www.labcompliance.com (Replace with your companys name)

FOR INTERNAL USE

STANDARD OPERATING PROCEDURE

Document Number: S-264 Version Beta
Validation of Spreadsheet Applications

Page 14 of 14

7.7. Attachment - Test Summary Sheet with Corrective Actions

Spreadsheet Title:
Revision Number:
File Name:
Number

Test

Result

www.labcompliance.com (Replace with your companys name)

Corrective Action

FOR INTERNAL USE