Say you're the controller at a church extension fund managing about $180 million in church loans and investor notes. Your auditor asks for evidence that every note-rate change received approval. The rates are in the servicing system, approvals are scattered through email, and the employee who maintained the spreadsheet has retired. You don't need another dashboard. You need a defensible record connecting each change to the person authorized to approve it.
What SOC 2 Software Does for a Church Extension Fund
SOC 2 compliance software organizes the evidence behind your controls. It can collect access records, connect approvals to transactions, track exceptions, and prepare material for an independent examination. It doesn't replace the operational judgment needed to decide who should change a note rate or approve a church construction draw.
SOC 2 is an independent CPA examination of a service organization's controls against applicable Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. The software is the evidence-management tool. The CPA's report contains the opinion.
As described in the arc42 SOC 2 framework overview, the American Institute of Certified Public Accountants introduced SOC 2 in 2011 as a successor to SAS 70 for technology and cloud-service organizations, then revised the criteria in 2017 to align with the COSO 2013 internal-control framework. The AICPA refreshed the Points of Focus in 2022 to address evolving technologies, cloud environments, and supply-chain risks.
Practical rule: Software cannot make an ineffective control effective. It can record whether the control operated and help staff identify where it failed.
For the controller handling that note-rate request, a useful system connects the previous rate, replacement rate, effective date, requesting employee, approving officer, and resulting posting. A folder full of screenshots doesn't establish that connection unless someone reconstructs it.
Start with the fund's money movements
CEFs accept investor funds to finance church construction, renovation, land purchases, and refinancing. Protecting those relationships requires controls over both information and financial processing.
Before choosing software, management should answer:
- Which criteria apply? Match the examination to commitments made to investors, borrowers, and the board.
- Which controls carry the most risk? Prioritize unauthorized payments, incorrect accruals, inappropriate access, and unresolved reconciliation differences.
- Which report should the board require? Decide what evidence of ongoing operation is necessary before relying on a provider.
The Controls Your Software Must Evidence
Core control areas and the evidence software should produce
The following is a practical control specification, not a universal SOC 2 checklist. The cadences and deadlines shown are examples a fund can adopt after assessing its risks.
| Control area | What the auditor tests | Evidence the software should produce | Fund example |
|---|---|---|---|
| Access controls | Who can view or change loan and investor records | Role assignments, access review exports, deprovisioning dates | Loan officer access removed within one business day |
| Audit trails | Whether changes are attributable and unaltered | Time-stamped, user-attributed, immutable change logs | Note rate change recorded with user and prior value |
| Log management | Whether security-relevant events are captured and retained | Centralized logs for logins, privilege changes and exports | Failed logins and ACH file exports kept for the review period |
| Change management | Whether system changes are tested and approved before release | Ticket, test result and approver for each release | Interest accrual logic change approved before production |
| Maker-checker approvals | Whether payments and postings need a second person | Approval records linking maker, checker and amount | Investor payout released by a second authorized officer |
| Evidence collection | Whether control evidence is complete and reproducible | Scheduled exports with owner, frequency and retention period | Quarterly access review export filed by the controller |
| Reconciliation | Whether subledgers tie to the general ledger | Tie-out reports, exception logs and sign-off | Note subledger variance reviewed monthly |
| Backup and recovery | Whether availability commitments are achievable | Backup logs and restore test results | Quarterly restore test of loan servicing data |
| Encryption and transmission | Whether data is protected at rest and in transit | Encryption configuration and TLS enforcement records | TLS enforced on all borrower and investor connections |
| Vendor management | Whether subservice providers are assessed | Vendor SOC reports, review dates and exception notes | Hosting provider's SOC 2 report reviewed annually |
Access controls establish who may act. Audit trails establish who did act, and log management preserves security events surrounding that activity. Require time-stamped, user-attributed, unalterable records, with prior values for financial changes, rather than a screen showing only today's balance. Our guide to audit trail requirements provides a useful evaluation reference.
Change management protects the calculation before release; maker-checker approval protects the transaction before release. These aren't interchangeable. Correct interest logic won't prevent an employee from sending an unauthorized payout.
Check completeness, not just availability
Scheduled evidence collection should have a named owner, collection frequency, and retention period. Reconciliation evidence must include unresolved differences and their disposition, not merely a successful export. Backup evidence should demonstrate restoration, while encryption evidence should establish protection both in storage and during transmission.
Vendor management completes the chain by documenting the services your provider depends on. Keep the review decision alongside the vendor report so a board member can understand what management accepted.
During a demonstration, ask:
- Native records: Which rows does the product log without staff intervention?
- Manual work: Which require exports, spreadsheets, or evidence from another provider?
- Failure handling: Who receives notice when an export fails or an approval is bypassed?
Choosing the Trust Criteria That Fit Your Fund
Security is the only required SOC 2 category. The others should reflect the organization's commitments and system risks, rather than a preference for a longer report, as explained through the AICPA's SOC 2 description-criteria guidance.
Availability concerns whether services are usable when promised. Tie it to borrower payment access, investor account access, and the operational windows required to process transactions.
Processing integrity concerns complete, accurate, timely, authorized processing. For a fund promising accurate quarterly investor statements, it deserves serious consideration because interest accrual, amortization, Automated Clearing House (ACH) payments, and statement generation all affect the promise.
Distinguish sensitive information from personal information
Confidentiality addresses protection of information designated confidential, including borrower financial records and investor account information. Privacy addresses the collection, use, retention, disclosure, and disposal of personal information, including personally identifiable information used in tax reporting.
A fund holding no borrower personal information might consider excluding Privacy, but that fact alone isn't enough. Management must also assess investor, employee, and other personal information within the system boundary.
For broader context when comparing frameworks, Vigil Security's guide to security frameworks is a useful companion. The fund's actual commitments should still determine its SOC 2 scope.
Use this decision sequence:
- List commitments. Include statement accuracy, payment authorization, service availability, and information protection.
- Map processes to systems. Follow each commitment through origination, servicing, notes, general ledger, and reporting.
- Select applicable criteria. Identify which risks require supporting controls and testing.
- Document exclusions. Write a short rationale for every category left outside scope.
An automated check can confirm that an approval setting exists. It cannot, by itself, establish that staff properly investigated an unusual transaction.
The criteria memo should identify the service, system boundary, data types, commitments, selected categories, exclusions, and approving management. Include the reason for each exclusion and the circumstances that would trigger reconsideration.
Type 1 Versus Type 2 Reports and What They Prove
Type 1 and Type 2 reports compared on board questions
| Question | Type 1 report | Type 2 report |
|---|---|---|
| Point in time or period | Controls designed and implemented at a specified date | Controls tested over a stated review period |
| Operating effectiveness | Not tested | Tested through sampling across the review period |
| Exceptions | Not reported as operating failures | Exceptions reported with management responses |
| Typical use | Early readiness or first-time vendor onboarding | Ongoing vendor oversight and reliance by auditors |
| Question for the board | Is the design adequate for the risks the fund accepts? | Did controls work across the full period, and what were the exceptions? |
The AICPA's SOC 2 reporting resources distinguish a Type 1 examination of control design and implementation at a specified date from a Type 2 examination that also addresses operating effectiveness over a stated period. That distinction matters more than a vendor's compliance badge.
A Type 1 report is a snapshot. It doesn't establish that an access review occurred consistently or that payment approvals worked during the fund's busiest processing periods.
Read beyond the report title
A Type 2 report supports a different question: did the controls operate during the period examined? Read the testing results and exceptions, not just the opinion page. An exception affecting privileged access or payment authorization deserves an explanation of exposure, corrective action, and any additional controls the fund must operate.
When the reporting period ends before the fund's current review date, request a bridge letter addressing the intervening interval. It's a management representation, not an extension of the CPA's testing, so assess the length of the gap and any reported changes.
The board should require management to confirm:
- Report type: The provider has supplied a Type 2 report, not a readiness statement.
- Relevant period: The review includes the operational cycles on which the fund relies.
- Actual scope: The named applications and services match what the fund uses.
For a critical provider, Type 2 should be the default expectation. I would accept Type 1 only as a documented transitional exception for a new service or provider, with compensating controls, an accountable sponsor, and an agreed path to Type 2 reporting. Convenience alone isn't a sufficient reason.
How to Test a Vendor Against Your Controls
Begin with the fund's processes, not the provider's integration list. A report is useful only to the extent that its scope and tested controls support the services you're buying.
Map the money movements. Connect loan funding, accruals, ACH payments, and investor statements to the selected criteria. Identify where a failure could change an amount, recipient, effective date, or reported balance.
Confirm the product boundary. Obtain the report and reconcile its system description to every module and integration you intend to use. A clean opinion for another product doesn't establish coverage for yours.
Read exceptions in full. Require the management response and determine whether the affected control supports your operation. If it does, record the compensating control or remediation needed before reliance.
Examine downstream providers. Confirm how hosting, payment, and other subservice providers are assessed and which responsibilities remain outside the report. In our vendor program, all third-party vendors and service providers undergo security assessment before integration, including review of their SOC 2 reports, security policies, and data handling practices.
Assign the evidence workflow. Record an owner, source, frequency, retention period, and escalation path for each control. NIST SP 800-53 Revision 5 describes continuous monitoring through defined metrics, scheduled assessments, analysis, documented responses, and recurring reporting, a stronger model than an audit-season upload exercise.
Inspect actual exports. Request an audit trail sample and access review report before signing, then inspect timestamps, user attribution, and prior values. Use a structured control-testing approach to determine whether records demonstrate the control rather than merely describe it.
Test confidentiality and governance fit. Ask how investor and borrower information is restricted, exported, and retained. Confirm that management can produce appropriate evidence for board oversight and denominational reporting without distributing unnecessary personal information.
Separate readiness from independent validation
SOC 2 ready isn't a completed independent examination. Our independent audit engagement for SOC 2 Type II compliance validation is planned and not yet in place. Customers may request a summary of our most recent security assessment results by contacting security@cefcore.com.
Before go-live, retain the available report or explicitly approved assurance exception, written scope confirmation, sample exports, and an owner for each evidence stream.
Acceptance standard: If the provider cannot supply the evidence, record the gap before implementation rather than leaving staff to discover it during fieldwork.
Mapping SOC 2 Evidence to FFIEC Examination Areas
CEFs generally aren't examined under Federal Financial Institutions Examination Council (FFIEC) rules. Nevertheless, the FFIEC IT Examination Handbook can provide a useful benchmark for organizational risk management and board reporting. Treat the mapping below as a planning aid, not a declaration that SOC 2 satisfies FFIEC expectations.
FFIEC examination areas mapped to SOC 2 evidence
| FFIEC area | What examiners look for | SOC 2 evidence to keep | Criteria supported |
|---|---|---|---|
| Information Security | Access controls, encryption and monitoring | Access review exports, encryption configuration, alert logs | Security, Confidentiality |
| Management | Governance, risk assessment and vendor oversight | Risk register, vendor report reviews, board minutes | Security, Privacy |
| Business Continuity | Recovery planning and tested backups | Backup logs, restore test results, incident drill records | Availability |
| Audit | Independent testing and tracking of issues | Type 2 report, exception remediation log | All in-scope criteria |
| Development, Acquisition and Maintenance | Change control and vendor selection | Change tickets, test approvals, vendor assessments | Security, Processing Integrity |
| Support and Delivery | Service levels, incident and problem management | Incident tickets, uptime records, service reports | Availability, Processing Integrity |
Our FFIEC IT Handbook guide offers context for using these areas in a fund's oversight program. The mapping doesn't replace state securities obligations, IRS reporting responsibilities, or accounting policies prepared under generally accepted accounting principles (GAAP).
Read the gaps as management decisions
A row with extensive evidence but no accountable owner is a governance gap. A row without evidence describes a control the fund cannot demonstrate, even if employees believe the work occurs.
Say a small fund can produce quarterly access reviews and restore-test results but has no vendor review records. It doesn't need to rebuild its security program first. The controller can inventory critical providers, assign reviewers, obtain available assurance documents, and record acceptance decisions and follow-up actions.
Store evidence once with cross-references to relevant controls and examination areas. Duplicating the same report across folders makes version control harder and creates opportunities for reviewers to reach different conclusions.
For a lean team, I would check these areas first rather than assume they're complete:
- Management: Close undocumented vendor oversight with a review register and approval record.
- Business Continuity: Replace confidence in backups with documented restoration results and follow-up.
- Audit: Give every open finding an owner, corrective action, and closure evidence.
The board doesn't need every technical log. It needs a clear account of unresolved exposure, responsible management, and decisions requiring its authority.
Where a Platform Like CEFCore Fits Alongside Your Controls
A financial platform that processes loan records, investor account information, general ledger transactions, personally identifiable information (PII), and tax reporting data belongs in the fund's system inventory. When those services fall within the examination boundary, the scope memo should name the platform and identify the information it handles.
CEFCore should face the same evaluation as any other provider. 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. Those are control-design objectives, not a substitute for an independent auditor's opinion or a determination of which legal requirements apply to your fund.
Divide platform evidence from fund responsibility
During evaluation, identify which role records, audit logs, approval records, and archive exports the platform provides natively. Confirm which require configuration, manual export, or evidence from an integrated service. Request the current assurance documentation, system description, and disclosed findings, then distinguish independently tested claims from design statements.
Our platform supports single sign-on through OpenID Connect and SAML 2.0, with an application programming interface (API) for custom integrations. Those connections should have documented ownership because identity permissions and transferred data can extend beyond the core application's boundary.
The fund still owns:
- Policies and authority: Define permitted actions, approval limits, and segregation of duties.
- Review work: Complete access reviews and investigate exceptions rather than merely collecting reports.
- Governance: Approve scope decisions, assess residual risk, and report material issues to the board.
- Accounting and reporting: Validate financial outputs and maintain the controls supporting regulatory and tax submissions.
A connected platform can reduce evidence effort and eliminate some manual handoffs. It cannot decide whether an unusual investor redemption is appropriate, whether a reconciliation difference is acceptable, or whether management has met its responsibilities. Software supports the controls; accountable people operate them.
Confirm Scope and AI Exposure Before Your Next Audit
Make the next audit preparation cycle a set of owned decisions rather than a general request to improve compliance. The immediate priorities are scope approval, current vendor assurance, and visibility into artificial intelligence (AI) tools that can reach financial information.
Bright Defense's SOC 2 reporting cites findings that 69% of surveyed security and compliance leaders believed AI adoption was outpacing their organizations' ability to maintain controls, 53% identified evidence collection across multiple tools as an audit bottleneck, and 91% had to resubmit evidence at least sometimes. These findings aren't estimates of CEF performance, but they identify practical questions worth resolving before fieldwork.
Give each decision an owner
- Controller and board chair: Approve and date the criteria memo before fieldwork. Record each selected or excluded category, its rationale, and who must revisit the decision when services change.
- Controller: Obtain current SOC 2 reports for systems touching loan, investor, or borrower data. Record report type, review period, scope, and any bridge letter needed for an intervening gap.
- IT director: Inventory AI tools with access to that information, including features embedded in existing applications. Record permitted data, prompt and output logging, model-change approval, human review of generated reconciliations or classifications, and monitoring of third-party model providers.
An AI policy template isn't enough if staff can upload investor records to an unapproved tool. The inventory should distinguish authorized use from discovered use, with unresolved access questions assigned for action.
This coming week, have the IT director send the AI inventory to the audit committee, including unknowns, owners, and proposed restrictions. Give the committee something it can evaluate and act on.
CEFCore offers purpose-built financial management for church extension funds, bringing loan, investor, accounting, and reporting workflows together with compliance-support capabilities. Visit CEFCore to discuss your control requirements and request a demonstration focused on the records, approvals, and evidence your fund needs.
