Why nonprofit tech buyers now expect a SOC 2 report by default — and why it takes far longer to issue a real one than your compliance automation tool would like you to believe.
Two things are true about SOC 2 right now, and they sit a little awkwardly next to each other.
The first is that, in 2026, a nonprofit tech vendor without a SOC 2 report is increasingly hard to sell into the mid-market and above. Buyers ask for it on first calls. RFPs reference it by name. Foundations and grantmakers expect their vendors to have it. The major incumbents in our category put it on the front of their trust pages because they know it’s the first thing a procurement reviewer looks for. SOC 2 has crossed the line from differentiator to fit-for-purpose. It is, functionally, part of whether your product can be bought.
The second is that issuing a real one — the kind of report that holds up under scrutiny rather than the kind that just satisfies a checklist — is a 9-to-15-month program of work that no tool can compress to a button. Anyone selling you otherwise is selling you something subtler than a compliance program.
This post is about both halves of that, and what we think you should do about it.
Table stakes: how SOC 2 became part of the spec
It used to be true that a small or mid-size nonprofit would pick its software the way it picked its office printer — by feature, by price, and by whose demo went best. Security questions, when they came up at all, came up late, and they came up casually. That world is gone.
Look at where the sector now points buyers when they’re evaluating vendors. The Nonprofit Alliance’s 2025 RFP best-practices guide treats security and compliance attestations as standard RFP components alongside pricing and functionality. Fundraise Up’s compliance checklist for nonprofit software buyers is direct about it: “The easiest and most effective way to ask for proof of data security is to request a SOC 2 Report.” Tech Impact’s guided assessments for nonprofits include vendor security maturity as a first-class evaluation dimension. NTEN’s cybersecurity guidance tells nonprofits, in plain language, to confirm that their vendors adhere to the same security standards their own staff and volunteers do. None of these are marginal voices in the sector. They are the places nonprofits look when they’re deciding who to give their money to.
Look at where the major NPTech vendors have decided to put their security posture in the buyer’s path. Salesforce.org, Bonterra, Neon One, GiveButter, Virtuous — every one of them has a public trust center, and every one of those trust centers leads with SOC 2. They didn’t put it there because it’s pretty. They put it there because it’s load-bearing in the sales conversation, and it’s the credential that closes the procurement security questionnaire fastest.
Look at the foundations. Candid — one of the largest data infrastructure organizations in U.S. philanthropy — publicly maintains its own SOC 2 program and explicitly conducts security reviews of every third-party vendor it partners with. When the central data utility of the sector is doing this, it sends a signal downstream: the grantmakers and infrastructure partners that nonprofits depend on are being held to a SOC 2-shaped standard, and they will hold their vendors to it in turn.
And look at what changed the room. The 2020 Blackbaud ransomware incident — which reached more than 13,000 nonprofit customers and an estimated 13 million individuals, and ultimately produced coordinated enforcement settlements from federal securities regulators, the federal consumer protection authority, and 49 state attorneys general totaling more than $59 million — did more to raise the security bar in nonprofit tech buying than any RFP template ever could. The current vendor-breach environment has only sharpened it. Roughly 30% of breaches in 2024 involved a third-party vendor — double the rate of the year before. Nonprofits, foundations, and the people who advise them have absorbed that, and they have started buying differently.
SOC 2 is no longer a nice piece of trust-page furniture. It’s part of the functional spec — like asking whether your platform takes backups. Without it, you don’t get to the demo.
Anything but: what it actually takes to issue a first SOC 2
If you have not been through it, the easiest mistake to make is to assume SOC 2 is a thing you can decide to have. It isn’t. It’s a program of work, ratified by an opinion issued by a licensed CPA firm under AICPA standards. The opinion only means anything because the work it’s based on actually happened. Compress the work and you compress the meaning of the report. Here’s what the work actually looks like, in rough order:
- Scoping. Decide which Trust Services Criteria you’re in scope for — Security at minimum, plus some combination of Availability, Processing Integrity, Confidentiality, and Privacy. The wrong scope will haunt you for years.
- Control identification and design. Translate your environment into a defensible control set — usually 60–120 controls for a first-time engagement, depending on scope and complexity.
- Policy authoring. The minimum viable stack is usually 12–20 policies, including Information Security, Access Control, Incident Response, Change Management, Vendor Management, Acceptable Use, Business Continuity, Risk Management, and SDLC.
- System and tooling implementation. Endpoint management, identity provider configuration, logging and monitoring, vulnerability management, evidence collection automation, ticketing for change and access reviews. Most companies discover gaps here that take months to close.
- Gap remediation. The first readiness assessment is almost always a list of things you thought you did and didn’t, written down. Closing those gaps is the bulk of the work.
- Observation period. For Type 2, you need a window of operating effectiveness — typically 6 months for a credible first report, sometimes 3 months for an interim bridge, often 12 months thereafter. SSAE 18, the AICPA standard governing SOC 2, makes this period non-optional. No tool can compress wall-clock time.
- Audit fieldwork. The CPA firm tests your controls, samples your evidence, interviews your team. Three to six weeks of focused work, often more for first-timers.
- Management responses, draft, and final report. Two to six more weeks to close findings, exchange drafts, and issue the final report under the audit firm’s letterhead.
Add it up and the realistic timeline for a first-time SOC 2 Type 1 is two to four months. For a first-time Type 2 — the report your enterprise buyers actually want — it’s nine to fifteen months end to end. That is not a pessimistic number. It’s the number CPA firms that specialize in SOC 2 quote when they’re being honest with their clients.
Cost has a similar shape. Audit fees alone for a first Type 2 typically land between $20K and $80K depending on scope, complexity, and the firm. Total program cost — including readiness work, automation tooling, and the staff time you’ll spend internally — is usually two to three times that, and that’s before the productivity tax of the months your engineering team spends building the controls instead of building the product.
None of this is a reason to delay. It’s a reason to start earlier than the first RFP that asks for it.
Be careful of the “SOC 2 in days” pitch
Compliance automation tools are real, useful, and worth the money. We use them with our clients. They genuinely accelerate the parts of SOC 2 that benefit from automation — control monitoring, evidence collection, policy templating, integration coverage, audit liaison. If you’re starting from scratch, picking a good one is one of the highest-leverage decisions you can make.
What they do not do is compress the program. They do not collapse the observation period. They do not perform the audit. They do not turn the work of building a security program into the work of buying a SaaS subscription. And the marketing that suggests they do — “get audit-ready in weeks instead of months,” “SOC 2 in days,” “audit-ready out of the box” — is a category of claim worth reading carefully.
The Journal of Accountancy ran a piece in February 2026 that said the quiet part out loud: CPAs themselves are warning that the high-volume push for fast SOC reports is starting to threaten the credibility of the SOC service line. The article documents tool vendors cultivating networks of small audit firms to issue reports at scale, and warns that a flood of low-quality SOC 2 reports — “all exactly the same, with a different client logo on it” — could erode confidence in the framework itself. That is auditors talking about their own profession. It is worth listening to.
The buyer’s view of this is sharpening too. Sophisticated procurement reviewers — and the security teams behind them — have started reading SOC 2 reports the way a credit analyst reads a 10-K. They look at the system description for thinness. They look at the control matrix for templated language. They look at the auditor’s name. They look at the observation period. A six-page Type 1 from a no-name firm doesn’t open the same doors a substantive Type 2 does, even if both technically check the box.
Automation tools accelerate the work. They don’t replace it. The certificate isn’t what your buyer is paying for. The practice underneath it is.
Why this matters more in our sector
There is a version of this conversation that’s just about competence and procurement hygiene. We could leave it there, and most software industries probably would. But the reason Betterleg keeps coming back to the standard-of-care question is that the data we hold for the nonprofit sector isn’t ordinary commercial data, and the people whose information sits in our systems aren’t ordinary customers.
A donor’s gift history is the material record of donated trust. A beneficiary’s case file may be the most sensitive record of her life. Neither of them was a party to the contract that brought their data into our environment. Neither of them clicked an “I agree” box that lets us treat their information the way a B2B SaaS company treats a marketing list. When we hold their data, we hold it on behalf of the organizations they trusted, and those organizations hold it on their behalf.
That responsibility is what a SOC 2 program is supposed to be a public statement about. Done well, it is the closest thing our industry has to a vow. Done as a checklist exercise rushed through to clear procurement, it is the opposite — a credential that looks the same on the trust page but means materially less under the hood. Donors and beneficiaries can’t tell the difference. That’s exactly why we have to.
If you are a nonprofit tech vendor in the early stages of your SOC 2 journey, our argument is simple. Yes, you need one. The market won’t wait for you. But do it as the security program first and the certificate second. Pick an automation tool that helps you actually mature the underlying work, not one that helps you mime it. Pick an audit firm whose reputation is downstream of the quality of its reports, not the speed of its turnaround. Plan for nine to fifteen months and don’t let anyone sell you a shortcut you’ll regret the next time a customer’s CISO actually reads the report.
If you’d like to talk it through
Betterleg has shepherded a lot of nonprofit tech vendors through their first SOC 2 — and through the second one, where the lessons from the first one finally land. If you’re in the early stage of scoping a program, somewhere in the middle and stuck, or staring at a procurement requirement and trying to figure out what’s realistic in the time you have, we’d be glad to chat.
Reach out on our contact form or subscribe to our newsletter for plain-language compliance posts, security playbooks, and the occasional opinion you can take into a Tuesday standup. We’d rather be in the conversation.
