Fintech startups usually meet SOC 2 as a sales question: a bank, payments partner or larger customer asks for the report before it will complete a security review. The request sounds like a single badge. It is better understood as an examination of a defined system, the controls around it and the period or point in time covered by the report.
That distinction matters. A report can be useful evidence, but it does not declare every product, workflow or vendor in the company safe.
What SOC 2 examines
The American Institute of CPAs describes a SOC 2 engagement as an examination of a service organisation’s system and controls relevant to security, availability, processing integrity, confidentiality or privacy. Those five areas come from the AICPA’s Trust Services Criteria.
The system description is therefore central. It tells a reader which services, infrastructure, people, procedures and data are inside the boundary. If the product has several environments, acquired systems or regional stacks, the report may not cover all of them. A prospective customer should match the report’s stated system to the service it plans to buy.
This is why “SOC 2 compliant” is an imprecise shortcut. The useful questions are narrower: What system was examined? Which criteria were in scope? What dates does the report cover? What did the service auditor test, and what exceptions did the report identify?
The five criteria are not five interchangeable badges
Security concerns protection against unauthorised access, use or disclosure. Availability concerns whether the system is available for operation and use as committed or agreed. Processing integrity concerns whether system processing is complete, valid, accurate, timely and authorised. Confidentiality concerns information designated as confidential. Privacy concerns personal information and how it is collected, used, retained, disclosed and disposed of.
The criteria overlap in practice, but they answer different customer risks. A payments API may need to explain not only access controls but also how it detects incomplete or duplicate processing. A lending-data platform may face detailed confidentiality and privacy questions. An infrastructure provider may be pressed on availability commitments and recovery procedures.
The correct scope follows the service and its commitments. Adding categories for appearance alone creates more evidence to maintain without necessarily answering the buyer’s actual question.
Start with the boundary, not the evidence folder
A weak SOC 2 project begins by collecting screenshots from every tool. A stronger one begins by drawing the service boundary and the data flow.
For a fintech startup, that map should identify:
- the production services that receive, transform or store customer data;
- identity providers and privileged administration paths;
- payment processors, cloud platforms and other important subservice organisations;
- deployment, change-management and incident-response workflows;
- customer responsibilities that the controls assume; and
- systems that are deliberately out of scope.
The boundary also exposes awkward seams. A security policy may cover employees but not contractors. A production database may be backed up while an analytics store is not. An access review may include the cloud console but omit a vendor dashboard with customer information.
Those are operational gaps, not documentation gaps. The aim is to make the real control environment coherent before an auditor tests it.
Controls need an owner and a repeatable record
A control should describe who performs an action, when it happens, what evidence remains and what happens when the expected result is missing. “We review access” is not enough. A useful design identifies the population of accounts, the reviewer, the frequency, the approval or removal decision and the retained record.
Common control areas include user access, privileged access, software changes, vulnerability handling, incident response, vendor risk, backups and restoration, business continuity and security monitoring. The exact set depends on the system and criteria.
Automation can reduce manual work, but it does not remove responsibility. A tool may gather a cloud configuration or a list of users. Someone still has to decide whether the population is complete, investigate exceptions and preserve evidence that explains the decision.
The same discipline applies to credentials used by payment systems. Our guide to payment API authentication explains why API keys, OAuth tokens and mutual TLS certificates need different scoping, rotation and recovery controls.
What customers should read in the report
Security questionnaires often ask only whether a SOC 2 report exists. Procurement and risk teams can learn more by reading it as a scoped piece of assurance.
Check the service auditor’s opinion, the system description, the criteria in scope, the period or date covered, the tests described and any exceptions. Look for complementary user-entity controls: these are controls the service expects the customer to operate. Also check how important vendors are treated in the description, because outsourced infrastructure does not make the underlying dependency disappear.
A report can age. A customer may ask for a bridge letter or other current information when the report period ended months ago. That request is not proof that the earlier report was defective; it reflects a gap between the examination period and today’s service.
A practical sequence for a fintech startup
First, confirm why the report is being requested and which product or customers it needs to support. Second, define the system and applicable criteria with the CPA firm that will perform the engagement. Third, compare the real environment with the proposed controls. Fourth, repair operational gaps and run the controls consistently. Fifth, retain evidence as part of ordinary work instead of assembling it at the end.
That sequence makes SOC 2 a by-product of a better-controlled service. It also gives sales and security teams a more accurate answer than a logo: a report with a clear scope, current period and controls that can be explained.
