Cloud Vendor Audits for GxP SaaS: Using SOC 2 Reports Without Overrelying on Them

Why SOC 2 Became the Default Evidence for SaaS Vendors

Ten years ago, a regulated company that bought a laboratory system or a document management system usually installed it on its own servers. The supplier audit focused on how the vendor built and tested the software. The regulated company ran the infrastructure, controlled the upgrade schedule, and owned the backups. Supplier qualification was one part of a validation effort that the company controlled end to end.

Software as a service changed who does what. In a SaaS model, the vendor runs the application, the database, the infrastructure (often on a public cloud provider), the release schedule, the backups, and the security operations. The regulated company configures the system, trains its users, and owns its data and its GxP processes. Much of what used to be the customer’s own controlled environment is now the vendor’s operation. That makes supplier qualification far more important, because the evidence for many of the controls a validated system depends on now lives at the vendor.

At the same time, SaaS vendors sell to every industry. A vendor with a few dozen life sciences customers may have thousands of customers in finance, retail, and technology. The assurance those other customers ask for is almost always a SOC 2 report, sometimes alongside ISO/IEC 27001 certification. So when a pharma quality team sends a supplier questionnaire, the vendor’s first response is predictable: here is our SOC 2 Type 2 report, here is our ISO certificate, and please sign our nondisclosure agreement.

There Is No GxP Certificate to Ask For

Part of the reason SOC 2 fills the space is that nothing else does. Microsoft states it directly on its GxP compliance page: “There’s no GxP certification for cloud service providers.”¹ The same page explains that Microsoft relies on independent audits such as ISO 9001 and ISO/IEC 27001, commissioned a GxP qualification review from an outside firm, and tells customers that they should determine the GxP requirements for their own systems based on intended use and then follow their own qualification and validation processes.¹

That last point is the one to hold on to. Even a hyperscale provider that has invested heavily in GxP material puts the responsibility for qualification and validation back on the customer. A mid-sized SaaS vendor with a SOC 2 report and nothing GxP-specific is not going to take on more.

The Risk Is Not Using SOC 2. It Is Stopping There.

None of this means SOC 2 reports are weak evidence. A Type 2 report is prepared by an independent CPA firm, follows AICPA attestation standards, and tests controls over a period of time rather than looking at a single day. For access control, security monitoring, incident response, and infrastructure operations, it is often better evidence than a regulated company could collect in a two-day audit.

The problem comes when a quality team files the SOC 2 report as the whole supplier assessment. The report answers questions the auditor was asked to answer. Most of the questions a GxP reviewer needs answered were never asked. Treating the report as a complete supplier qualification leaves gaps that show up later: an unannounced release that changes validated functionality, a restore that brings back data without its audit trail, or a subcontracted hosting provider nobody assessed.

What a SOC 2 Report Covers and How It Is Built

Before mapping gaps, it helps to be precise about what a SOC 2 report is. Quality professionals who have not worked with attestation reports often read them the way they would read a GxP audit report, and the two are built very differently.

The Trust Services Criteria

A SOC 2 examination reports on a service organization’s controls against the AICPA’s 2017 Trust Services Criteria, which the AICPA reissued with revised points of focus in 2022. The criteria were set by the AICPA’s Assurance Services Executive Committee to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy of information and systems.⁴ Those five areas are the Trust Services categories.

Security, also called the common criteria, is the only category required in every SOC 2 examination. The other four can be added at management’s discretion or when they are key to the services provided.² The common criteria include areas that matter to GxP reviewers, including change management (how an entity recognizes the need for changes, runs them through a controlled process, and prevents unauthorized changes) and risk mitigation, which includes monitoring the use of business partners and vendors.²

Processing integrity is the category closest to GxP data concerns. It addresses whether system processing is “complete, valid, accurate, timely, and authorized to meet the entity’s objectives.”⁵ But because it is optional, many SaaS reports do not include it. Look at what large providers choose to cover. The AWS SOC 2 report addresses security, availability, confidentiality, and privacy.³ Processing integrity is not on that list. That is a reasonable choice for an infrastructure provider, and it shows why a GxP reviewer should never assume which categories a report covers.

Type 1 Versus Type 2

A Type 1 report describes the vendor’s system and gives the auditor’s opinion on whether controls were suitably designed as of a single date. A Type 2 report adds testing of whether those controls operated effectively over a period of months. Each AWS SOC 2 report, for example, covers twelve months.³ The AICPA describes a Type 2 report as including management’s assertion, the description of the system, the service auditor’s report, and the tests of controls and their results.⁶

For supplier qualification, a Type 2 report is the one to ask for. A Type 1 report tells you the vendor wrote sensible controls down. It says nothing about whether anyone followed them.

The Parts of the Report That Matter Most

A SOC 2 Type 2 report typically has four main parts, and a reviewer should treat each one differently:

• The service auditor’s opinion. This states whether the description is fairly presented and whether controls were suitably designed and operated effectively. An unqualified opinion is the clean result. A qualified opinion means the auditor found a problem serious enough to call out in the opinion itself.
• Management’s assertion. The vendor’s own statement about its system and controls.
• The system description. This defines the boundaries of what was examined: which services, which infrastructure, which locations, which subservice organizations, and which controls the vendor expects its customers to operate. The AICPA’s description criteria (DC 200) govern what this section must disclose, although they do not set a fixed format.⁶
• Tests of controls and results. The auditor’s test procedures for each control and whether any exceptions were found. This is where the detail is, and it is the section most often skipped.

The AICPA’s SOC 2 guide was updated as of October 15, 2022, to reflect SSAE No. 20 and SSAE No. 21 and the 2022 revised points of focus.⁷

Complementary User Entity Controls and Subservice Organizations

Two features of SOC 2 reports matter a great deal in GxP work, and both describe controls the auditor did not test at the vendor.

Complementary user entity controls (CUECs) are controls the vendor’s management assumed its customers would put in place, and that are needed, together with the vendor’s own controls, for the vendor to meet its service commitments.⁸ Typical examples include customers managing their own user provisioning, reviewing their own user access, and protecting their own credentials. If your organization does not operate the CUECs, the controls described in the report may not achieve their objectives for you.

Complementary subservice organization controls (CSOCs) are controls the vendor assumed its own suppliers would operate, such as the public cloud provider underneath a SaaS application.⁸ When a report uses the carve-out method, the subservice organization’s controls are excluded from the examination. The report tells you the dependency exists but does not test it. You need separate evidence for that layer, usually the cloud provider’s own SOC report.

Bridge Letters and the Gap Period

A Type 2 report covers a fixed period that has already ended. Reports are usually issued some weeks after the period closes. AWS, for example, notes that new reports are generally released about nine to ten weeks after the period end date.³ Between the end of the tested period and today, there is a gap with no independent testing.

Vendors address this with a bridge letter, sometimes called a gap letter or continued operations letter. AWS publishes its SOC Continued Operations Letter monthly.³ A bridge letter is a statement by the vendor’s management, not by the auditor. It is worth having, and it is worth reading as what it is: the vendor telling you nothing material has changed.

What SOC 2 Does Not Cover: The GxP Gaps

With the structure clear, the gaps become easier to see. A SOC 2 examination tests controls against the vendor’s own service commitments and system requirements, using criteria written for any service organization in any industry. A GxP supplier assessment tests whether the vendor can support a regulated user in keeping a computerized system in a validated state and its records trustworthy for their full retention period. Those overlap, but they are not the same question.

The table below maps the GxP expectations that come up most often in SaaS supplier assessments against what a typical SOC 2 Type 2 report provides. “Typical” matters here. Some reports go further than others, and the only way to know is to read the report.

Gap One: Change Control Written for Security, Not Validated State

SOC 2 change management criteria focus on how the vendor recognizes the need for changes, runs them through a controlled process, and prevents unauthorized changes.² That is a good control, and a clean result is reassuring. But the criteria are written from the vendor’s point of view. They ask whether the vendor controls its own changes. They do not ask whether the vendor tells its customers what changed in time for those customers to assess the impact on their validated configuration.

For a GxP SaaS system, that second question is the one that matters. A vendor can have excellent internal change control and still release a new version every two weeks with a short notice and generic release notes. The SOC 2 auditor would have no finding. The regulated customer would have a system whose validated state it cannot confirm.

The draft revision of EU GMP Annex 11, released for public consultation in July 2025 and not yet final, makes this expectation explicit. It says the contract with a service provider should agree on the process for releasing new system versions and on whether the regulated user can test them before release.⁹ Even though the draft is not in force, it shows where inspectors’ thinking is heading, and it gives quality teams a clear line item for the supplier assessment.

Gap Two: Validation Support Is Outside the Criteria

Nothing in the Trust Services Criteria asks whether a vendor supports its customers’ validation. That includes whether the vendor tests its standard functions against documented requirements, whether that test evidence is available to customers, whether the vendor will explain its development practices to an inspector, and whether it provides a requirements specification the customer can review.

The draft Annex 11 addresses this point for SaaS directly. It notes that when a system is bought or consists of software as a service, the vendor may provide the requirements specification, but the regulated user should carefully review and approve it and decide whether the system meets GMP requirements and company processes as is or needs configuration.⁹ A SOC 2 report gives you no information about whether such a specification exists.

Gap Three: Data Integrity at the Application Layer

SOC 2 security controls protect the environment: who can log in, how privileged access is managed, how security events are logged and monitored. Those controls support data integrity, and a reviewer should credit them. But GxP data integrity is mostly about the application and its records: whether the audit trail captures who, what, when, and why for GxP-relevant changes; whether it can be turned off or edited; whether electronic signatures are bound to their records; and whether records remain complete and readable through upgrades, migrations, and restores.

A SOC 2 auditor examining logging controls is usually testing security event logging, not the application audit trail your users depend on. The two can overlap, but they are different records with different purposes. Do not accept “logging and monitoring” in a SOC 2 report as evidence that the application audit trail meets GxP expectations.

Gap Four: Backup Is Not the Same as a Tested GxP Restore

If the availability category is in scope, the SOC 2 report will usually describe backup processes and some form of recovery testing. That is useful evidence. The GxP question is narrower and stricter: can the vendor restore your data and metadata, including audit trails, to a usable state, and has that been tested and documented?

The draft Annex 11 states that restore from backup should be tested and documented based on risk during system validation and after changes to the backup or restore processes and tools, and that restore tests should include verifying that data is accessible on the system.⁹ The current Annex 11, in force since 2011, already expects regular backups, with the integrity and accuracy of backup data and the ability to restore it checked during validation and monitored periodically.¹⁰ The MHRA’s data integrity guidance adds that there must be arrangements to restore the software or system to its original validated state, including validation and change control information to permit this.¹¹ A SOC 2 statement that “backups are performed daily and recovery is tested annually” does not tell you whether any of that is true for your tenant and your records.

How Regulators Frame Reliance on Suppliers

Regulators do not mention SOC 2 by name, and they do not need to. The texts on supplier management and outsourced activities are consistent on three points: the regulated company stays responsible, the depth of supplier assessment should follow risk, and certifications alone are not enough for critical systems.

EU GMP Annex 11 (2011, Current)

The current Annex 11 requires formal agreements with third parties that provide, install, configure, integrate, validate, maintain, modify, or retain a computerized system or related service, with clear statements of the third party’s responsibilities. It says the competence and reliability of a supplier are key factors when selecting a product or service provider, and “The need for an audit should be based on a risk assessment.”¹⁰ It also expects that “Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request.”¹⁰

That last clause matters for how you document a SOC 2 review. If your supplier file consists of a vendor’s SOC 2 report held under a nondisclosure agreement that prevents you from showing it to an inspector, you have a documentation problem. Your own written assessment of the report, which you can show, becomes the key record.

EU GMP Annex 11 (Draft Revision, 2025)

The draft revision has a full section on supplier and service management. It states that relying on a vendor’s qualification, a service provider, or an internal IT department does not change the requirements of the annex, and that “The regulated user remains fully responsible for these activities based on the risk they constitute on product quality, patient safety and data integrity.”⁹ It then expects the regulated user, according to risk and system criticality, to conduct an audit or a thorough assessment of the vendor’s or service provider’s procedures and documentation, and to decide whether that work can be relied on rather than repeated.⁹

The draft also lists what a contract with a service provider should cover, including the activities and documentation to be provided, reporting and oversight including service level agreements and key performance indicators, conditions for supplier audits, support during regulatory inspections, communication of quality and security issues, an exit strategy that lets the regulated user retain control of system data, and the process for releasing new versions.⁹ Almost none of those items appear in a SOC 2 report, because they are commitments to a specific customer, not controls tested against general criteria.

PIC/S PI 011-3

The PIC/S guidance on computerized systems in GxP environments, dated 2007 and still published by PIC/S, addresses certification directly. It accepts that confidence in a supplier may rest partly on recognized certification of its development methods and quality system, provided the certification scope covers actual practices, controls, and records, including change management. It then says that an assessment of the supplier’s QMS and certification alone is “unlikely to be the final arbiter for critical systems,” and suggests supplier questionnaires, shared supplier audits, and contact with user groups as additional means of assessment.¹²

That guidance was written about ISO 9001 and similar certifications, but the reasoning carries over to SOC 2 without any change. An independent attestation is useful input. For critical systems, it is not the whole answer.

MHRA GXP Data Integrity Guidance

The MHRA’s 2018 data integrity guidance has a section on IT suppliers and service providers that names cloud, SaaS, PaaS, and IaaS. It says: “Where ‘cloud’ or ‘virtual’ services are used, attention should be paid to understanding the service provided, ownership, retrieval, retention and security of data.”¹¹ It asks regulated companies to consider where data is physically held and which laws apply there, to define responsibilities in a technical agreement or contract that ensures timely access to data including metadata and audit trails, to define archiving and continued readability for the retention period, and to include tested business continuity arrangements. It closes with: “The need for an audit of the service provider should be based upon risk.”¹¹

Read that list against a SOC 2 report. Security of data is covered. Ownership, retrieval, retention, data location, access to audit trails for regulators, and continued readability are mostly not.

EU GMP Chapter 7

EU GMP Chapter 7 on outsourced activities says the contract giver’s quality system should include control and review of outsourced activities, and that the contract giver is responsible for assessing the suitability and competence of the contract acceptor before outsourcing. It also says the contract acceptor should not subcontract any of the work to a third party without the contract giver’s prior evaluation and approval.¹³ For SaaS, that last point connects directly to subservice organizations. If the vendor moves from one hosting provider to another, you should know before it happens.

Chapter 7 also expects the contract giver to monitor and review the contract acceptor’s performance and to identify and put in place any needed improvements, and to review and assess the records and results related to the outsourced activities.¹³ For a SaaS system, that means supplier qualification does not end when the contract is signed.

FDA on Quality Agreements

FDA’s guidance on quality agreements for contract manufacturing is written for manufacturing and testing arrangements, not software services. Its central principle still applies to any GxP outsourcing decision: “quality agreements cannot be used to delegate statutory or regulatory responsibilities to comply with CGMP.”¹⁴ The guidance also says quality agreements should cover audits, inspections, and communication of findings, including both routine and for-cause audits.¹⁴ A SaaS vendor’s SOC 2 report does not transfer your responsibility any more than a contract manufacturer’s certificate would.

Reading a SOC 2 Report Like a Quality Reviewer

Most quality teams that receive a SOC 2 report check that it exists, that it is a Type 2, and that the opinion is unqualified. That takes five minutes and misses most of the value. A structured review takes longer, but it turns the report from a checkbox into evidence you can use and defend. The steps below are the ones we recommend for any SaaS system with GxP impact.

How to Read Exceptions Without Overreacting

Exceptions in a Type 2 report are normal. A clean opinion with a handful of exceptions is common, and the auditor will often note management’s response. The question for a GxP reviewer is not whether exceptions exist, but whether they touch controls your intended use depends on, and whether management’s response is credible.

An exception in which a small sample of terminated employees kept access for a few days beyond policy, with a documented remediation, may be low concern for a learning management system and a higher concern for a system holding batch release data. An exception in which production changes were deployed without documented approval deserves a direct question, whatever the system, because it goes to the heart of how the vendor protects your validated state.

Questions a Report Review Should Produce

A useful output of the review is a short list of vendor-specific questions. These are usually more productive than a generic 200-item questionnaire, because they show the vendor you read the report and they target real uncertainty. Examples:

• The report lists an exception in change approval during the third quarter of the period. What caused it, what did you change, and how do you confirm the fix is working?
• Processing integrity is not included. How do you verify that data imports, calculations, and exports in the product are complete and accurate after each release?
• Your hosting provider is carved out. Has the hosting provider changed in the last two years, and do you commit to notifying customers before a change?
• The availability section describes annual recovery testing at the infrastructure level. Do you test restoring an individual customer tenant, including application audit trails, and can we see the record of the last test?

Closing the Gaps: Questionnaires, Targeted Audits, and Contract Terms

Once the report review has shown what SOC 2 covers and what it leaves open, you have three tools to close the gaps. Most SaaS assessments use all three in different proportions.

Targeted Questionnaires

A GxP supplement questionnaire should cover only what the SOC 2 report does not. If you send the vendor a full security questionnaire after receiving a clean SOC 2 Type 2 report, you are asking them to repeat work an independent auditor already tested, and you will get boilerplate answers. Focus the questionnaire on the four GxP gaps and ask for evidence, not just yes or no.

For security topics that a SOC 2 report covers only in part, industry questionnaires can help. The Cloud Security Alliance’s Consensus Assessments Initiative Questionnaire (CAIQ v4), released in June 2021, is a set of yes or no questions that cloud customers and auditors may ask a provider to assess alignment with the CSA Cloud Controls Matrix.¹⁵ Many SaaS vendors have already completed it. It is a security tool, not a GxP tool, so treat it as a complement to the SOC 2 report rather than a replacement for GxP-specific questions.

Targeted Audits

For high-risk systems, a questionnaire may not be enough. An audit, remote or on site, lets you see records rather than descriptions: an actual release record with its test evidence, an actual restore test report, an actual deviation and its CAPA. The value of the SOC 2 report here is that it lets you shrink the audit. If an independent auditor has already tested logical access, physical security, and infrastructure operations over twelve months, you do not need to spend a day of your audit on them.

A focused GxP audit of a SaaS vendor that already has a clean SOC 2 Type 2 report can often concentrate on four areas: release management and customer notification, the vendor’s quality system as it applies to the product (deviations, CAPA, training, document control), validation evidence for standard functions, and backup and restore at the tenant level. That is a tighter scope than a traditional supplier audit, and it produces better evidence on the questions that matter.

Some vendors resist customer audits, especially smaller ones with many customers. The draft Annex 11 expects the contract to agree on conditions for supplier audits,⁹ and FDA’s quality agreement guidance expects agreements to allow both routine and for-cause audits.¹⁴ If a vendor will not accept any audit right for a high-risk GxP system, that is a finding in itself and should be part of the risk decision.

Contract and Quality Agreement Terms

Some gaps cannot be closed by evidence, because they are about future behavior. The vendor’s current practice on release notice may be fine, but nothing stops it from changing. These gaps are closed in the contract or quality agreement. Based on the draft Annex 11 list and the MHRA guidance,⁹¹¹ the terms that most often need to be added for GxP SaaS are:

• Minimum notice for releases, content of release notes, and customer access to a test environment before production release.
• Notice before changing a subservice organization that hosts or processes GxP data, and before moving data to a new location.
• Notice of quality and security incidents affecting customer data, with defined time frames.
• Audit rights, including for-cause audits, and support during regulatory inspections.
• Timely access to data, including metadata and audit trails, for the customer and for regulators on request.
• Backup retention periods and tenant-level restore support.
• Data return at contract end, with format, completeness (including audit trails), and time frame defined.
• Commitment to provide each new SOC 2 report and bridge letter as they are issued.

Sizing the Assessment to Risk

Every text cited above says the depth of supplier assessment should follow risk. In practice, that means deciding how much weight the SOC 2 report can carry for a given system, and how much additional work is justified. The factors that drive that decision are the GxP impact of the system, the degree to which the vendor controls the validated state, and the vendor’s track record with regulated customers.

Three Practical Tiers

The examples are illustrative. The right tier depends on intended use, not product category. A document management system that holds approved batch records belongs in a different tier from one used only for draft collaboration. Your risk assessment should record why a system was placed in its tier, and the tier should drive the assessment plan rather than the other way around.

Vendor Track Record Is a Factor, Not a Shortcut

A vendor that serves many regulated customers may have a GxP support package, a validation accelerator, or a history of customer audits. That is valuable, and it may reduce what you need to do. PIC/S PI 011-3 mentions shared supplier audits and user group interaction as ways to assess suppliers.¹² But a vendor’s claim that it is “GxP ready” or “validated” needs the same scrutiny as any other claim. A vendor cannot validate your system for your intended use. It can provide documentation that you assess and rely on where it is good enough.

Reassessment Over Time

A SaaS supplier qualification is not a one-time event. The draft Annex 11 expects ongoing oversight through agreed service levels and performance indicators.⁹ EU GMP Chapter 7 expects the contract giver to monitor and review the contract acceptor’s performance.¹³ A practical approach ties reassessment to the SOC 2 cycle: each time a new report arrives, repeat the review steps, compare the exceptions with the prior period, confirm the scope still covers your use, and update the supplier file. Add event-driven reassessment for a change of hosting provider, an acquisition of the vendor, a major platform rewrite, or a significant incident.

Documenting the Assessment So It Holds Up in an Inspection

An inspector who asks about a SaaS system’s supplier qualification wants to see how you decided the vendor was suitable, what evidence you relied on, what you found, and what you did about it. A SOC 2 report on its own answers none of those questions, because it is the vendor’s evidence, not your decision. And as noted above, it may be under a nondisclosure agreement. AWS, for example, requires an NDA to review its SOC 1 and SOC 2 reports and offers a public SOC 3 summary instead.³ Your own written assessment is the record that matters.

What the Supplier Assessment Record Should Contain

• System and intended use. What the system does, which GxP processes it supports, and the risk tier with its rationale.
• Evidence reviewed. The SOC 2 report (with its period, type, auditor, and categories), bridge letter, questionnaire responses, audit report, certifications, and any vendor GxP documentation. Reference each by date and version.
• Scope confirmation. A statement that the product, modules, and regions in use are inside the SOC 2 system boundary, or a note of what falls outside and how it was addressed.
• Report review findings. Opinion type, exceptions noted and their relevance, subservice organizations and how they were assessed.
• CUEC mapping. Each complementary user entity control and the internal control, SOP, or record that meets it.
• GxP gap map. Each GxP expectation, whether the SOC 2 report covers it, and how any gap was closed: questionnaire evidence, audit, contract term, or internal control.
• Residual risks and decision. Risks you accepted, with rationale, and the qualification decision: approved, approved with conditions, or not approved.
• Follow-up actions. Open questions, contract changes, conditions, and dates.
• Reassessment plan. The trigger for the next review, normally the next SOC 2 report, plus event-driven triggers.

Write the Rationale, Not Just the Result

The most common weakness in supplier files is a result without a rationale: “SOC 2 Type 2 reviewed, no issues, vendor approved.” That tells an inspector you received a report. It does not tell them you understood its limits. A single paragraph that says, in plain terms, what the SOC 2 report proved, what it did not, and what you did to close the difference is worth more than a long checklist.

Here is the kind of statement we mean: “The SOC 2 Type 2 report for the period ending March 31 covers security and availability for the production platform in the EU region, which includes our tenant. Processing integrity is not in scope. Two exceptions were noted in change management; the vendor’s response and our follow-up questions are attached. Validation support, release notice, and audit trail controls were assessed through the attached GxP questionnaire and a remote audit. Release notice and test environment access are now contract terms in the quality agreement. All CUECs are met by the SOPs listed in Appendix B.”

That paragraph tells an inspector the reviewer understood the report and made a decision based on risk. It also tells the next reviewer, a year from now, exactly where to start.

Keep the Record Where Inspectors Can See It

Because the current Annex 11 expects supplier quality and audit information to be available to inspectors on request,¹⁰ check your vendor’s nondisclosure terms before an inspection, not during one. Most vendors allow the report to be shown to regulators, but some agreements are drafted narrowly. If the report cannot be shared, your assessment record, which summarizes what you relied on, becomes the evidence.

Conclusion

SOC 2 reports belong in GxP supplier qualification. They are independent, tested over time, and cover security and operational controls that every GxP SaaS system depends on. Throwing them out in favor of a long in-house questionnaire wastes the vendor’s time and yours, and usually produces weaker evidence. The mistake is the opposite one: treating the report as a GxP audit, filing it, and moving on. The report was built to answer questions about security, availability, and a few other categories against general criteria. It was not built to tell you whether a vendor protects your validated state, supports your validation, keeps your audit trails intact, or can restore your records when it counts. A sound SOC 2 GxP vendor audit approach reads the report carefully, maps what it proves, closes the gaps with focused questions, audits where risk demands it, and writes the important answers into the contract.

Sakara Digital works with pharma and biotech organizations on supplier qualification for cloud and SaaS systems, from reading the first SOC 2 report to building a repeatable assessment process that holds up in inspection. If you are reviewing how your team qualifies SaaS vendors and want an independent perspective on where your current approach relies too heavily on attestation reports, we are happy to have that conversation.

For Further Reading