Blog

If a vendor shows you a SOC 2 badge, what have you actually learned about how it'll protect your data? In most cases, almost nothing, because the badge hides the only details that matter. What is SOC 2 compliance and why is it important comes down to a report, its scope, and its testing period. Read those three things and you'll know whether the assurance covers the system you plan to use.

Table of Contents

• What SOC 2 Compliance Means in Plain Terms
  • A kitchen inspection you can actually read
• The Five Trust Services Criteria Explained
  • What each criterion looks like on an R&D platform
  • From a criterion to a piece of evidence
• Type 1 vs Type 2 Reports and What They Cover
  • Scope is where reports get misread
• Why SOC 2 Matters for IP-Sensitive R&D Data
  • Why R&D data raises the stakes
  • What SOC 2 gives you, and what it doesn't
• How to Prepare for a SOC 2 Audit Step by Step
• Vetting a Vendor's SOC 2 Report Before You Sign

What SOC 2 Compliance Means in Plain Terms

Say you're about to hand a vendor your customer data, your experimental records, and a formulation you haven't published yet. The vendor says its platform is secure. That claim might be honest, but it's still the vendor grading its own work.

SOC 2 replaces that self-assessment with an independent examination. A CPA firm tests a service organization's controls over the systems that deliver its product, using a framework developed under the American Institute of Certified Public Accountants (AICPA). The AICPA SOC 2 resources describe an evaluation of whether controls are suitably designed and, for a Type 2 examination, operating effectively over a defined period.

That distinction is why SOC 2 is not a certificate. There's no pass stamp you earn once and keep forever. There's a report, written by an auditor, that describes what was tested and what the auditor found.

A kitchen inspection you can actually read

A restaurant health inspection offers a useful comparison. You don't have to trust the owner's word that the kitchen is clean, because an inspector checked the storage temperatures, the handwashing station, and the pest control log, then wrote up the results. A SOC 2 report works the same way for a software vendor. You read the inspector's findings instead of the owner's promise.

In practice, the evidence an auditor reviews is ordinary operational paperwork. It includes access reviews, change management records, backup and recovery tests, incident response exercises, vendor risk assessments, and audit logs. None of that is exotic. The value is that someone independent checked whether it happened, on schedule, the way the policy said it would.

SOC 2 is also voluntary. No law requires a vendor to get one. Enterprise buyers request it anyway, because they need evidence they can put in front of their own risk teams. That request is strongest when the data at stake is proprietary research, personal information, or operational records that would be expensive to reconstruct or damaging to lose.

Trust transfer: You stop relying on a supplier's security claims and start relying on an auditor's report about that supplier's controls.

Before you accept any vendor's SOC 2 claim, ask three questions. What was examined, meaning which systems and services. Against which criteria, meaning which of the five Trust Services Criteria applied. Over what period, meaning when the testing happened. If a vendor can't answer those three, you have a logo, not assurance.

The Five Trust Services Criteria Explained

Every SOC 2 report is measured against the AICPA Trust Services Criteria. Only one of the five is mandatory. Security appears in every engagement, and the other four get added only when the service makes promises that need them.

That's the first thing readers get backwards. A report covering all five criteria isn't automatically stronger than one covering two. It might just mean the vendor paid to test criteria its customers never asked about. The AICPA 2017 Trust Services Criteria with revised points of focus can be applied across an entity, subsidiary, division, or a specific system supporting a product or service, so the boundary matters as much as the list.

The five Trust Services Criteria at a glance

What each criterion looks like on an R&D platform

Abstract labels get clearer once you attach them to a real system. On a materials R&D platform, security covers role-based access and encryption configuration, so a scientist sees only the projects she's assigned to. Availability covers uptime commitments and backup recovery tests, so a lab team can retrieve last month's run after an outage.

Processing integrity covers complete and accurate handling of experimental results, so a calculation doesn't drop rows. Confidentiality covers unpublished formulations that you've marked confidential and that must not leak to another tenant. Privacy covers personal data about lab staff and external collaborators, such as names, emails, and account details.

Notice that confidentiality and privacy aren't the same thing. Confidentiality is about information you've designated as sensitive, whatever it is. Privacy is specifically about personal information and how it's collected, used, retained, and disposed of. Confusing the two leads buyers to assume a privacy criterion protects their formulations. It doesn't.

From a criterion to a piece of evidence

A criterion is a question. A control is the vendor's answer, and evidence is proof the answer held up. For security, evidence might be privileged-account monitoring records and quarterly access reviews with sign-offs. For change management, it's tickets showing a second person approved a production release before it shipped.

The auditor then checks two separate things. First, is the control designed sensibly, so it would work if people followed it? Second, did people follow it, repeatedly, across the review period? A beautifully written access policy that nobody enforced fails the second test.

To decide which criteria matter for you, start with your own promises. If your team guarantees customers a specific uptime, you need availability from your vendor. If you're handing over unpublished IP, confidentiality is the one to insist on. Match the criteria to the commitment, and ignore the rest.

Type 1 vs Type 2 Reports and What They Cover

The difference between the two report types is time. A Type 1 report asks whether controls were suitably designed on a single date. A Type 2 report asks whether those controls were designed suitably and then operated effectively across a whole review period.

That gap matters more than it sounds. A control can look perfect on audit day and still be skipped for the other eleven months. Procurement teams have learned this the expensive way, which is why IBM's Cost of a Data Breach research, based on 600 organizations across 17 industries with breaches between March 2024 and February 2025, gets cited in vendor reviews. It documents how costly third-party exposure becomes when assurance is thin.

Type 1 and Type 2 reports side by side

Scope is where reports get misread

Buyers often stop at the report type and never check scope. That's the expensive mistake. A vendor can hold a genuine Type 2 report for its core platform while the feature you're buying sits outside the audited system entirely.

Say you plan to use an AI model feature that sends formulation data to a subprocessor for inference. If that subprocessor, that data flow, or your retention setting falls outside the system description, the report tells you nothing about it. The auditor never looked. The same applies to a new integration, a separate regional deployment, or an add-on product the vendor acquired last year.

A report only supports conclusions about the systems, criteria, and period it actually tested. Everything outside that boundary is still an unverified claim.

Two documents fill the gaps a report leaves. A bridge letter covers the stretch between the end of the report period and today, with management stating whether anything material changed. Complementary user-entity controls list the things you must do yourself, such as enforcing your own user provisioning and reviewing who on your team has access. Skip those controls and the vendor's controls can't do their job.

So the reading order is fixed. Open the system description first and confirm your product, region, and data flows are inside it. Then check which criteria applied, then the testing window, then the exceptions. Read the scope before you look at the badge.

Why SOC 2 Matters for IP-Sensitive R&D Data

Start with the money, because that's what changes a procurement conversation. A breach at a vendor can cost you as much as a breach inside your own building, and you have far less control over the response.

IBM 2025 breach cost benchmarks

Two numbers carry the argument. The global average of USD 4.44 million sets the baseline for an ordinary incident. The third-party vendor or supply-chain figure of USD 4.91 million sits above it and nearly matches a malicious insider attack. A supplier you chose can hurt you about as much as an employee acting deliberately against you.

Why R&D data raises the stakes

Materials R&D data doesn't sit in one place. Formulations live in spreadsheets, process parameters in lab systems, experimental images in shared drives, and analysis in third-party tools. Each handoff is another environment, another set of credentials, and another vendor's controls standing between your IP and the outside world.

That fragmentation is exactly what the multiple-environment figure reflects. More environments means more places where access rules drift, where a departed contractor's account stays active, or where a dataset gets copied somewhere nobody monitors. A formulation that took years of experiments to develop can leave through the least governed tool in the chain.

Say a formulation chemist needs a quick chart for a review meeting. She exports a shared dataset into a free tool she found that morning, because it's faster than the approved route. Nothing malicious happened, but your unpublished results now sit on a server your team never assessed. Access controls, data handling rules, and a vendor risk review are what catch that move before it becomes a disclosure.

What SOC 2 gives you, and what it doesn't

SOC 2 contributes documented controls plus independent evaluation. That combination gives your risk team something concrete to review, and it gives leadership evidence that security is managed systematically rather than improvised by whoever set up the account.

It does not prevent every breach. It doesn't replace penetration testing, which probes whether an attacker can get in. It doesn't substitute for contract terms covering incident notification timelines, data return, and liability. Treat it as one strong layer, not the whole defense.

What you gain is a defensible basis for a vendor decision. Instead of telling leadership that a platform seemed trustworthy, you can show which controls an auditor tested, over what period, and where the exceptions were.

How to Prepare for a SOC 2 Audit Step by Step

Preparation is mostly unglamorous documentation work done early. The teams that struggle aren't usually missing security tools. They're missing records proving they used them.

Here's the sequence that works, with the slip that usually derails each step.

1. Define the system boundary. List the products, infrastructure, data flows, subprocessors, and locations the report will cover. The usual slip is drawing the boundary too narrowly, so the report excludes the product your biggest customer uses.

2. Choose the criteria. Start with security, then add availability, processing integrity, confidentiality, or privacy only where a customer commitment requires them. Teams slip by selecting all five to look thorough, then paying to test criteria nobody asked for.

3. Map controls to criteria. Document access reviews, change management, encryption, backups, incident response, and vendor risk assessments, with a named owner for each control. A control without an owner stops happening the moment someone changes roles.

4. Gather evidence on a routine. Keep logs, tickets, and approvals as you go, because a Type 2 auditor samples across the entire review period. Starting collection a few weeks before fieldwork leaves you with nothing to show for the early months.

The video below walks through how that evidence collection works in practice during an examination.

5. Run a readiness assessment. Find the gaps before your auditor does, then close them with written policies and recorded staff training. Skipping this step means your first real audit becomes your gap analysis, at audit prices.

6. Select an independent CPA firm. Agree the report type and review period up front, and confirm who on your side will answer evidence requests. Booking late is the common slip, since experienced firms fill their calendars months ahead.

7. Complete the examination and read the report. Check the auditor's opinion and every exception, not just the summary. Teams slip by forwarding the report to customers without reading the sections where controls failed a test.

8. Keep the controls running. Schedule the next report so coverage doesn't lapse. Controls that only operate during audit season produce exceptions in the next cycle.

Practical rule: If a control doesn't leave a dated record, an auditor has to treat it as though it didn't happen.

Budget your timeline. Even after your controls are designed and documented, a Type 2 report needs its observation window to run, which adds months before you can hand anything to a customer. If you're building your first control list, SOC 2 planning with Sift AI offers a useful starting structure for sequencing that work.

Vetting a Vendor's SOC 2 Report Before You Sign

Treat the report as one input beside contract terms and technical testing, not as the decision itself. Work through this checklist before any sensitive data moves.

• Request the full report. A logo on a pricing page tells you nothing about scope or exceptions.
• Confirm the criteria and review period. Check that both match the service and timeframe you'll rely on.
• Read the exceptions and the auditor's opinion. Look for failures in the areas your data depends on.
• Check subprocessors and data locations. Confirm where your data will sit and who else can touch it.
• Confirm incident notification commitments. Get the timeline in the contract, not in a sales call.
• Ask what changed after major architecture or AI model updates. Controls tested last year may not describe this year's system.
• Identify your complementary user-entity controls. Assign owners for the tasks the report expects you to perform.

Pair the document review with outside signals about a vendor's exposure. GoSafe Dark Web monitoring on vendor risk sets out how leaked credential monitoring fits into broader vendor due diligence. We hold ISO 27001, ISO 27017, ISO 27018 and SOC 2 certifications, follow industry security standards, regularly conduct security audits and application testing, and provide the reports to customers.

If a vendor can't produce a current report, treat its security claims as unverified and widen your contract protections before sharing anything sensitive. A current Type 2 report covering the systems you'll use, with no unresolved exceptions in the areas you rely on, is a strong basis for trust. A badge without scope isn't. Request the report and any bridge letter before signing, then map its scope against the data you plan to share.

---

If you're moving experimental data and unpublished formulations onto a platform, you deserve controls you can inspect rather than claims you have to take on faith. Polymerize unifies fragmented materials R&D data into a secure, AI-ready backbone with role-based access and audited controls, so your team can run targeted experiments without exposing its IP. Visit us to review our security documentation and see how the platform fits your vendor review.