Most nonprofits do not ask software vendors about security certifications when evaluating new tools. They ask about features, pricing, and implementation time. Security comes up later — usually after a breach, a compliance audit, or a funder asking questions the organization cannot answer.
SOC 2 is a security framework that certifies how a software vendor protects your data. For nonprofits handling sensitive donor information and financial records, choosing SOC 2-aligned software is an increasingly essential fiduciary responsibility — not because regulators require it, but because the donors, funders, and board members who trust you with their information increasingly expect it.
What SOC 2 Actually Is
SOC 2 stands for Service Organization Control 2. It is a framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates how software vendors manage data security. A SOC 2 report is produced by an independent auditor who examines the vendor's systems and controls against five Trust Services Criteria.
SOC 2 is not a government regulation and not a certification in the traditional sense. It is a voluntary audit that produces a report. When a vendor says they are "SOC 2 compliant" or "SOC 2 Type II certified," they mean an independent auditor has reviewed their controls and produced a report confirming those controls were operating effectively.
There are two report types:
- SOC 2 Type I evaluates whether controls are properly designed at a point in time
- SOC 2 Type II evaluates whether controls operated effectively over a period of time (typically six to twelve months)
Type II is the more meaningful standard. It demonstrates sustained, consistent control operation rather than a snapshot.
The Five Trust Services Criteria
SOC 2 evaluates vendors against five criteria. Not all vendors are evaluated on all five — they choose which criteria are relevant to their services. For financial software used by nonprofits, the most important criteria are:
Security
The system is protected against unauthorized access. This includes physical security of data centers, network security, access controls, encryption of data in transit and at rest, and vulnerability management.
For nonprofit financial software, security is the baseline. Your donor payment information, grant financial records, payroll data, and financial statements should be stored in a system that cannot be accessed by unauthorized parties.
Availability
The system is available for operation and use as committed. This covers uptime guarantees, disaster recovery capabilities, and business continuity planning.
For organizations with month-end close deadlines, reporting obligations to funders, and audit schedules, system availability is a real operational concern. A system that is regularly unavailable during business hours creates compliance risk.
Processing Integrity
System processing is complete, valid, accurate, timely, and authorized. For a financial system, this means transactions are processed correctly, calculations are accurate, and the system does not introduce errors into your financial data.
Confidentiality
Information designated as confidential is protected. This covers data classification, access restrictions on sensitive data, and the vendor's policies around who within their organization can access your data.
Privacy
Personal information is collected, used, retained, and disclosed appropriately. For nonprofits with individual donor data, this criterion governs how donor personal information is handled by the software vendor.
Why This Matters for Nonprofits Specifically
Nonprofits handle several categories of sensitive data that make security a genuine fiduciary concern.
Donor payment information. Credit card and bank account data from online donations is highly sensitive. The system processing this data must meet security standards that prevent unauthorized access.
Major donor records. Donor giving history, contact information, and relationship notes represent sensitive personal data that donors share in confidence. A breach of this data damages donor trust in ways that are difficult to repair.
Financial records. Your general ledger, grant financial data, payroll records, and audit documentation represent the full financial picture of the organization. Unauthorized access to this data creates both legal exposure and reputational risk.
Federal grant compliance. Organizations receiving federal grants are subject to data protection requirements as part of the broader compliance framework. Using software with documented security controls supports compliance.
What "No Hard Deletes" Means and Why It Matters
One of the most practically important SOC 2-adjacent principles for financial software is the soft delete policy. In a system with hard deletes, financial records can be permanently destroyed. In a system with soft deletes, records are marked as deleted but retained — they cannot be recovered by users in normal operation, but they are preserved in the system for audit and compliance purposes.
For nonprofit financial software, soft delete is not a design preference. It is a data integrity requirement. Federal grant retention rules, IRS record retention expectations, and audit requirements all assume that financial records will be available for the applicable retention period. A system that hard-deletes records puts compliance at risk.
When evaluating software, ask explicitly: what happens when a user deletes a transaction or record? If the answer is "it's gone," that is a material compliance risk.
Questions to Ask Software Vendors
When evaluating nonprofit financial software, include these questions in your due diligence:
- Are you SOC 2 Type II certified? If so, can you provide the most recent report or a summary of findings?
- What is your data deletion policy? Do you use soft deletes on financial records?
- How is data encrypted? At rest and in transit?
- Who within your organization has access to our data? Under what circumstances and with what controls?
- What is your incident response process? How would you notify us in the event of a breach?
- Where is our data stored? In what country and with what cloud provider?
- What is your data retention policy when we terminate service? How long is our data available and in what format?
These are reasonable due diligence questions that any reputable software vendor should be able to answer. Vendors who cannot or will not answer them should be disqualified from consideration.
sherbertOSOS's architecture follows SOC 2 principles: soft delete on all financial data ensures no records are permanently destroyed; activity logging captures every operation with user attribution and timestamps; row-level security enforces access boundaries at the database layer; and data is encrypted in transit and at rest.
For audit trail documentation that SOC 2 principles support, see Why Audit Trails Matter for Nonprofit Financial Data. For access control principles that complement SOC 2 security, see Role-Based Access Control for Nonprofit Financial Systems.
Frequently Asked Questions
Do nonprofits need SOC 2-certified software?
It is not legally required for most nonprofits, but it is becoming a best practice — especially for organizations handling sensitive donor data, processing online payments, or receiving federal grants. Some major funders are beginning to ask about data security practices in grant applications.
What is the difference between SOC 2 Type I and Type II?
Type I evaluates whether controls are properly designed at a point in time. Type II evaluates whether controls operated effectively over a sustained period (typically six to twelve months). Type II is the more meaningful standard because it demonstrates consistent control operation rather than a snapshot.
What does "no hard deletes" mean in practice?
Financial records are never permanently destroyed. When a user deletes a record, it is soft-deleted — marked as inactive — and can be recovered by administrators for audit or compliance purposes. This is essential for meeting financial record retention requirements.
Should SOC 2 be on our software RFP?
Yes. Ask vendors about their SOC 2 status, data encryption practices, deletion policies, and incident response procedures. A vendor who cannot answer these questions clearly is a vendor who has not invested in security controls.
Is SOC 2 the same as HIPAA compliance?
No. HIPAA governs protected health information specifically. SOC 2 is a broader security framework applicable to software vendors generally. Some organizations need both — a nonprofit health clinic, for example, may need HIPAA-compliant software with SOC 2-aligned security controls.
The Bottom Line
Software security is not a technical question for IT staff. It is a governance question for nonprofit leadership. The data you entrust to your software vendor — donor information, financial records, grant documentation — represents information your donors, funders, and regulators expect you to protect.
The standard for software selection is rising. Asking about SOC 2 certification and data protection practices is no longer a sophisticated question from large organizations. It is a basic due diligence question that any nonprofit leader can and should ask.
→ Subscribe to the sherbertOS newsletter for guides on nonprofit data security, compliance, and financial systems.
Frequently Asked Questions
Do nonprofits need SOC 2-certified software?
It's not legally required, but it's becoming a best practice — especially for organizations handling sensitive donor data or receiving federal grants.
What does 'no hard deletes' mean?
Financial records are never permanently destroyed. Deleted data is soft-deleted (flagged as inactive) and can be recovered for audit or compliance purposes.
Should SOC 2 be on our software RFP?
Yes. Ask vendors about their SOC 2 status, data encryption practices, and incident response procedures. It's a reasonable due diligence question.
Related Articles
See sherbertOS in action
Schedule a personalized walkthrough with our team.