Your finance team is ready to recommend a new platform. The vendor has sent a SOC 3 badge, the board chair has asked for the SOC 2 report, and your external auditor wants to know which systems the examination covered. Meanwhile, staff are still reconciling investor notes, loan payments, and the general ledger across disconnected files.
The practical answer to SOC 2 vs SOC 3 is straightforward: use the public report to establish that independent assurance exists, then obtain the detailed evidence before approving a system that will hold the fund's financial records. Stewardship requires both trust and a documented basis for it.
SOC 2 and SOC 3 at a Glance
A vendor badge isn't the document your audit committee needs. When the board requests a SOC 2 report after receiving a SOC 3 summary, it's asking for more evidence, not a better-looking seal.
Both are attestation reports under the American Institute of Certified Public Accountants, or AICPA, built around the Trust Services Criteria, the criteria used to evaluate relevant controls. The difference is principally the detail disclosed and the audience permitted to receive it.
A management assertion is the service organization's statement about its controls. The service auditor is the independent practitioner who examines that assertion and issues an opinion.
SOC 2 and SOC 3 compared on the same criteria
| Dimension | SOC 2 | SOC 3 |
|---|---|---|
| Trust Services Criteria applied | Security, availability, processing integrity, confidentiality, privacy as scoped | Same criteria as the underlying SOC 2 |
| Control descriptions | Included in detail | Omitted |
| Auditor test procedures and results | Included | Omitted |
| Management assertion and auditor opinion | Included | Included |
| Distribution | Restricted to intended users, normally under confidentiality terms | General use and can be published freely |
| Typical reader | Customers, auditors, regulators, risk committees | Prospective customers, board packets, public website |
Match the document to the decision
The table compares a SOC 2 Type II report with its public-facing companion. Their purposes differ: one supports examination of outsourced-service risks; the other communicates an assurance conclusion without disclosing sensitive operational detail.
Don't confuse the presence of an auditor's opinion with access to the evidence behind it. Your finance team needs enough information to challenge the vendor's answers, identify responsibilities the fund retains, and decide whether unresolved issues are acceptable.
For board members who need an introduction before reviewing the reports, Pipecorn's SOC 2 compliance requirements explained provides a useful starting point for understanding the control framework.
Boardroom takeaway: The SOC 2 belongs in the diligence file. The SOC 3 is the public summary drawn from the same underlying examination.
Neither document should be treated as a decorative procurement requirement. Choose the report according to the decision someone must make and the evidence they need to defend it.
What the Five Criteria Cover and What the SOC 3 Leaves Out
Security is the core category. Availability, processing integrity, confidentiality, and privacy may also be included, but their inclusion follows the examination scope. The AICPA's SOC 3 guidance explains that both reports address the relevant Trust Services Criteria, while SOC 3 omits the detailed testing and results available in SOC 2.
Read the scope before drawing conclusions. A report covering security alone doesn't establish that the auditor also examined the vendor's commitments concerning processing accuracy or service availability.
For a church extension fund, translate the categories into operational questions:
- Security: Who can access investor accounts, change payment instructions, or administer the platform?
- Availability: Can staff access essential services when payments and reporting are due?
- Processing integrity: Are transactions processed accurately, completely, and on time?
- Confidentiality: How does the provider protect restricted financial information?
- Privacy: How does it handle personal information about investors, borrowers, and other individuals?
Follow a transaction through the controls
Consider a loan servicing platform that handles investor notes, Automated Clearing House (ACH) payments, and general ledger data. Your reviewer should look beyond whether staff authenticate successfully. They should examine how privileged access is reviewed, how software changes are approved, and how the provider responds when an incident affects financial processing.
The SOC 2 supplies management's system description, applicable criteria, control descriptions, auditor procedures, and results, including identified exceptions. Those details let a reviewer distinguish a documented policy from evidence that staff followed it.
A SOC 3 retains management's assertion and the auditor's opinion, but not the detailed testing needed for that analysis. It communicates the conclusion without exposing the supporting operational record.
A SOC 3 establishes that an assurance conclusion exists. A SOC 2 Type II shows how the examined controls operated during the review period.
That distinction matters when a software change could affect interest accrual, payment allocation, or an investor statement. For a platform holding the fund's financial records, request the detailed report. A public summary cannot resolve a control question it doesn't describe.
Type I, Type II and What the Audit Period Means
For operational assurance, the more consequential comparison is SOC 2 Type I versus Type II. Type I evaluates whether controls are suitably designed and implemented at a specified date; Type II also evaluates operating effectiveness over a stated period, as explained in Microsoft's SOC 3 overview.
SOC 3 is generally the condensed public companion to the Type II examination. It isn't an unrelated audit offering a different control standard.
SOC 2 Type I, Type II and SOC 3 by what they test
The cost benchmarks below are 2024 audit estimates from Sprinto's SOC reporting comparison, not current quotations or complete implementation budgets.
| Report | What It Evaluates | Period Covered | Typical Cost (2024) |
|---|---|---|---|
| SOC 2 Type I | Whether controls are suitably designed and implemented | One specified date | $5,000 to $25,000 |
| SOC 2 Type II | Design plus operating effectiveness of controls | Stated review period | $7,000 to $50,000 |
| SOC 3 | Same criteria as the underlying Type II, in summary form | Same period as the underlying Type II | Minimal add-on cost, no additional testing |
A date isn't a history of performance
Suppose your fund receives a Type I report in March. It may provide useful evidence that the provider established appropriate controls at the examination date. It doesn't establish that access reviews, change approvals, and incident procedures operated consistently throughout your financial reporting year.
Don't infer coverage from the report's issue date. Read the actual examination period, then compare it with the period your auditor needs to evaluate. A recently delivered report may concern an earlier operating period.
The current reference point is the 2017 Trust Services Criteria, with revised points of focus issued in 2022, identified in the Microsoft guidance cited above. Those dates identify the framework, not the age or currency of a particular vendor's examination.
Our SOC 2 Type II report guide provides additional context for evaluating period-based evidence in a church fund's technology review.
Make Type II the baseline for reviewing an established production service. A Type I report can be a meaningful milestone, but it shouldn't be represented to the board as equivalent evidence. Cost is a vendor planning consideration; the fund's approval standard should follow the risk of the work being outsourced.
Which Report Each Stakeholder and Situation Needs
The access question is practical: a public summary can circulate freely, while detailed control information needs controlled distribution. Arrange access before the approval meeting rather than discovering that your auditor cannot obtain the report after the contract is signed.
The AICPA's SOC 2 and SOC 3 reporting course distinguishes information that helps outsourcing organizations and their auditors assess risks and controls from the less detailed material intended for public use.
Minimum evidence by stakeholder
| Stakeholder | Question They Must Answer | Minimum Evidence |
|---|---|---|
| Board members | Are vendor controls adequate for our loan and investor data? | SOC 3 for the board packet, SOC 2 summary for committee review |
| External auditors | Did controls over ledger and reporting operate during the period? | Full SOC 2 Type II |
| Compliance officers | Do access, change, and incident controls work in practice? | Full SOC 2 Type II |
| Procurement or enterprise partners | Can we screen this vendor quickly? | SOC 3 for screening, full SOC 2 before approval |
| Prospective churches or public visitors | Does this vendor have independent assurance? | SOC 3 published on the website |
A committee summary should identify who reviewed the full report, what exceptions mattered, and which responsibilities remain with the fund. It shouldn't repeat the vendor's assurance statement.
Vendor selection and routine governance
A platform selection involving sensitive financial records. Say a fund with $180 million in investor notes is evaluating a loan servicing platform that will hold ACH instructions and general ledger data. The audit committee and external auditor should review the full SOC 2 Type II under confidentiality terms, asking whether its period and exceptions support the proposed use.
A quarterly board packet. A SOC 3 can serve as the assurance attachment when the committee has completed detailed diligence and the full SOC 2 is available to authorized reviewers. The board should still receive a concise account of material exceptions and any gap between the examination period and the current quarter.
Public communication and audit renewal
A denominational lending program's website. Publish the SOC 3 if appropriate, describing it as the public summary of the examination, not detailed proof of how controls operated. The person approving that publication should verify the covered period and avoid suggesting that omitted exceptions were independently reviewed by public readers.
A renewal audit. When the external auditor requests evidence of operating effectiveness during the year, provide the full SOC 2 Type II. Ask the auditor to identify period gaps and exceptions requiring further evidence rather than assuming the report settles the matter.
Integration adds another question: which provider controls each handoff? Our third-party integration discussion is relevant when records move between the platform, payment services, and other systems.
At CEFCore, our controls are designed to meet or exceed SOC 2 Type II Trust Service Criteria for Security, Availability, and Confidentiality; AICPA Generally Accepted Privacy Principles; NIST CSF 2.0; GDPR and CCPA requirements; and IRS Publication 1075. Design alignment is not a completed independent examination.
SOC 3 isn't a separate certification or a cheaper substitute for detailed assurance. Give each stakeholder the evidence their decision requires, and expect follow-up questions.
How to Request and Check a SOC Report
Assign the review to a finance owner working with IT, compliance, and the external auditor. Keep a written record of findings rather than collecting documents without reaching a conclusion.
Microsoft's guidance on SOC 3 reports supports using the detailed Type II report for vendor-risk review and checking scope, exceptions, customer responsibilities, and subservice organizations.
Work through the evidence
Request the complete SOC 2 Type II report under confidentiality terms. Don't accept only a SOC 3 for production-vendor approval. Establish who may review the restricted material and where it will be stored.
Confirm the dates and auditor. Record the examination period, service auditor's name, and opinion date. These establish whose work you're relying on and when the examined controls operated.
Read the exceptions alongside the opinion. Assess each deviation's cause, affected systems, and remediation. A favorable overall opinion doesn't make an exception irrelevant to your fund.
Check the included criteria. Confirm whether availability, processing integrity, confidentiality, and privacy were examined rather than assuming their inclusion. Connect omissions to the fund's own risk assessment.
Assign complementary user-entity controls. These are controls the report expects the customer to perform. Give named fund employees responsibility for tasks such as approving access, removing departed users, and reconciling transactions.
Examine subservice-organization treatment. Identify how hosting providers and payment processors are addressed, including whether their controls are included or excluded. Determine what separate evidence is needed for excluded services.
Map scope to production data flows. Trace loan records, investor notes, general ledger entries, ACH, and reporting through the covered system. Include backups, subprocessors, and scheduled jobs, not just the application staff see.
Request a bridge letter through the current date. Use management's statement to understand changes or incidents after the report period ended. It doesn't extend the auditor's testing or replace a subsequent examination.
Close the documentation gaps
Use our SOC 2 audit checklist to organize ownership and evidence. For a payment-focused perspective, compliance documentation with MCA Pay can help frame additional documentation questions without replacing the auditor's report.
We assess all third-party vendors and service providers before integration, including review of their SOC 2 reports, security policies, and data handling practices. Apply that same discipline to every service connecting to the fund's records.
Send a written request this week for the full report, supporting documents, and the most recent security assessment summary, stating the date or period it covers. Our customers may request that summary by contacting security@cefcore.com.
Confirm the Report Before You Approve the Vendor
Approve a production vendor only after the full SOC 2 Type II has been reviewed against the fund's actual data flows, or document an explicit, limited exception to that standard. The approval memo should record the examination period, covered services, material exceptions, customer responsibilities, and unresolved questions.
Ask every vendor to state its current audit status in writing. Ready describes preparation, not a completed examination. A planned engagement, an engagement underway, and an issued report are different conditions and should appear differently in the board record.
Apply the same standard to our platform
CEFCore's infrastructure is described as SOC 2 Type II ready. Our controls are designed to meet the relevant criteria, but an independent audit engagement for SOC 2 Type II compliance validation is planned and not yet in place.
We make a summary of our most recent security assessment available on request. That summary should be evaluated for what it is, not presented as an independently issued SOC 2 Type II report.
Approval discipline: Record the evidence you have, the evidence you lack, and who has authority to accept the remaining risk.
Extend that discipline beyond software. The Beyond Surplus guidance on ITAD partners offers a related perspective on reviewing information technology asset disposition providers, another point where sensitive records can leave the fund's direct control.
Send this written question before the next approval meeting: What is the current audit status of your SOC 2 Type II examination, which period will it cover, and when will the full report be available to us?
Choose and document the decision:
- Approve: The required evidence supports the proposed production use, with responsibilities assigned.
- Approve with conditions: Limit use, data access, or implementation until named gaps are resolved, with an accountable owner and review date.
- Defer: Wait until the full report is in hand when missing assurance prevents a defensible decision.
The ministry mission deserves reliable systems and candid governance. Don't let implementation pressure turn an unanswered control question into an undocumented assumption.
CEFCore offers financial management software purpose-built for church extension funds, bringing loan management, investor notes, general ledger, cash operations, and reporting together. Visit CEFCore to evaluate that fit, and request our current security assessment summary and written audit status as part of your fund's diligence.
