SSAE 18, SOC 1 and SOC 2 Reports

Why This Topic Matters for the CTP Exam and for Treasury Practice

Modern treasury departments rarely operate in isolation. They outsource critical functions to banks, payment processors, lockbox providers, treasury management system (TMS) vendors, payroll services, custodians, cloud hosting providers and data aggregators. Every time treasury hands a process to a third party, it also hands over a portion of its control environment. The company remains accountable for the accuracy of its financial statements, the safety of its cash and the protection of its data, yet the controls that make those outcomes possible now sit inside someone else's organization.

This is where SSAE 18 and the SOC (System and Organization Controls) reports come in. They are the primary mechanism by which a user organization gains independent, auditor-verified assurance about the controls at a service organization. For a treasury professional, understanding these reports is essential to:

- Performing vendor due diligence and ongoing third-party risk management
- Supporting Sarbanes-Oxley (SOX) Section 404 compliance, because outsourced processes that affect financial reporting still fall within management's internal control assessment
- Managing operational risk, which the Basel framework defines as the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events
- Satisfying internal and external auditors who need evidence about controls they cannot test directly
- Protecting against fraud, payment errors, data breaches and service outages

The CTP exam places this material in the Financial Regulatory and Operational Risk domain. Questions tend to test whether you can distinguish the types of reports, understand who uses them and why, and recognize how treasury should act on the information they contain.

Background and Evolution: From SAS 70 to SSAE 16 to SSAE 18

For many years, the standard governing auditor reports on service organizations in the United States was SAS 70 (Statement on Auditing Standards No. 70), issued by the AICPA. SAS 70 reports became widely used, and often misused, as general-purpose proof that a vendor was secure or well controlled, even though SAS 70 was designed narrowly around controls relevant to financial reporting.

In 2011, the AICPA replaced SAS 70 with SSAE 16 (Statement on Standards for Attestation Engagements No. 16), moving the engagement from an auditing standard to an attestation standard and introducing the SOC report framework (SOC 1, SOC 2, SOC 3). SSAE 16 also required a written assertion from service organization management about the fairness of the system description and the suitability and effectiveness of controls.

Effective May 1, 2017, SSAE 18 superseded SSAE 16. SSAE 18 is a broad recodification of the AICPA attestation standards (the AT-C sections). SOC 1 engagements are now performed under AT-C Section 320, and SOC 2 engagements under AT-C Sections 105 and 205 using the Trust Services Criteria. The international equivalent of SOC 1 is ISAE 3402, issued by the IAASB.

Key enhancements introduced by SSAE 18 that are frequently examined include:

1. Subservice organization monitoring. The service organization must identify its own vendors (subservice organizations) whose controls are relevant and must describe how it monitors them. This pushes vendor risk management down the supply chain.
2. Complementary subservice organization controls (CSOCs). When a service organization carves out a subservice provider, the report must identify the controls the subservice organization is expected to have in place for the service organization's control objectives to be met.
3. Complementary user entity controls (CUECs). SSAE 18 sharpened the requirement that the report list controls the user entity itself must operate for the service organization's controls to be effective.
4. Risk assessment by the service auditor. The auditor must obtain a deeper understanding of the service organization and assess the risk of material misstatement in the description and assertion.
5. Stronger evidence requirements. The auditor must evaluate the reliability of information produced by the service organization that is used as audit evidence.

What Is a SOC Report?

A SOC report is the deliverable of an attestation engagement in which an independent CPA (the service auditor) examines and reports on controls at a service organization that are relevant to its customers, known as user entities. The report is intended to be used by user entities and their auditors (user auditors) so they do not each have to perform their own audit of the vendor. One service auditor report replaces potentially hundreds of individual customer audits.

Every SOC 1 or SOC 2 report contains several core components:

- The service auditor's opinion (the independent auditor's report), which may be unmodified (clean), qualified, adverse or a disclaimer
- Management's written assertion about the system description and controls
- Management's description of the system, including services, infrastructure, people, procedures, data and relevant control objectives or criteria
- The controls and (for Type 2) the tests of controls and results, including any exceptions noted
- Complementary user entity controls that the customer must have in place
- Identification of subservice organizations and whether they are treated under the carve-out or inclusive method
- Optional other information provided by the service organization, such as management responses to exceptions, which is not covered by the auditor's opinion

SOC 1 Reports: Controls Relevant to Financial Reporting

A SOC 1 report addresses controls at a service organization that are likely to be relevant to the user entities' internal control over financial reporting (ICFR). The service organization, not the auditor, defines the control objectives, which typically cover areas such as transaction authorization, completeness and accuracy of processing, timely recording, reconciliation, data security and change management as they affect financial data.

The intended users are the management of the user entity and, especially, the user entity's financial statement auditors, who rely on the report when planning and performing the audit. SOC 1 reports are restricted use documents; they are not to be distributed publicly.

Treasury examples where a SOC 1 is appropriate:

- A bank providing lockbox and remittance processing (affects cash and receivables balances)
- A payroll processor (affects compensation expense and liabilities)
- An ACH or wire origination service (affects cash disbursements)
- A treasury management system hosted by the vendor that calculates cash positions, accruals or debt schedules used in the ledger
- A trust company or custodian holding investment assets and reporting valuations
- A claims or benefits administrator processing payments on the company's behalf

SOC 2 Reports: Controls Over Security, Availability, Processing Integrity, Confidentiality and Privacy

A SOC 2 report addresses controls relevant to the Trust Services Criteria (TSC) established by the AICPA. There are five categories:

1. Security (also called the Common Criteria) - protection against unauthorized access, both physical and logical. Security is the only category that must be included in every SOC 2.
2. Availability - the system is available for operation and use as committed or agreed (uptime, disaster recovery, business continuity).
3. Processing Integrity - system processing is complete, valid, accurate, timely and authorized.
4. Confidentiality - information designated as confidential is protected as committed or agreed.
5. Privacy - personal information is collected, used, retained, disclosed and disposed of in conformity with the organization's privacy notice and generally accepted privacy principles.

Unlike SOC 1, where the service organization writes its own control objectives, a SOC 2 measures controls against the predefined AICPA criteria selected for the engagement. The report is intended for management of user entities, regulators, business partners and others with sufficient understanding of the system. It is still generally considered restricted use, though distribution is typically broader than a SOC 1 and is often provided under a non-disclosure agreement.

Treasury examples where a SOC 2 is the appropriate report:

- A cloud-based TMS or cash forecasting platform, where treasury cares about data security, uptime and accurate processing but the vendor does not directly produce ledger entries
- A bank connectivity or SWIFT service bureau transmitting payment files
- A data aggregation or API provider pulling bank balances into dashboards
- A document or signature management vendor storing bank account documentation and board resolutions
- A payment fraud screening tool processing sensitive vendor and account data

In practice, many critical treasury vendors provide both a SOC 1 and a SOC 2, because their services affect financial reporting and involve sensitive data and system availability.

SOC 3 Reports: The General-Use Summary

A SOC 3 report covers the same Trust Services Criteria as a SOC 2 but is a general-use report that can be freely distributed or posted on a website. It contains the auditor's opinion and management's assertion but omits the detailed description of controls, tests performed and results. It is useful for marketing and high-level assurance but is insufficient for detailed vendor due diligence, because a user cannot see which controls were tested or whether exceptions occurred.

Type 1 vs. Type 2: The Critical Distinction

Both SOC 1 and SOC 2 reports come in two types. This distinction is one of the most frequently tested concepts.

Type 1 reports on the fairness of the description of the system and the suitability of the design of controls to achieve the objectives or criteria as of a specified date (a point in time). The auditor confirms the controls exist and are appropriately designed and implemented, but does not test whether they operated effectively over time. Type 1 reports are often used by newer service organizations or as a first step before a Type 2.

Type 2 reports on the fairness of the description, the suitability of design and the operating effectiveness of controls throughout a specified period, typically six to twelve months. The auditor performs tests of controls and reports the results, including any exceptions. Type 2 is far more valuable to user entities and their auditors because it provides evidence that controls actually worked over time, which is what SOX 404 and operational risk management require.

A simple memory aid: Type 1 is a snapshot; Type 2 is a movie. Treasury and auditors almost always want the Type 2.

How Treasury Uses SOC Reports: The Review Process

Obtaining a SOC report is only the beginning. The CTP exam expects you to know what a competent treasury professional does with it. A structured review includes the following steps.

1. Confirm you have the right report. Is it SOC 1 or SOC 2? Type 1 or Type 2? Does the scope cover the specific services, locations and systems your company actually uses? A report on the vendor's retail payment platform does not help if you use its corporate treasury platform.

2. Check the period and the gap. Note the period covered by a Type 2 report. If the report period ends before your fiscal year end, request a bridge letter (also called a gap letter) in which the service organization's management represents that no material changes to controls occurred between the report end date and your year end. Bridge letters are management representations, not auditor opinions, and typically should not cover more than a few months.

3. Read the auditor's opinion. An unmodified opinion is the goal. A qualified opinion means one or more control objectives were not achieved or the description was not fairly presented in some respect. An adverse opinion or disclaimer is a serious red flag requiring escalation.

4. Analyze exceptions and deviations. Even with a clean opinion, individual tests may show exceptions. Evaluate each one: Does it affect a process you use? Did management respond? Is there a compensating control? Document your conclusion.

5. Map complementary user entity controls (CUECs). This is the step most often skipped and most often tested. The service organization's controls are designed on the assumption that the user entity performs certain controls, such as restricting system access to authorized employees, reviewing output reports, approving payment files before release, reconciling bank statements and promptly removing terminated users. If treasury does not actually perform these CUECs, the vendor's assurance is incomplete and the company's control environment has a gap.

6. Evaluate subservice organizations. Identify which vendors the service organization relies on (for example, a cloud hosting provider). If they are carved out, you may need to obtain their SOC reports separately or assess whether the service organization's monitoring controls over them are adequate. If they are included (inclusive method), their controls are covered in the report.

7. Assess the service auditor. Is the CPA firm independent and reputable? Is it subject to peer review?

8. Document and communicate. Record the review in the vendor risk file, share relevant findings with internal audit, the controller and IT security, and incorporate results into the annual vendor risk rating and contract renewal decisions.

9. Make it recurring. SOC reports should be obtained and reviewed annually for every critical vendor, and contracts should include a right to receive them.

SOC Reports in the Broader Risk and Compliance Framework

Sarbanes-Oxley. Under SOX Section 404, management must assess the effectiveness of ICFR, and the external auditor must opine on it for larger filers. Outsourcing does not transfer this responsibility. SOC 1 Type 2 reports are the standard evidence used to cover outsourced processes within the SOX assessment, which is why controllers and internal audit frequently coordinate with treasury on vendor SOC collection.

COSO. SOC reports are organized around the same control concepts as the COSO Internal Control - Integrated Framework: control environment, risk assessment, control activities, information and communication, and monitoring. Treasury's review of SOC reports is itself a monitoring activity under COSO.

Operational risk and business continuity. SOC 2 reports addressing Availability directly support treasury's business continuity planning for payment processing and liquidity management. Processing Integrity criteria support payment accuracy and fraud prevention objectives.

Regulatory expectations. Banking regulators and supervisors increasingly expect robust third-party risk management programs. While SOC reports are not legally mandated for most corporates, they are considered a baseline due diligence practice, and their absence would be difficult to defend to auditors, boards or regulators.

Limitations of SOC Reports

The exam may test your awareness that SOC reports are not a complete answer:

- They cover controls at the service organization, not the user entity's own controls (hence CUECs).
- A Type 1 says nothing about operating effectiveness.
- A SOC 3 lacks detail for meaningful analysis.
- The scope is defined by the service organization and may exclude services or locations you rely on.
- They are historical; a report covering last year does not guarantee controls are effective today.
- They do not evaluate the vendor's financial strength, contractual performance or strategic viability, which require separate due diligence.
- The auditor's opinion does not extend to the other information section or to management's bridge letter.

Exam Tips: Answering Questions on SSAE 18, SOC 1 and SOC 2 Reports

Tip 1: Anchor on the purpose to identify the report type. If the question mentions financial statements, ICFR, the user entity's external auditor, SOX 404 or control objectives defined by the service organization, the answer is SOC 1. If it mentions security, availability, processing integrity, confidentiality, privacy, Trust Services Criteria, cloud, data protection or uptime, the answer is SOC 2. If it mentions public distribution, website posting or a general-use seal, the answer is SOC 3.

Tip 2: Point in time vs. period of time. Any reference to as of a specific date, design only or implemented signals Type 1. Any reference to operating effectiveness, over a period, tests of controls or exceptions signals Type 2. When asked which report provides the most assurance or is most useful to auditors, choose Type 2.

Tip 3: Know the lineage. SAS 70 came first, SSAE 16 replaced it in 2011 and introduced SOC reports, and SSAE 18 replaced SSAE 16 effective 2017. If an answer choice refers to a current SAS 70 report, it is outdated and almost certainly a distractor. The international counterpart to SOC 1 is ISAE 3402.

Tip 4: Remember who does what. The service organization provides the service and prepares the description and assertion. The service auditor (independent CPA) tests and opines. The user entity is the customer, and the user auditor audits the customer. The service organization's management, not the auditor, writes the bridge letter.

Tip 5: CUECs are the user's job. Questions that describe a clean SOC report but a control failure at the company are usually testing complementary user entity controls. The correct response is that treasury must implement and operate the CUECs listed in the report; the vendor's clean opinion does not cover them.

Tip 6: Recognize SSAE 18 specifics. If a question asks what SSAE 18 added or emphasized, look for answers about subservice organization monitoring, complementary subservice organization controls, the service auditor's risk assessment and the written management assertion. The carve-out method excludes subservice controls from the report; the inclusive method includes them.

Tip 7: Bridge letters fill gaps, they do not replace reports. If the report period ends before fiscal year end, the correct action is to obtain a bridge letter. A bridge letter is a management representation, is not audited and is not a substitute for a new report.

Tip 8: A qualified opinion or exceptions require analysis, not automatic rejection. The best answer typically involves evaluating the impact of the exception on the services used, identifying compensating controls and documenting the conclusion, rather than immediately terminating the vendor or ignoring the finding.

Tip 9: SOC reports are one component of due diligence. If a question asks whether a SOC report alone is sufficient to approve a vendor, the answer is no. Financial stability, contract terms, business continuity testing, insurance, references and ongoing performance monitoring are also required.

Tip 10: Watch for absolutes and scope traps. Answer choices stating that a SOC report guarantees security, eliminates risk or covers all vendor services are almost always wrong. SOC reports provide reasonable assurance about controls within a defined scope and period.

Tip 11: Link to the broader risk domain. Expect questions that connect SOC reports to SOX compliance, COSO monitoring, operational risk, business continuity and third-party risk management. The right answer usually reflects that outsourcing shifts the performance of controls but not the accountability for them.

Quick Reference Summary

- SSAE 18: AICPA attestation standard, effective May 2017, replaced SSAE 16 (which replaced SAS 70). Governs SOC engagements. Added subservice organization monitoring, CSOCs and enhanced risk assessment.
- SOC 1: Controls relevant to user entities' financial reporting (ICFR). Control objectives set by service organization. Restricted use. Primary users: user management and user auditors. Supports SOX 404.
- SOC 2: Controls relevant to Security (required), Availability, Processing Integrity, Confidentiality, Privacy under AICPA Trust Services Criteria. Restricted use. Primary users: management, regulators, partners.
- SOC 3: General-use summary of SOC 2; no detailed tests or results.
- Type 1: Design and implementation as of a point in time.
- Type 2: Design and operating effectiveness over a period (usually 6-12 months); includes tests and results.
- CUECs: Controls the user entity must perform for the vendor's controls to be effective.
- Bridge letter: Management representation covering the gap between report period end and user's year end.
- Treasury action: Obtain annually, verify scope and period, read opinion, analyze exceptions, implement CUECs, assess subservice organizations, document and escalate.

Master these distinctions and the logic behind them, and you will be well prepared for any CTP question on SSAE 18 and SOC reporting within the Financial Regulatory and Operational Risk domain.