SaaS PE Is Dead, Long Live SaaS PE! (Part 2 of 2): What a Buyer Actually Tests

Part 1 argued that AI has made surface credibility free (policies, control narratives, evidence packages, even a clean audit report from an unrigorous firm) and that this destroys thin SaaS while making the durable ones easier to tell apart. When everyone can produce the artifact, only the things that took years to become true still carry information.

Which leaves the practical question. If the badge in the footer is noise, what do you actually check?

Read the scope, not the opinion

Almost everyone gets this backwards. They receive a SOC 2 Type 2 report, look for the words "unqualified opinion," see them, and file it.

The opinion is the least informative part of the document. The useful part is this: SOC 2 has five Trust Services Criteria, and four of them are optional.

Security is the only required one: the common criteria, the floor. Availability, Confidentiality, Processing Integrity and Privacy are elective. A company chooses which of them to be measured against, and that choice is made long before the auditor arrives, on the basis of what the company believes it can survive being tested on.

So the scope section tells you something the opinion can't: what this company was willing to be held to. A Security-only report from a platform that processes financial transactions isn't a clean bill of health. It's a company that declined to be examined on whether it processes those transactions correctly, and then handed you a document with the word "unqualified" in it.

Scope is the fastest tell in a data room full of plausible vendors. A hastily assembled competitor will always scope to Security only. Not out of dishonesty, but arithmetic. The other four criteria require operational evidence that accumulates over time, and they don't have any.

Run the five criteria as buyer questions. They map cleanly onto the CIA triad that has organized this field for forty years, and the mapping is worth holding in your head: Security and Confidentiality are the C, Processing Integrity is the I, Availability is the A.

Security. Table stakes, and treat it that way. Everyone in the room has it in scope. It differentiates nothing. The only interesting question here is whether the controls described are ones the company designed for its own risk or ones it inherited from a template, and you find that out by asking why a control exists, not whether it does.

Availability. Not the uptime number on the marketing page. Availability as a criterion is about commitments, monitoring, capacity planning, and recovery that has been tested. Test is the operative word. Ask when they last executed a recovery, not whether they have a plan. Everyone has a plan; plans are a writing task, and we've established what happened to writing tasks.

Confidentiality. Classification, handling, retention, and disposal of information the company committed to protect. The revealing question is disposal, because it's the one nobody stages for a demo. Where does customer data go when a contract ends, who verified it went there, and can they show you?

Privacy. Distinct from Confidentiality and frequently conflated with it. Confidentiality is about protecting information; Privacy is about notice, choice, collection, use, retention, and disclosure of personal information: the obligations that GDPR and its descendants actually impose. It requires a data inventory that reflects reality, a lawful basis someone can articulate, and a subject-request process that has processed real requests. Expensive to hold, and almost impossible to retrofit under diligence pressure.

Processing Integrity. This is the one that deserves the most weight, and it's the one that gets skipped.

Why Processing Integrity is the sleeper

Processing Integrity asks whether system processing is complete, valid, accurate, timely, and authorized. In plain terms: does the software do the right thing to the right record at the right time, and can you prove it did?

It's the least-discussed criterion in an industry that talks about security constantly, and it's where hastily generated software fails, and it fails in a way that's nearly invisible from the outside.

Generated code is very good at the happy path, because the happy path is what the training data is full of. Where it's weak is exactly where processing integrity lives: partial failures, retries that aren't idempotent, race conditions under concurrency, ordering guarantees, reconciliation after a failed batch, the edge case at the boundary of two systems that each behaved correctly on their own. None of that shows up in a demo. All of it shows up at volume, months later, in a way that looks like a data problem rather than a design problem.

In payments this isn't an abstraction, it's the whole job. A duplicated transaction is money that moved twice. A dropped one is money that didn't move at all. A reconciliation that silently drifts by a fraction of a percent is a problem you discover from the other side of the table, at the worst possible moment, from a party who is no longer inclined to be generous about it. Any platform that touches money, health records, or regulated reporting has this exposure, whether or not it has ever been examined on it.

A company that carries Processing Integrity in scope has been examined on this and survived. A company that doesn't may be perfectly sound; plenty of good platforms scope narrowly for cost reasons. But you now know which question to ask, and you know that "our SOC 2 is clean" isn't the answer to it.

Two companies, same data room

Make it concrete. Two targets, same category, same revenue band, both with a clean SOC 2 Type 2 sitting in the data room. Call them Ledgerline, eight years old, and Flowstate, eight months from launch and growing faster.

What's the scope? Ledgerline: Security, Availability, Confidentiality, Processing Integrity. Flowstate: Security. Both reports say unqualified. They aren't comparable documents and it took one paragraph to find that out.

What's the observation period? A Type 2 covers a window. Flowstate's is three months, which is the practical minimum, and it's their first. Ledgerline's is twelve, and it's their seventh consecutive. Seven consecutive periods isn't seven times better than one; it's a different claim entirely, because it means no year in which they quietly stopped.

How many exceptions? This is the question people get exactly backwards. Flowstate's report notes zero exceptions. Ledgerline's notes four, with management responses and remediation dates. The instinct is to prefer zero, and the instinct is wrong. A twelve-month examination across four criteria at a real operating company that surfaces nothing at all suggests the testing was shallow or the population was convenient. Exceptions with dated remediation are what a functioning program looks like from the outside. Ledgerline's report is the more credible document because it contains bad news.

What was carved out? Read the subservice organisations and the complementary user entity controls. This is where a company tells you, in language designed not to be read, which responsibilities it has pushed onto its vendors and onto you. Flowstate's CUEC list is long. That isn't a footnote. Read it as a description of the work you're being handed at closing.

Who owns this, and for how long? Ledgerline names a security leader who has held the seat for six years and sat through every one of those seven examinations. Flowstate names a fractional CISO retained four months ago. Both are real arrangements. One of them is a person; the other is a contract.

Show me your largest customer's security review. Ledgerline has a file: a nine-month enterprise review, the assessor's findings, what they remediated, and a renewal signed afterward. Flowstate's largest customer didn't run one. That absence is itself information. It tells you nobody with real leverage has yet had a reason to look closely.

Now ask something the report didn't anticipate. This is the test from Part 1, applied. Pick any control described in the document and ask why it's designed that way: what it traded off, what broke the last time it was changed, what carries the load when it fails. Ledgerline's security leader answers from memory and disagrees with one of their own auditor's characterisations. Flowstate's fractional CISO reads you the control. Both answers are polite. Only one of them came from somebody who was there.

Nothing in that sequence required specialist tooling. It required knowing that the interesting information is in the scope, the period, the exceptions and the carve-outs, not in the opinion.

And a necessary caveat, because the comparison above is tidier than reality usually is: none of this makes Flowstate a bad company. Eight-month-old companies are supposed to look like that. Growing faster than the incumbent is valuable, and a narrow first report is a reasonable decision for a company that has to choose where its money goes. The failure mode in diligence isn't buying the young company; it's buying the young company at the price of the proven one, because both data rooms contained a document with the same words on the cover.

The purpose of the questions isn't to disqualify, but to price. One of these companies is selling you eight years of accumulated proof and one is selling you a trajectory, and those are different assets with different risk profiles. They should not clear at the same multiple. For most of the last decade, they often did, because from the outside, with the cheap signals intact, nobody could tell them apart.

What to do about it on Monday

If you're building rather than buying, invert all of it. Everything above is a list of things you can start accruing now, and the accrual is the point; none of it can be purchased later under time pressure.

Widen your scope before you need to. If you touch money or regulated data and your report is Security-only, adding Processing Integrity is the single highest-value change available to you. Adding it also takes the longest, which is why starting now is worth something.

Keep your exceptions and your remediations. Do not treat a clean report as the goal. A documented history of finding problems and fixing them on a date is more persuasive to a serious assessor than an unblemished record, and it's the thing a new entrant can't fabricate.

Name the owner, publicly and durably. Tenure in that seat is a balance-sheet item. Treat continuity in the role as something you're deliberately protecting rather than something that happens by default.

Capture your customer audit outcomes. Every enterprise security review you survive is a third party verifying you at their own expense. Most companies file these and forget them. File them somewhere you can retrieve them, because in a diligence process they're worth more than anything you wrote about yourself.

Instrument your processing integrity. Reconciliation that runs and alerts, evidence of completeness, idempotency you can demonstrate rather than assert. That work is engineering, not compliance, which is why it usually has no owner.

Make sure someone can answer the second question. If the only person who could explain why a control is built the way it is left the company last year, you don't have a control environment. You have a document describing one. That gap stays invisible right up until somebody competent asks, and then it's the only thing in the room.

Long live SaaS PE

The capital isn't leaving software. It's going to start asking better questions, because the old questions stopped separating anything.

That's a good outcome for anyone who has spent years doing the unglamorous version of this work: the assessments, the customer reviews, the reconciliation that runs at three in the morning and pages someone when it drifts. For most of the last decade that work was invisible in a market where a competitor could buy the same badge and put it in the same footer.

The glut took the badge's meaning away. What's left is the part that took years, and years are the one input that hasn't gotten cheaper.

If you've been carrying that work as a cost centre, it's worth reconsidering what it actually is. Every examination you've survived, every customer review you passed, every year you didn't quietly stop. Those were always assets. They were just impossible to price in a market where a six-month-old competitor could display the same credential. That market is ending. Boring, proven and thoroughly assessed is about to be repriced, and it's going to be repriced upward.

SaaS PE is dead. Long live SaaS PE.