Understanding Computer

Software Assurance (CSA)

eBook
Table of Contents
Executive Summary 01

Why Does the FDA Recommend CSA? 03

What is CSA?  04
CSA’s Regulatory Impact  04
Determining Intended Use  05
Determining Risk  06
Feature Risk  07
Testing Approaches & Test Evidence  07
Appropriate Assurance Activities  08

Critical Thinking: The Difference Between

CSV and CSA 10
Traditional Validation Approach  10
New Risk-based Approach & Framework  11
Risk-based Validation  12

Why is CSA Beneficial? 13

What Are the Benefits of Digital Validation for CSA? 15

Considerations When Selecting a Digital Validation System For CSA  18
Using Kneat to Enable CSV at Scale  18
Conclusion  19

About the Author 20

Additional Resources 21
eBook
1
Understanding Computer Software Assurance (CSA)

Executive Summary
Life sciences organizations rely on computer systems to ensure the safety and quality
of therapies, medical devices, and other products throughout their development, trial,
production, and distribution.

Computer System Validation (CSV) is the process of ensuring that a computer system is fit
for its intended use by testing and documenting that the system’s features and functions
operate accurately, reliably, consistently, and to relevant regulatory requirements.

Following feedback gathered in its 2011 initiative, ‘The Case for Quality’, the FDA
determined that existing CSV guidance lacked clarity and deterred industry from
adopting new technologies. In September 2022, the FDA released Computer Software
Assurance for Production and Quality System Software1 a draft guidance providing new
recommendations for a more efficient risk-based approach to computer system validation.

To achieve this efficiency, the guidance places responsibility on the software vendor,
instead of the customer/manufacturer, to:

• determine the risk level associated with each feature, function, or operation of the
system (for example: low, medium, high)

• determine the appropriate corresponding assurance activity to be performed by the

customer/manufacturer

As a result of this change, validation activities performed by the customer/manufacturer

provide ‘assurance’ of the validated state of a computer system that is already tested and
documented by a software vendor, resulting in:

 reduced risk of a customer/manufacturer inaccurately determining risk of increasingly

complex and specialized computer systems

 customers/manufacturers only being required to test features and functions

whose intended use is directly involved in production or quality by the customer/
manufacturer, when deemed appropriate by the customer/manufacturer

 customers/manufacturers only being required to perform testing and documentation

proportionate to the risk determined by the customers/manufacturer

1. U.S. Food and Drug Administration. (2022, Sept 13). Computer Software Assurance for Production and Quality System Software.
Retrieved from https://www.fda.gov/media/161521/download
 eBook
2
Understanding Computer Software Assurance (CSA)

In this guide you will learn:

 Why the FDA recommends CSA

 What is CSA

 The difference between CSA and CSV

 Why CSA is beneficial; and

 The benefits of digital validation for CSA

Each section contains analysis and a description of the implications of the guidance for
industry.
eBook
3
Understanding Computer Software Assurance (CSA)

Why Does the FDA Recommend CSA?

Computer Software Assurance for Production and Quality System Software draft guidance2
comes from a multi-year collaboration between the FDA and industry.

Following the launch of their ‘Case for Quality’ initiative3 in 2011, the FDA was uncertain
why so few companies were investing in automated solutions and why so many continued
to run long-outdated versions of software.

The initiative, which set out to study quality best practice in medical device manufacturing,
found that a combination of the perceived regulatory burden of Computer System
Validation (CSV), a lack of clarity, and outdated compliance approaches deterred
investment in new technologies and the implementation of automated systems and as a
result, inhibited quality best-practice.

On learning that the burden of CSV was holding companies back from realizing their
investment in technology, the FDA decided to partner with industry to strike a balance
between promoting automation and value-add CSV activities.

The FDA’s CSA guidance is meant to encourage companies to make necessary technology
investments by decreasing burdensome, low-value validation efforts without compromising
quality or accountability. To accomplish this, the guidance offers validation professionals
three key strategies:

1. Relying on and leveraging vendor testing and documentation

2. Prioritizing testing efforts based on risk

3. Implementing less detailed unscripted testing for not high-risk functions and systems

The guidance document from the U.S. Food and Drug Administration (FDA) was released
for Computer Software Assurance (CSA) on September 13, 2022.4 It is supported by the
FDA5 and the International Society for Pharmaceutical Engineering (ISPE®).6

2 U.S. Federal Drug Administration. (2022, September 13). Computer Software Assurance for Production and Quality System Software.
Retrieved from https://www.fda.gov/media/161521/download
3 U.S. Federal Drug Administration. Retrieved from https://www.fda.gov/medical-devices/quality-and-compliance-medical-devices/case-quality
4 U.S. Federal Drug Administration. (2022, September 13). Computer Software Assurance for Production and Quality System Software.
Retrieved from https://www.fda.gov/media/161521/download
5 https://www.fda.gov/
6 https://ispe.org/
 eBook
4
Understanding Computer Software Assurance (CSA)

What Is CSA?
Computer Software Assurance (CSA) is the term established by the FDA to communicate a best-
practice process for computer system validation as part of the Computer Software Assurance for
Production and Quality System Software draft guidance.

The guidance provides recommendations for a more efficient risk-based approach to computer
system validation aimed at reducing the burden of validating complex new technologies to foster
increased technological adoption.

To achieve this efficiency, the guidance places responsibility on the software vendor, instead of
the customer/manufacturer, to:

• determine the risk level associated with each feature, function, or operation of the system
(for example: low, medium, high)

• determine the appropriate corresponding assurance activity to be performed by the

software vendor

As a result of this change, validation activities performed by the customer/manufacturer provide

‘assurance’ of the validated state of a computer system that is already tested and documented by
a software vendor, resulting in:

 reduced risk of a customer/ manufacturer inaccurately determining risk of increasingly

complex and specialized computer systems

 customer/ manufacturer only being required to test features and functions whose intended
use is directly involved in production or quality by the customer/manufacturer, when
deemed appropriate by the customer/ manufacturer

 customer/ manufacturer only being required to perform testing and documentation

proportionate to the risk determined by the customers/ manufacturer

What is CSA’s Regulatory Impact?

As a draft guidance, Computer Software Assurance for Production and Quality System Software is
not new a regulatory requirement. A draft guidance sets out an approach to “describe various
methods and testing activities that may be applied to establish computer software assurance
and provide objective evidence to fulfill regulatory requirements, such as computer software
validation requirements in 21 CFR part 820 (Part 820).”
eBook
5
Understanding Computer Software Assurance (CSA)

Like all guidance, Computer Software Assurance for Production and Quality System Software
undertook a consultation period, which concluded in November 2022, where comments and
feedback were received from organizations testing the guidelines proposed. This feedback will
be assessed and, in some cases, incorporated by the FDA into potential future regulation.

According to its Introduction,7 the draft guidance is intended to “describe ‘computer software
assurance’ as a risk-based approach to establish confidence in the automation used for
production or quality systems, and identify where additional rigor may be appropriate” and,
“describe various methods and testing activities that may be applied to establish computer
software assurance and provide objective evidence to fulfill regulatory requirements, such as
computer software validation requirements in 21 CFR part 820 (Part 820).”

The guidance is not a replacement for computer system validation; it is simply a framework
designed to help software vendors provide validated software and streamline customer’s/
manufacturers implementation of new technologies.8 CSA will however supersede Section 6
(“Validation of Automated Process Equipment and Quality System Software”) of the Software
Validation guidance.9

The guidance initially cites Medical Device Software manufacturers as being subject to CSA
and does not explicitly state its contents apply to other life sciences organizations; however,
it is important to note that CSA is expected to become the new de facto standard in computer
system validation across life sciences.

Determining Intended Use

To identify the intended use of the computerized system—i.e., to determine whether the
systems is intended as part of production or a Quality System (QS)—customers/manufacturers
should ask themselves the following questions:

• Is it a direct part of the production or QS?

• Is it an indirect, supporting element of production/QS?

• Is it not used as part of production/QS?

• Are there multiple uses arising from multiple features, functions or operations?

7 U.S. Federal Drug Administration. (2022, September 13). Computer Software Assurance for Production and Quality System Software, p.4.
Retrieved from https://www.fda.gov/media/161521/download
8 https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation
9 https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-software-validation
10 https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
 eBook
6
Understanding Computer Software Assurance (CSA)

The FDA’s Quality System regulation 21 CFR 820.70(i)10 applies:

• Software intended to be used directly as part of production or QS

 Production processes, inspection, testing, or collection and processing of production data

 Quality system processes, collecting or processing quality system data, or maintaining a

quality record established under the Quality System regulation

• Software intended to be used to support production or QS

 Development tools that test or monitor software systems, or automate testing activities

 General record keeping that is not part of the quality record

Determining Risk
In releasing the draft CSA guidance, the FDA aims to improve quality, remove non-value add
activities, and focus testing on high-risk areas—therefore reducing validation cost and time by
focusing on the software’s impact to patient safety, impact to product quality, and impact to
quality system integrity for both direct and indirect systems:

Direct system software (e.g., inspects or dispositions product, labeling systems)—will require
testing based on risk. Expected deliverables are similar to current expectations, i.e., the riskier
the application, the more testing and documentation is required.

Indirect system software (e.g., Document Control, Complaint Management, Lifecycle

Management tools) — is software that does not directly impact the product or patient safety
but does impact the quality system. The same rigor is not needed for the assurance of these
types of systems, and they require less documentation.

Taking the traditional CSV approach, each test script was written in great detail, regardless of
whether the system or feature was a Direct or Indirect system or feature. So, the same level
of effort was being put into creating test documentation for not high-risk system software.
The FDA acknowledges that the risk associated with software used as apart for production or
the quality system are on a spectrum ranging from High to Low Risk. Manufacturers should
determine the risk of each software feature, function or operation as the risk falls on that
spectrum, depending on the intended use of the software, and assurance activities should be
conducted for software that is commensurate with the risk.
eBook
7
Understanding Computer Software Assurance (CSA)

Feature Risk

The FDA’s guidance on “Determining the Appropriate Assurance Activities” introduces the terms
“Scripted”, “Unscripted”, and “Ad-hoc” testing.

Testing Aproaches & Test Evidence

The FDA acknowledges that the risk associated with software used as a part for production or
the quality system are on a spectrum ranging from High to Low Risk. Software vendors should
determine the risk of each software feature, function or operation as the risk falls on that
spectrum, depending on the intended use of the software.

According to the FDA’s guidance: “A manufacturer may still determine that a process risk is,
for example, “moderate,” “intermediate,” or even “low” for purposes of determining assurance
activities; in such a case, the portions of this guidance concerning “not high process risk”
would apply. As discussed in Section V.C. below, assurance activities should be conducted for
software that is “high process risk” and “not high process risk” commensurate with the risk.”11
 eBook
8
Understanding Computer Software Assurance (CSA)

Appropriate Assurance Activities

Scripted Testing

With scripted testing, actual results are recorded, along with detailed test steps, and
screenshots may not be required (see figure 1).

Figure 1: Example of Scripted Testing in Kneat

Unscripted Testing

With unscripted testing, high-level test plan objectives should be established–no step-by-step
test script procedure is required. Each test has a “pass” and “fail”, and the name and date of the
tester is captured (see figure 2).

11. U.S. Federal Drug Administration. (2022, September 13). Computer Software Assurance for Production and Quality System Software.
Retrieved from https://www.fda.gov/media/161521/download
eBook
9
Understanding Computer Software Assurance (CSA)

Figure 2: Example of Unscripted Testing in Kneat

Ad-hoc Testing

With ad-hoc testing techniques, there are no pre-approved test scripts. Each test has a Pass
and Fail. You should just describe what was tested to verify that the feature worked correctly
and include the name of the tester and date of test execution (see figure 3).

Figure 3: Example of Ad-hoc Testing in Kneat

It is important to note that ad-hoc testing does not equal no documentation; ad-hoc does not
mean that you don’t have any objective evidence that the test has been completed.
 eBook
10
Understanding Computer Software Assurance (CSA)

Critical Thinking: The Difference Between CSV and CSA

CSA represents a step-change in computer system validation, placing critical thinking at the
center of the CSV process, as opposed to a traditional almost one size fits all approach, that
has morphed into an activity that is being done primarily to secure evidence for auditors,
rather than to assure the quality of systems being validated.

Computer System Validation Computer Software Assurance

A focus on creating documentary records for A focus on testing for higher confidence in
compliance system performance

Risk-based “Assurance”, applying the right level

“Validate” everything (and miss higher risk
of rigor for a given level of risk to patient safety
areas)
and/or product quality

Ignoring previous assurance activity or related “Take credit” for prior assurance activity and
risk controls upstream/downstream risk controls.

Focus on testing, not scripting. Use unscripted

testing for not high-risk components.

Traditional Validation Approach

Traditionally, software validation has often been accomplished via software testing and other
verification activities conducted at each stage of the software development lifecycle.12

The traditional computer system validation approach, for organizations that wanted to
implement a software system to drive efficiency and quality improvements, was arduous
and time-consuming. Critical thinking was not applied, every feature or system, regardless of
whether it impacted patient safety or product quality or not, was tested in the same way, and a
burdensome documentation approach was applied.

The current CSV methodology sees software vendors or manufacturers spending

approximately 80% of their time documenting and only 20% of their time testing. This
generated a significant amount of documentation and was time-intensive and was arguably not
a good use of the time and the resources available to both the organization and the auditor.

12. U.S. Federal Drug Administration. (2022, September 13). Computer Software Assurance for Production and Quality System Software, p.6.
Retrieved from https://www.fda.gov/media/161521/download
eBook
11
Understanding Computer Software Assurance (CSA)

Traditional Validation of a New Software System

New Risk-based Approach and Framework

The CSA approach completely inverts the triangle. The FDA wants to flip the traditional
approach so that 80% of a software vendors or manufacturers time is spent on testing based
on the appropriate risk level as a result of applying critical thinking, while only 20% of their time
is spent on documentation.
 eBook
12
Understanding Computer Software Assurance (CSA)

The FDA's CSA draft guidance sets out a broad step-by-step framework that an organization
should follow to assure the quality and safety of its computerized tools. Based on the intended
use of the computerized system, risk should dictate the process of determining the system
validation approach and this risk determination should establish a commensurate level of
validation effort.

Risk-based Validation

Most of the time will now be spent on critical thinking by subject-matter experts—assessing
each particular feature, function or system on a particular piece of equipment and determining
the appropriate level of testing document based on its impact on the patient, impact on
product quality, and impact on system integrity. Then the assurance needs are determined—
leveraging vendor audits—and the appropriate testing activities are undertaken, together with
the necessary documentation.
eBook
13
Understanding Computer Software Assurance (CSA)

Why Is CSA Beneficial?

Too often, testers spend time ensuring their protocol is error free, as opposed to spending
time on automated solutions that verify the software meets it’s intended use. The CSA guidance
document focuses on clarifying risk-based methodologies to justify the amount and types of
testing required and encourages leveraging previous testing activities. It promotes a “Case for
Quality” approach, which allows life sciences companies to focus on improving product quality
and patient safety, rather than on documentation, for documentation’s sake.

The logic of CSA is clear. Faster, easier, computerized system onboarding, higher adoption, and
a more digitized life sciences world with modern tools and techniques. There are many benefits
to CSA for organizations, such as improved quality and efficiency and validation effort reduced
by up to 30%, with more time spent challenging the system.

The Benefits of Computer Software Assurance (CSA) Guidance

 eBook
14
Understanding Computer Software Assurance (CSA)

Other benefits include:

 A reduction in cycle times (test creation, review, and approval)

 A system can be broken into features, and only the high-risk features will require
scripted testing
 Reduced test script execution time
 60% faster protocol generation / execution
 Lower number of detected defects, for example script errors and configuration
 A reduction in the number of generated documents, for example the use of the
combining deliverables and test scripts)
 Testing focused on ensuring software quality
 Better use of Supplier Qualification
 Maximized use of CSV and project resources expertise (e.g., SMEs)
eBook
15
Understanding Computer Software Assurance (CSA)

What Are the Benefits of Digital Validation for CSA?

CSA can alleviate the challenges associated with the traditional CSV approach by calling for
the least burdensome documentation approach. It can result in fewer issues encountered in
production—reducing project costs and accelerating speed to market. However, any potential
efficiency gains from CSA will not be realized if you are using paper-based validation processes.

Whether you decide to use the traditional CSV methodology or a streamlined CSA approach,
shifting to a digital, automated, validation lifecycle management system like Kneat can lessen
your validation burden and save you time, money, and effort.

The benefit of digital validation for CSA is manifold. It is the best way to streamline validation
activity while also ensuring compliance through evidence and sound rationale. Scripted,
unscripted, and ad-hoc testing can be executed or managed digitally—and vendor testing/
evidence can be easily stored for quicker reference.

A robust paperless validation system should automate the validation lifecycle processes and
should lead to:

 Elimination of inefficiencies

 Ensuring consistency and compliance with SOPs and appropriate regulations

 Cycle time reductions in review and executions

 Data integration and safe and secure storage of generated data

 Electronic Traceability Matrix

 Integration of the Validation and the Change Management Process

 Cost reductions for printing and storage of generated paper records

 Increased quality

 Scalability of the system in order to add new software systems/sites etc.

 Instant access to the validation artifacts in the event of an audit

 eBook
16
Understanding Computer Software Assurance (CSA)

Elimination of Inefficiencies

Inefficiencies exist in all paper-based systems: Keeping track of the paper documents can be a
constant headache. For example, if more than one person is offsite then getting their signature
may require multiple emails, attaching PDFs of the signature, ensuring GDP compliance on the
scanned pages etc.

Enforced Consistency and Compliance

Digitizing computer system validation activities in one 21 CFR Part 11 compliant end-to-end
validation lifecycle management platform like Kneat ensures that all software validations follow
the same approach, use the same version of the approved templates, ensures signatures have
been obtained prior to execution for example, and ensures that all design/test documentation
should be approved prior to execution of related test documentation. An electronic system
should enforce GDP compliance for signatures by implementing electronic signatures etc.

Cycle-Time Reductions

Allowing online reviews will see a reduction in review and approval times. The ability to see
other reviewers' comments for example will aid in reduction of the cycle times.

Data Integration and Security

In a true paperless system any attachment, screenshot etc., should be integrated into the
records stored in that system. Therefore, all the data related to the validation will be stored in a
single secure location.

Electronic Traceability Matrix (RTM)

Time taken to manually create the RTM can be onerous, sometimes weeks in the case of a large
Site/Company based system.

“One of the winning pieces of functionality for Kneat was the

reporting, especially the automated-requirements-traceability-
matrix...that would have been one of the clinching features we
wanted that Kneat provided. That was the sort of functionality
that was very inefficient in some of the competitors’ products.”
- Global Commissioning and Qualification Lead for EU, A Risk Focused Global Biotech.
eBook
17
Understanding Computer Software Assurance (CSA)

Integrated Validation and Change Management Process

Integration of both processes into a single software application can ensure compliance with
company SOPs and associated regulations.

Cost Reductions

The cost of paper and the storage of paper records is eliminated. As are security costs,
transport costs, and costs associated with retrieving paper records in the event of an audit.

Increased Quality

There is less chance of ad hoc additions to an electronic based system. For example, we
have all seen “Notes to File” to a document to explain an issue found during the validation
for a computer system. Utilizing an electronic system results in less deviation from a GDP
perspective.

Scalability

Addition of new system/site or validation discipline should be possible with an electronic

system.

Instant Access for Audits

An electronic-based system should allow for instant retrieval for validation records in the event
of an audit. With Kneat, users get instant access to validation records/evidence and audit trails
for each artefact stored in the electronic system, saving time and resources.

Kneat gives users an unprecedented capability to create, manage, access, and mine validation
data. Kneat enables testers to quickly and easily enter recorded results, create and process
exceptions, upload evidence, apply electronic signatures, and generate summary reports. You
can capture any changes, complete with e-signature, time stamp, and reason for change; all
while automatically generating a full independent audit trail.
 eBook
18
Understanding Computer Software Assurance (CSA)

Considerations When Selecting a Digital Validation System

For CSA
Select an enterprise data management system that is purpose-built for life sciences that is:

 Process centric, not tool centric—company procedures should drive the process, not
the e-Validation tool.
 21 CFR Part 11 compliant—the system should have password-protected e-signatures
and time stamped audit trail.
 Functional and user friendly—that fits company culture and that supports the full
process including central management, retrieval, and viewing of records.
 Adaptable to future business process needs—with flexible configurability.
 Document centric—the system should still be document centric and have a traditional
look and feel, but with strong data management capabilities. A paperless validation
system should also be able to include other processes, for example Equipment and
Cleaning validation.
 Mobile—it can be used on both laptops and tablets and a user can login from multiple
sites, from anywhere in the world.
 Secure—ensure that the vendor is compliant with ISO 27001. You need to be assured
that the data you create using a paperless system is secure. Use a vendor you have
audited and have trust in.

Using Kneat to Enable CSV at Scale

In-vitro diagnostics industry leader Fujirebio Diagnostics,
Inc. (FDI), selected Kneat to digitize its global CSV process
with the aim of enabling its limited IT Compliance Team
to deliver a large volume of complex computer-system
projects, including the implementation and re-validation
of systems at multiple manufacturing sites across five
divisions.

As a result of this digital validation initiative, FDI achieved

a 53% reduction in time for quality management (CAPA)
system change control projects, reduced the number hours for script execution by 40%, and
eliminated reliance on a time-consuming ‘hybrid’ validation system, conducting 100% of its CSV
activities remotely, driving efficiency for the validation team.

Read more about FDI’s story and why they chose Kneat here.
eBook
19
Understanding Computer Software Assurance (CSA)

Conclusion
Using a risk-based approach is nothing new, and regulatory agencies such as the International
Society for Pharmaceutical Engineering (ISPE®) who author Good Automated Manufacturing
Practice (GAMP®) have been advocating this for two decades.

The ISPE published its second edition of GAMP®5 in July 2022, in advance of the FDA’s CSA
guidance that was released in September 2022 and has dedicated an entire chapter to critical
thinking.

Extracts from the ISPE GAMP® 5: A Risk-Based Approach to Compliant GxP

Computerized Systems (Second Edition)

 “Critical thinking promotes informed decision-making and good judgement on where

and how to apply and scale quality and compliance activities for computerized systems.”

 “Critical thinking should be applied to understand the implementation risks as well as

functional risks to patient safety, product quality, and data integrity.”

 “Regulators look for scaled paperwork with well-organized information and records
that have an appropriate level of detail, supported by clear and unambiguous rationales
explaining critical thinking applied.”14

CSA provides clarity on the stance and methodology used to determine what is high risk and
what is not, therefore minimizing misinterpretation by software vendors or manufacturers. The
clarification in the CSA approach flips the paradigm to focus on critical thinking (risk-based),
assurance needs, testing activities, and documentation, in that order.

The release of the CSA guidelines will support companies who have taken the path to
automation. Today, thousands of validation, compliance, and quality professionals within highly
regulated businesses—including eight of the world’s top ten pharmaceutical companies—use
Kneat to manage, execute, and archive their validation documentation, securely, rapidly, and
cost-effectively in the cloud.

13 International Society of Pharmaceutical Engineers. (n.d.). GAMP 5 Guide 2nd Edition.

Retrieved from https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition
14 International Society of Pharmaceutical Engineers. (n.d.). GAMP 5 Guide 2nd Edition, Appendix M12 Critical Thinking.
Retrieved from https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition
 eBook
20
Understanding Computer Software Assurance (CSA)

About the Author

Darren Geaney, BEng, Kneat

Darren Geaney is a Process Engineer and Subject-Matter-Expert on

Computer System Validation at Kneat.

Darren has over 23 years’ experience in software validation,

providing right-sized computer system validation solutions to
medical device companies. Knowledgeable in regulations FDA 21 CFR
Part 820, 21 CFR Part 11, ISO 62304 and ISO 14971, Darren is ‘Lead
Auditor’ accredited and experienced in supporting both internal and
external audits (including FDA, IMB, TUV, and BSI).
eBook
21
Understanding Computer Software Assurance (CSA)

Additional Resources
 On-demand Webinar with CSV Specialist Darren Geaney: Achieving Computer Software
Assurance (CSA) with Digital Validation

 Blog: Achieving Computer Software Assurance with Digital Validation: Webinar FAQ

 Blog: What Is Computer Software Assurance (CSA) and Why Are the FDA Transitioning
from Traditional

 Case Study: Fujirebio Diagnostics, Inc. Uses Kneat to Provide CSV at Scale

 Case Study: HCL Technologies: Reducing Global Deployment Validation Cost by 35%

 Case Study: Transforming Traceability: From Prohibitive to Productive Risk Mitigation