A Clean SOC Report Is Not a Clean Bill of Health

A practical guide for community-bank and credit-union leaders on testing SOC report scope, exceptions, subcontractor coverage, customer-performed controls, and post-period chang...

The vendor sent the SOC report. The opinion looks clean. The renewal packet gets a green checkmark.

Everyone exhales.

That is usually the moment when the review should get more interesting.

A System and Organization Controls report can be valuable evidence about a service provider’s controls. It can also be treated like a magic permission slip that says, “A CPA looked at this, so we are done.”

We are not done.

For a community bank or credit union, the useful question is not whether the vendor has a SOC report. The useful question is whether the report covers the service, systems, dates, locations, subcontractors, and controls the institution actually relies on.

That makes the SOC review a technology-governance decision, especially before an exam, vendor renewal, major implementation, or risk committee meeting.

The board does not need to become an audit shop. Senior leaders do not need to memorize trust services criteria over breakfast. But they should expect management to explain what the report proves, what it does not prove, and what the institution still owns.

A clean opinion is a starting point.

The cover page is not the control environment

A SOC report is not one generic product.

Scope matters. Period matters. System boundaries matter. The difference between a Type 1 report and a Type 2 report matters. Carved-out subservice organizations matter. Exceptions matter. Management’s description of the system matters. So do the controls the service organization assumes its customers will perform.

That last category is where a reassuring report can become a very awkward exam conversation.

A core provider may assume the institution reviews privileged access. A cloud service may assume the institution configures identity controls correctly. A payments platform may assume the institution maintains dual control and reviews exception reports. A managed service provider may assume the institution promptly removes terminated users.

The vendor can perform its controls exactly as described while the bank or credit union leaves its part undone.

Both statements can be true:

1. The service provider’s controls operated effectively. 2. The institution’s overall process still has a serious gap.

That is why “clean SOC report” should never be translated into “low risk” without reading the rest of the sentence.

Example one: the interagency guidance says relevance must be tested

The Federal Reserve, FDIC, and OCC issued final interagency guidance on third-party risk management in 2023. The guidance says banking organizations may consider SOC reports and other independent assessments during due diligence. It also says they should consider whether the scope and results are relevant to the activity being performed and whether additional scrutiny of the third party or its contractors is appropriate.

Source: Board of Governors of the Federal Reserve System, “SR 23-4: Interagency Guidance on Third-Party Relationships: Risk Management,” June 7, 2023: https://www.federalreserve.gov/supervisionreg/srletters/SR2304.htm

That is a much higher standard than checking whether a PDF exists.

Imagine a credit union renewing a digital banking platform. The vendor provides a current SOC 2 Type 2 report. Good. But the report covers the vendor’s primary hosting environment, while the mobile deposit feature relies on another service provider. The report uses the carve-out method for that subservice organization, so those controls are outside the auditor’s testing.

The institution’s exposure did not disappear. It moved into the scope note.

Management now needs other evidence. That may include the subservice organization’s report, contract language, monitoring results, incident history, architecture details, or a documented risk decision.

The report did its job. The review failed if nobody noticed what was outside it.

Example two: AICPA describes assurance, not outsourced accountability

The AICPA describes its SOC suite as services that CPAs may provide regarding system-level controls at a service organization or entity-level controls at another organization. It says these assurance reports give users information needed to assess and address risks associated with outsourcing.

Source: AICPA & CIMA, “System and Organization Controls: SOC Suite of Services”: https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services

Notice the verbs: assess and address.

The report supplies evidence. The institution still has to interpret it and act.

A practical review should trace the report into the actual service relationship:

• Is the legal entity in the report the same entity named in the contract?
• Does the system description include the product and modules we use?
• Does the review period cover the time we are relying on?
• Were any locations, data centers, processes, or subcontractors excluded?
• What testing exceptions appeared, and did management’s response resolve the concern?
• Which customer controls apply to us, and who owns each one?
• What happened between the report period and today?

That last question is why a bridge letter can matter. A report covering last year does not automatically explain a merger, platform migration, control failure, material incident, or architecture change that happened last month.

Time moves forward even when the audit PDF does not. Very inconsiderate of it.

Example three: Capital One showed that provider controls do not replace bank controls

In 2020, the OCC assessed an $80 million civil money penalty against Capital One. The OCC said the bank failed to establish effective risk-assessment processes before migrating significant information technology operations to the public cloud and failed to correct deficiencies in a timely manner.

Source: Office of the Comptroller of the Currency, “OCC Assesses $80 Million Civil Money Penalty Against Capital One,” August 6, 2020: https://www.occ.gov/news-issuances/news-releases/2020/nr-occ-2020-101.html

Capital One is not a community bank, and this was not a case about a reviewer missing one line in a SOC report. The scale and facts are different.

The governance lesson still fits.

A service provider can have mature controls while a financial institution has weak risk assessment, poor configuration, unclear ownership, or slow remediation around its use of that service. Assurance over the provider does not certify every customer deployment.

This matters for community institutions because they often depend heavily on third parties and have smaller teams available to challenge the details. That does not make the challenge less important. It makes prioritization more important.

Management should spend its limited review time where the institution’s responsibility meets the vendor’s boundary: identity configuration, data movement, administrative access, interfaces, exception handling, recovery, subcontractors, and customer-performed controls.

That seam is where two individually reasonable control stories can fail to connect.

What should be in the review packet

A useful SOC review packet does not need to reproduce 200 pages for the board. Please do not turn a risk committee meeting into a competitive reading event.

Give leadership five exhibits.

Name the legal entity, product, modules, infrastructure, locations, report type, review period, and relevant control criteria. Show what is included and excluded.

Summarize testing exceptions, management responses, unresolved items, significant incidents, acquisitions, migrations, and material changes since the report period.

3. Subservice organization map

List the important subcontractors and show whether their controls were included, carved out, or supported by separate evidence.

4. Customer-control register

Translate every relevant customer responsibility into a named internal control, owner, evidence source, review frequency, and current status. “IT handles it” is not an owner.

5. Residual-risk decision

State what evidence is missing, what compensating controls exist, what remediation is required, and who can accept the remaining risk. Give open items dates, not adjectives.

This turns the SOC report from a document-management exercise into a control conversation.

The board needs the gap, not the glossary

Most directors do not need a lesson on audit terminology. They need a clear view of reliance.

What service do we depend on? What did the independent review cover? What was outside scope? What must our institution do? Where is the evidence that we did it? What risk remains before renewal, launch, or exam?

Those questions are understandable without diluting the substance.

A clean SOC opinion can be good news. It just is not the whole news.

The governance work begins where the report ends.

Board and executive discussion questions

1. For our most critical technology provider, what important service, subcontractor, period, or control sits outside the current SOC report’s scope? 2. Which customer-performed controls does the vendor assume we operate, who owns each one, and what evidence proves they are working? 3. What material change, exception, or incident occurred after the report period, and what additional assurance do we need before the next renewal, launch, or exam?