Spreadsheet Validation in 2026: A Risk-Based Approach That Holds Up in Audits

What Changed in 2026, and What Did Not

On February 3, 2026, FDA issued Computer Software Assurance for Production and Quality Management System Software. It supersedes the final guidance titled Computer Software Assurance for Production and Quality System Software, issued September 24, 2025, only a few months earlier.¹ The guidance history in the document explains the reason: the February 2026 version was issued under Level 2 procedures, with revisions to align it with the amended device quality regulation, now called the Quality Management System Regulation (QMSR). That rule took effect on February 2, 2026, and incorporates ISO 13485:2016 by reference into 21 CFR Part 820.²

If you last read the September 2025 edition, the risk framework will look familiar. What changed is the regulatory framing around it: the guidance now cites ISO 13485 subclauses, as incorporated into Part 820, as the source of the validation requirement, and the title now says “Quality Management System.” The guidance still supplements FDA’s 2002 General Principles of Software Validation and supersedes Section 6 of that document, the section on automated process equipment and quality system software.²

Why a Device Guidance Matters to Pharma and Biotech

Be precise about scope when you cite this guidance. It was prepared by the Center for Devices and Radiological Health and the Center for Biologics Evaluation and Research, in consultation with the Center for Drug Evaluation and Research, the Office of Combination Products, and the Office of Inspections and Investigations.² It is written for medical device manufacturers. It does not replace the drug GMP regulations, and a drug manufacturer cannot point to it as the legal basis for its validation approach.

It still matters to pharma and biotech for two reasons. First, it is FDA’s most detailed current statement of what risk-based assurance looks like in practice, and CDER was consulted on it. Second, it names spreadsheets directly, with a worked example of how the same product can need very different levels of assurance depending on how it is used. When your quality unit writes a spreadsheet procedure, this is the clearest statement of agency thinking you can reference, alongside the drug regulations that are the legal requirement.

The Drug Requirements Have Not Moved

For drug manufacturers, the legal foundation is the same as it has been for decades. Under 21 CFR 211.68(b), “Input to and output from the computer or related system of formulas or other records or data shall be checked for accuracy.” The same paragraph continues: “The degree and frequency of input/output verification shall be based on the complexity and reliability of the computer or related system.”³ Read those two sentences together and you have a risk-based rule that long predates CSA: check the output, and scale how often and how hard you check to how complex and how reliable the system is. That sentence does more work for spreadsheets than any guidance document.

The laboratory records rule adds a second requirement that spreadsheets often fail. Under 21 CFR 211.194(a)(5), laboratory records must include “A record of all calculations performed in connection with the test, including units of measure, conversion factors, and equivalency factors.”⁴ A printout showing only the final number does not meet that on its own. The calculation has to be reconstructable.

Where electronic records are involved, FDA’s 2003 guidance on the scope and application of 21 CFR Part 11 still governs how the agency reads that regulation.⁵ In Europe, the relevant text is EU GMP Annex 11 and the European Medicines Agency’s questions and answers on it, which address spreadsheets by name.⁶ We come back to both below.

GAMP 5 Second Edition Supplies the Method

The industry method for all of this is ISPE’s GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition, published in 2022. It keeps a dedicated appendix, Appendix S3, titled “End User Applications Including Spreadsheets.”⁷ In their summary of the Second Edition for Pharmaceutical Engineering, Sion Wyn and Chris Clark list among the updates “Additional data integrity considerations for end-user applications including spreadsheets and more detailed risk-based decision recommendations.” They also note that software categories 3 to 5 should be viewed as a continuum, and that the software category is only one factor in a risk-based approach.⁸ The FDA guidance itself points readers to GAMP 5 Second Edition as a resource on testing methods.²

So the regulatory picture in 2026 is consistent. The drug regulations require accuracy checks scaled to risk. The European Q&A requires templates to be checked and version controlled. GAMP 5 supplies the method. And FDA’s current CSA guidance shows, with a spreadsheet as its example, how to spend effort where a failure would matter.

When a Spreadsheet Is a Computerized System

A common scoping mistake is to ask whether “Excel is validated.” That question has no useful answer. The spreadsheet application is widely used commercial software. What carries GxP risk is the file your team built on top of it: the formulas, the lookups, the links to other files, and sometimes the macros.

The Application Is Not the Problem. The File Is.

The CSA guidance makes this point with a specific example. It describes a commercial off-the-shelf spreadsheet used only to document time and temperature readings for a curing process. For that use, the guidance says a manufacturer may not need assurance activities beyond what the software developer already did plus initial installation and configuration, because documenting readings poses a low process risk. Then it changes one thing. If the manufacturer also builds custom formulas that automatically calculate time and temperature statistics used to monitor the process, the guidance says “additional validation by the manufacturer might be necessary.”²

That is the whole scoping principle in one example. The same product, on the same computer, moves from “install and configure” to “validate the formulas” the moment it starts computing something the quality system relies on. Your scope decision is about the function of the file, not the name of the product.

The guidance also sorts software into three groups by intended use. Software used directly in production or the quality system includes software that collects and processes production or quality data or maintains a quality record. Software that supports production or the quality system includes software for general record-keeping that is not part of the quality record. Software that is generally not in scope includes general business tools such as email and accounting applications.² Spreadsheets appear in all three groups within a single company, which is why a blanket policy in either direction fails.

Four Questions That Settle Scope

A scope decision should be factual and checkable, so that two reviewers reach the same answer. Four questions, asked in order, are enough for almost every file.

The FDA guidance recommends that manufacturers document their decision-making process for determining whether a software function is used as part of production or the quality system.² That applies to the “no” answers as much as the “yes” answers. An inspector who finds a spreadsheet you decided was out of scope will ask to see why, and a one-line documented rationale is a far better answer than a verbal explanation.

The Paper Printout Question

Question 3 is where many teams go wrong, because the printout habit feels like a control. FDA’s Part 11 scope guidance says that when people use computers to generate paper printouts of electronic records, and those paper records meet all predicate rule requirements, and people rely on the paper records to perform regulated activities, FDA would generally not consider them to be using electronic records in lieu of paper.⁵

The same guidance then adds the condition that matters. If you generate a printout but still rely on the electronic record to perform regulated activities, the agency may consider you to be using the electronic record, and it may take your business practices into account. It recommends that “for each record required to be maintained under predicate rules, you determine in advance whether you plan to rely on the electronic record or paper record to perform regulated activities.”⁵

In practice, a laboratory that prints a result sheet but trends from the electronic file, recalculates from it during an investigation, or copies values from it into the next month’s report is relying on the electronic file. And even when the printout is the record, 211.194(a)(5) still requires the calculation to be recorded, so a printout that shows only values and hides the formulas leaves a gap.⁴

Finding every file in the first place is a separate exercise, and we covered the inventory method, including how to surface files on personal drives, in Replacing Spreadsheets in QC Without Starting a Two-Year Project. This article picks up once you have the list and need to decide how much validation each file needs and how to defend that decision.

Classifying Spreadsheets by Risk

Once a file is in scope, the question becomes how much assurance it needs. The CSA guidance frames this around one test. FDA considers a software function to pose a high process risk “when its failure to perform as intended may result in a quality problem that foreseeably compromises safety.” Everything else is “not high process risk,” and FDA says a manufacturer may still use intermediate levels such as moderate or low for its own purposes, in which case the “not high” portions of the guidance apply.²

That test was written for device safety, but it translates directly to drug GMP if you substitute the outcomes that matter for a drug: a wrong release decision, a wrong result on a certificate of analysis, a missed out-of-specification result, a wrong stability conclusion, or a wrong number in a regulatory filing.

Start From What a Wrong Answer Would Do

The guidance gives examples on both sides of the line. Functions that are generally high process risk include those that “Measure, inspect, analyze and/or determine acceptability of product or process with limited or no additional human awareness or review.” Functions that are generally not high process risk include those intended to “manage data (process, store, and/or organize data), automate an existing calculation, increase process monitoring, or provide alerts relevant to managing data when an exception occurs in an established process.”²

Notice the tension for laboratory spreadsheets. An assay template “automates an existing calculation,” which sounds like the low side. It also determines the acceptability of a product, which is the high side. The deciding phrase is “with limited or no additional human awareness or review.” A calculation whose result goes straight onto a certificate of analysis, with a second-person review that checks transcription but never recalculates, is on the high side. The same calculation, where an independent system or an independent recalculation would catch an error before release, can reasonably be placed in a lower class. That is the question to ask of every in-scope file.

Detectability Is the Factor Teams Underuse

The CSA guidance lists controls elsewhere in the quality system that can reduce the assurance effort a software function needs. These include established processes that fully verify the output, additional process controls, and data collected to detect issues after implementation. Its example: if all outputs of a process undergo verification testing, those controls can be used to reduce the effort of assurance activities appropriate for the software.²

For spreadsheets this matters in both directions. A downstream check can lower the risk class, but only if it is a real, independent check that would catch a formula error. A second-person reviewer who compares the printed result to the typed result in the laboratory system is checking transcription, not arithmetic. If you use a downstream check to justify a lower class, write down exactly what that check compares and confirm it would detect a wrong formula. Otherwise you have lowered the class on an assumption.

Complexity and Custom Code

The third factor is what the file contains. GAMP 5 Second Edition treats software categories 3 to 5 as a continuum, and its authors stress that category is only one input.⁸ For spreadsheets, a practical reading is that complexity rises in steps: simple arithmetic on typed inputs, then nested logic and lookups, then links to other workbooks or external data, then macros or scripts.

The European position on the last step is explicit. The EMA’s Annex 11 questions and answers state: “Validation according to paragraph 4 of annex 11 is required at least for spreadsheets that contain custom code (e.g. Visual Basic for applications). Formulas or other types of algorithm should be verified for correctness.”⁶ Note the words “at least.” Custom code is the floor that triggers full validation, not the only case where it applies.

These four classes are a Sakara Digital working convention, not a regulatory taxonomy. What matters is that your classes are defined in writing, that each maps to a fixed set of assurance activities, and that the classification of each file is recorded with its reasoning. Inspectors do not expect a particular number of tiers. They expect consistency.

What a “Not High Risk” Record Still Looks Like

Lower risk means less testing, not no evidence. The CSA guidance includes an example record for a spreadsheet built to collect and graph nonconformance data stored in a controlled system, where other controls ensure nonconforming product is not released. The spreadsheet is judged not high process risk, and the manufacturer uses rapid exploratory testing.²

Even so, the example record contains a stated intended use, a risk-based analysis explaining why failure would not foreseeably compromise safety, the file name and version tested, the test type, the goal, a list of testing objectives with pass or fail results, a deviation found during testing (text entered into a numeric field), the fix (a validation rule permitting only numeric input), the retest, a conclusion, and the date and name of the tester.² That is about a page. It is also a good model for your Class C record: short, specific, and honest about what was found.

Templates Versus One-Off Calculations

This distinction decides where validation effort goes, and it is the one most procedures handle badly. A template is a file built once and used repeatedly with new inputs: the assay workbook opened for every batch, the stability trend file refreshed every pull point. A one-off calculation is a file built for a single purpose and used once: a recovery calculation for a particular investigation, a conversion needed during a method transfer, an impact assessment for a single deviation.

They need different controls because they fail differently. A template error repeats on every use until someone finds it, so the control belongs up front: prove the template correct, then keep it from changing. A one-off error happens once, so validating the file in advance is wasted effort; the control belongs at the point of use, as an independent check of that single result.

The EMA explains why templates exist in the first place: “Templates of spreadsheets help to avoid erroneous calculations from data remaining from previous calculations.” The same answer says templates should be checked for accuracy and reliability under Annex 11 section 7.1 and stored in a way that ensures version control under Chapter 4 section 4.1.⁶ A template is a control in its own right. It stops a common spreadsheet error in laboratories, which is opening last week’s file, overwriting most of the inputs, and missing one.

What to Verify in a Template

FDA’s own laboratories publish their expectations. The FDA Office of Regulatory Affairs laboratory manual on statistics and data presentation says spreadsheets developed in its laboratory “should be looked upon as in-house developed software that are qualified before use, just as instruments are qualified before use.” It then lists considerations for design and validation, including locking all cells except input cells, making spreadsheets read-only with password protection, rejecting data outside acceptable conditions, verifying calculations by a manual method and keeping a record, entering extreme as well as expected values, entering nonsensical data, keeping a permanent record of all cell formulas with documented revisions, and periodically revalidating.⁹ That list is a reasonable minimum for a Class A template, and it has the advantage of coming from FDA’s own laboratory practice.

Rounding and Precision Tests

Rounding errors are dangerous because the template looks correct for every ordinary input. Three separate issues need test cases.

The rounding rule itself. Results compared against a specification must be rounded according to the rule the procedure requires. The FDA laboratory manual summarizes the USP convention: a result is compared to the limits after proper rounding, and results are reported to the same number of decimal places as the limit. Its example uses limits of 98.0 to 102.0 percent. A result of 102.03 percent rounds to 102.0 percent and meets the limit; a result of 102.05 percent rounds to 102.1 percent and does not.⁹ Those two values belong in the test set of any template that compares a result to a limit. Rounding conventions also vary. In a 2013 Pharmaceutical Technology article on rounding for comparison with specifications, Chris Burgess compared the simple rounding rules with an unbiased rounding procedure and showed that Excel’s standard ROUND function did not match the unbiased result in one of his four examples.¹¹ The practical point is that your requirement must name the rounding rule, and your tests must include values where the rules disagree.

Display versus stored value. Formatting a cell to show one decimal place changes what is displayed, not what is stored. A template that displays a rounded result but compares the unrounded value to the limit can report a visible 102.0 percent next to a “fail,” or worse, a visible 102.1 percent next to a “pass.” Test that the value used for the comparison is the rounded value the procedure requires, and that the displayed value is the same number.

Floating-point precision. Microsoft’s own documentation explains that Excel follows the IEEE 754 specification for storing numbers and that it can store a very wide range of values, but “it can only do so within 15 digits of precision.” The same article explains that some decimal fractions cannot be represented exactly in binary and are stored with a tiny rounding error.¹⁰ For most laboratory arithmetic this is irrelevant. It matters in two places: equality tests (a formula that checks whether two calculated values are exactly equal can return false when they look identical), and values that fall exactly on a rounding boundary after a chain of calculations. Include at least one test case of each kind if your template uses them.

What to Verify in a One-Off Calculation

For a one-off calculation, the evidence is the check, not a validation package. Section 211.68(b) requires input and output to be checked for accuracy, scaled to complexity and reliability.³ For a file used once and never tested, reliability is unproven, so the check has to be thorough. A defensible one-off record contains:

• The inputs, each traceable to its source (instrument printout, controlled system report, logbook entry).
• The formulas, visible to the reviewer. Printing a second copy with formulas displayed, or attaching the file itself, meets this; a values-only printout does not.
• An independent verification of the result by a second person, by a different method: a hand calculation, a calculator, or a separate validated tool. Re-reading the same spreadsheet is not independent.
• The name of the verifier and the date, recorded with the calculation, which also meets the 211.194(a)(5) requirement to record the calculation with its units and factors.⁴
• The file saved with the record it supports, read-only, so it cannot be reopened and reused as a template.

When a One-Off Stops Being One-Off

The failure mode here is predictable. A one-off file is built for an investigation, it works, someone saves a copy for the next similar investigation, and a year later it has been used thirty times with no validation and a different set of manual checks each time. R.D. McDowall described this pattern in Spectroscopy: in a laboratory where spreadsheets are well embedded, “a spreadsheet developed in the morning could be the department standard by the afternoon.”²¹

Put a simple rule in your procedure: the second use makes it a template. The first time a one-off file is reused for a new purpose, it must go through the template process before that use, or the second calculation must be built as a new file with its own independent check. This rule is easy to state, easy to audit, and stops the most common path by which unvalidated templates enter a laboratory.

Locking, Protection, and Version Control

Once a template is validated, the remaining risk is that it changes without anyone knowing. Protection, location, versioning, and change control address that risk. Each has limits that should be stated plainly in your procedure, because an inspector who knows those limits will test whether you do.

Protection Guards Against Accidents

Locking cells and protecting the worksheet is expected. FDA’s laboratory manual lists it first.⁹ The EMA says files and calculations should be secured so that formulas are not accidentally overwritten.⁶ Both use the language of accidental or inadvertent change, and that is the right way to understand what protection does.

Microsoft’s own support page is direct about it: “Worksheet level protection isn’t intended as a security feature.” The page explains that it prevents users from modifying locked cells, and that protecting a worksheet is different from protecting a file or a workbook with a password.¹² A risk assessment that describes worksheet protection as preventing deliberate alteration overstates the control. Describe it as what it is, a guard against accidental edits, and put the controls against deliberate change somewhere else: in who can write to the master location, and in the review that compares each use against the released version.

Where the Master Lives

The location of the master copy does more for control than any password. A validated template should exist in one place, where analysts can open it but cannot save over it, and where only a named owner or administrator can publish a new version. Analysts save their completed calculation as a new file, with the batch or sample identifier in the name, in a location tied to the record it supports.

Three practices keep this working:

• Version identity on the output. The template name and version appear in a locked header cell that prints on every page. A reviewer can then confirm, from the printout alone, that the released version was used.
• A released-versions list. One controlled list of every template, its current version, and its release date. Reviewers check the version on the printout against this list.
• Retirement of old versions. When a new version is released, the old master is moved to an archive location that users cannot open for new work. Uncontrolled copies of old versions are a common way for a validated template to stop being validated.

Version History Is Not an Audit Trail

Cloud storage has made spreadsheet history much better than it was, and it is tempting to call it an audit trail. Read the documentation before you do.

Excel’s Show Changes feature displays recent changes to specific cells, ranges, sheets, or a whole workbook, provided everyone edits in Excel apps that support co-authoring. Microsoft’s help page also lists what it does not show, including chart and object edits, PivotTable operations, formatting changes, and hiding cells or filtering. It notes that “The Changes pane shows only the most recent changes,” and that edits made in a one-time purchase or older version of Excel cannot be tracked and will also clear the Changes pane.¹⁴

SharePoint and OneDrive version history keeps earlier versions of the whole file, but administrators set limits on it. Microsoft’s documentation describes an automatic setting that manages version storage, and manual settings where versions are deleted after a set count or age. Its example is a library configured to keep 500 major versions with a 365-day expiration, which stores no more than 500 versions and deletes any version older than 365 days. The same page notes that version storage depends on the limits configured on a library, user deletion activity, and retention policies.¹³ In other words, what history exists depends on settings someone chose, and users can delete versions themselves.

None of this makes cloud history useless. It is a helpful detective control, and it is far better than a file on a local drive. But it does not record why a change was made, it can be cleared or trimmed by settings outside the laboratory’s control, and it does not cover every kind of change. If your procedure relies on it, specify the library settings, confirm them with IT, test that a formula change appears in the history, and review the settings periodically. Then describe it in your risk assessment as a supporting control, not as the audit trail.

The Application Under Your Template Changes Every Month

Here is the 2026 issue that older spreadsheet procedures do not address. Validation used to assume a fixed installed version of the spreadsheet application. That assumption no longer holds for most organizations running Microsoft 365. Microsoft’s update channel documentation describes Current Channel, which delivers new features as soon as they are ready, and Monthly Enterprise Channel, which delivers them once a month on the second Tuesday. It also announces that beginning July 2026, Semi-Annual Enterprise Channel will receive feature and security updates monthly, on the same basis as Monthly Enterprise Channel.¹⁵ Whatever channel your IT group uses, the application under a validated template now changes monthly.

You cannot run change control on every Microsoft release, and the CSA framework does not ask you to. The guidance supports relying on the vendor’s own development and testing as a starting point, applying purchasing controls to the vendor, and using data collected during operation to detect problems.² A proportionate approach for spreadsheets has three parts:

• Assess the application vendor once, and record why standard functions (arithmetic, statistical functions, lookups) are relied on without retesting at each release. Built-in functions are the vendor’s responsibility; the formulas you build with them are yours.
• Keep a small, automated or scripted known-answer test set for each Class A template: the boundary cases above plus a few typical results. Rerun it after significant application updates, or on a fixed schedule, and keep the record.
• Treat new application features as out of scope for validated templates until assessed. A template that begins using a new function, a data connection, or an embedded script is a changed template, and goes through change control.

What Inspectors Ask, and the Evidence That Answers Them

Inspectors do not start with your spreadsheet procedure. They start with a result, usually on a certificate of analysis or in an investigation, and trace it back. FDA’s inspection guide for pharmaceutical quality control laboratories tells investigators to “Be prepared to examine all records and worksheets for accuracy and authenticity” and to verify that raw data are retained to support the conclusions found in laboratory results.²⁰ The spreadsheet questions follow from that trace.

What Recent Warning Letters Show

Three letters show the pattern clearly, and each adds something different.

An error found by the investigator. In a December 2019 warning letter to Tismor Health and Wellness, FDA wrote that the firm failed to validate the Excel spreadsheet used to perform an assay calculation, that its procedures lacked guidance on how to check and manually verify the calculation sheets, and that the investigator identified a calculation error in the spreadsheet: an incorrect formula for averaging the internal standard peak area. The letter states: “There is no assurance that the associated assay results recorded are reliable and accurate.” The firm’s retrospective review then found a second error, a transcription entry error, in a batch that had already been released, although the recalculated result was still within specification. The firm committed to manually check calculations until the spreadsheet was validated. FDA still found the response inadequate: “You have not fully assessed the potential impact of using data from unvalidated, unsecured spreadsheets for critical CGMP functions.”¹⁷

Two lessons follow. Manual checking was accepted as an interim measure, not as the answer. And the gap FDA named was impact assessment: what else did the unvalidated file touch?

Files that were not kept. In an October 2025 warning letter to Taizhou Kangping Medical Science and Technology, FDA wrote that Excel worksheets used to perform chromatogram calculations were not retained, and that the inspection documented the deletion of several recent Excel spreadsheets used to perform suitability and assay calculations. The QC supervisor confirmed that the spreadsheets relied on for finished product release “had not been validated, controlled, retained, or quality verified for data integrity before they were used for product release.”¹⁸ Four failures in one sentence, and the one that makes the others impossible to fix is “retained.” A calculation that no longer exists cannot be verified after the fact.

A spreadsheet among wider controls. In an April 2022 warning letter to a university chemistry department performing CGMP testing, FDA listed data integrity concerns that included results stored in an uncontrolled folder, a shared master login with full administrative access, missing backups, and software without an audit trail. Among them: “The Excel spreadsheet used to calculate spike recovery and final results for the (b)(4) analysis was uncontrolled.”¹⁹ Inspectors rarely cite a spreadsheet in isolation. It usually appears as one symptom of a laboratory where data controls are weak across the board, and the spreadsheet is often the easiest one for them to demonstrate.

The Questions, and the Evidence That Answers Them

From these letters and FDA’s own laboratory expectations, the questions are predictable. The table pairs each with what it tests and the evidence that answers it in minutes rather than days.

The Follow-Up Question

If an inspector finds an unvalidated calculation, the next question is always about scope of impact: which batches, which results, which decisions used this file, and were any of them wrong? The Tismor letter shows FDA expects a full answer, not a promise to validate going forward.¹⁷

You can prepare for that question before any inspection. For every Class A template, keep a way to list the results it produced, even if that is only a naming convention for completed files in a controlled folder. If a defect is ever found, a list of affected results turns an open-ended investigation into a bounded one. Without it, the only honest answer to “which results used this file?” is “we don’t know,” and that answer tends to widen the finding.

Writing the Procedure That Holds It Together

Everything above needs one procedure that makes it repeatable. A spreadsheet SOP that holds up in inspections is usually shorter than teams expect, because most of the work is in decisions that can be written as rules. These are the parts it needs.

The Parts of a Spreadsheet Procedure

1. Scope and definitions. What counts as a template, a one-off calculation, and a supporting file. Include the four scope questions and the rule that out-of-scope decisions are recorded.
2. Risk classification. Your classes, the criteria for each, and the requirement to record the reasoning, including any downstream check used to lower a class and what that check compares.
3. Assurance by class. A table that fixes what each class requires: scripted testing, exploratory testing, boundary tests, approval level, periodic review interval. Fixing this in a table removes the argument about each file.
4. Template development and release. Requirements, formula specification, test design including rounding and boundary cases, protection, version identity, approval.
5. One-off calculations. What the record contains, what counts as an independent check, where the file is saved, and the second-use rule.
6. Storage and access. Where masters live, who can publish them, how old versions are retired, and the cloud library settings that support history.
7. Change control. What counts as a change (formula, layout of inputs, rounding, new function, new data connection) and the proportionate retest for each.
8. Application updates. How the known-answer test set is rerun and on what schedule, and how new application features are assessed before use in a template.
9. Periodic review. A scheduled check that each template in use matches its released version, that protection is intact, that the formulas still match the current method, and that the file is still needed. FDA’s laboratory manual includes periodic revalidation with verification of cell formulas, manual reverification of calculations, and confirmation that locked cells are still protected.⁹

Who Owns What

Spreadsheet control often breaks down at the handoffs between laboratory, quality, and IT. The laboratory owns each template’s content and its correctness against the method. The quality unit owns the procedure, approves classifications and releases, and runs periodic review. IT owns the storage location, permissions, and the cloud library settings, and must tell the laboratory before changing them. Put named roles in the procedure, not department names, because a department cannot sign a release.

When the Right Answer Is to Stop Using a Spreadsheet

A risk-based approach also tells you when spreadsheet validation is the wrong tool. If a file is the only record of GxP data, if it needs attributable entries and a real audit trail, or if a system you already own can do the same calculation under its own controls, validation effort on the spreadsheet achieves less than moving the work. The validation process is useful here as a diagnostic: when the requirements for a template cannot be met by any combination of protection, location, and review, the procedure should route the file to replacement rather than to a longer validation package. The migration decision itself, and how to make it in stages, is covered in our earlier article on replacing QC spreadsheets.

Conclusion

The regulatory expectation for spreadsheets has been stable for a long time: check the output, scale the effort to complexity and reliability, keep the calculation, and control who can change it. What 2026 adds is a current FDA document, the February 3 edition of the Computer Software Assurance guidance, that uses a spreadsheet to show how assurance effort should follow intended use and risk, along with a practical change most procedures have not caught up with: the application under a validated template now updates every month. A defensible approach to spreadsheet validation GxP inspectors will accept starts from what a file does to a GxP record, classifies it by what a wrong answer would do and whether anyone would catch it, validates templates once and protects them, verifies one-off calculations every time, and treats protection and cloud version history as the limited controls they are. None of this requires validating every file, and none of it allows ignoring the ones that decide a release.

Sakara Digital works with pharma and biotech quality and IT leaders on computerized system validation, data integrity, and the practical controls that make them hold up in inspections. If you are revisiting your spreadsheet procedure against the 2026 CSA guidance and want an independent view of where to focus first, we are happy to have that conversation.

For Further Reading