Reviewing an AI supplier with no SOC 2 report

SOC 2 belongs to the System and Organization Controls suite: assurance reports that CPA firms provide under standards the AICPA sets [1]. In a SOC 2 examination, a CPA firm reports on the supplier's description of its system and on its controls relevant to security, availability, processing integrity, confidentiality or privacy, measured against the AICPA's trust services criteria [2, 3]. Customers ask for one because they need to know how a supplier's system protects what they hand over [2].

How much a report is worth to you comes down to three details. Start with the type: in a type 2 examination the auditor reports on whether the controls were suitably designed and whether they operated effectively [4, 5], so ask which type you have been given and which dates it covers. Scope counts as much as type, because a report covers the system it describes and nothing else. Then look at who wrote it. The AICPA's own SOC page carries a notice that it is looking into anonymously published allegations about a compliance vendor that offers SOC services, and it tells service organizations and CPA firms to evaluate SOC services thoroughly [1]. Check the CPA firm the way you would check the supplier.

A SOC 3 report covers the same five areas in less detail, which is why the AICPA treats it as a general-use report that can be freely distributed [6]. It tells you an examination took place and what the auditor concluded. It does not show you which controls were tested.

A supplier without a SOC 2 report will sometimes offer an ISO/IEC 27001 certificate instead. They are different kinds of evidence. ISO/IEC 27001 sets the requirements for an information security management system, the way an organisation runs security as a whole [7]. A SOC 2 report is an opinion on the controls of one system. Neither contains the other.

My view: a current ISO/IEC 27001 certificate from an accredited body, with a scope that covers your work, is good evidence that a supplier runs security as a discipline. It will not show you whether a specific control operated effectively, which is what a type 2 report is for. And if your policy names SOC 2 because a regulator or a customer contract names it, a certificate does not change that. ISO notes that accreditation is not compulsory and that an unaccredited certification body is not necessarily disreputable [8], but its certificate is weaker evidence.

The question behind a SOC 2 requirement is whether a supplier can be trusted with your data. For an AI supplier the answer depends on where the work happens, so settle that before you choose the evidence. The table is my starting position for each case, not a rule. If the supplier's work will feed financial reporting at a company that reports to the SEC, its auditor will ask a separate question about service organisations, which our guide to SOX controls for AI in the finance close covers.

US banking regulators apply the same logic. The interagency guidance the Federal Reserve, the FDIC and the OCC published in June 2023 says due diligence should be tailored to the activity and scaled to its risk and complexity, and that where relevant and available a bank may consider SOC reports and independent certifications, checking whether their scope and results fit the activity [9]. The agencies state that supervisory guidance does not have the force and effect of law [9], and it is written for banks, but I have not seen a better model for any buyer.

This is the list I would send, roughly in this order. Each item is cheap for a serious supplier to produce, and a slow or vague answer is information too.

If your team works from a standard questionnaire, the Cloud Security Alliance publishes one, the CAIQ, as yes-or-no questions mapped to its Cloud Controls Matrix [10]. It was written for cloud providers, so cut what does not apply to a supplier working inside your accounts. Then add the AI questions a generic questionnaire misses: where prompts and outputs are stored and for how long, whether any provider may train on them, and what the system is allowed to do without a person approving it.

The banking guidance also covers the situation this page is about. When a bank cannot get the information it wants from a third party, it should document the limits of its due diligence and the risks they leave, then get other information, add controls or monitoring, or use a different third party [9]. That is a good shape for any exception, so write yours in those terms and give it a review date.

One requirement no evidence pack replaces. If the supplier will create, receive, maintain or transmit protected health information on behalf of a HIPAA covered entity, the covered entity may allow that only if it obtains satisfactory assurance that the supplier will appropriately safeguard the information. Where the supplier is a subcontractor of a business associate, such as a health-tech company serving covered entities, that business associate obtains the assurance instead. Either way, the assurance must be documented in a written contract or other written agreement or arrangement [12]. A SOC 2 report does not stand in for that agreement. This guide is not legal advice.

1AYM is not SOC 2 audited today, and we hold no ISO or SOC certification. We do not imply one. If your policy makes either a hard requirement, we are the wrong supplier for you, and a first call is a cheaper place to find that out than the end of a scoring round.

Most of our delivery work sits in the second row of the table above. We build in your repositories and your environments, so the systems we build run in your estate, under your controls. Our delivery engineers work under identities you issue, nothing we deliver depends on a system only 1AYM can reach, and a fixed-scope statement of work keeps our access as narrow as the scope. Much of that work is rolling out AI tools across a client's own teams, as in our AI platform enablement engagement. What we put in front of a reviewer is the control set, the evidence each control produces and the engineers who built them. You meet those engineers before you sign, we hold the relevant insurance, and US clients can contract through our US entity. Where the contract needs it, copyright in the deliverables is assigned to you.

Our AI governance implementation work is the other side of this guide: identity, verifier gates, evaluation in CI and audit trails built into the platform, so a reviewer can check what enforces a policy instead of reading about it. A small job runs as a fixed-scope statement of work, and the build can start within a day of the scope being signed. Larger work is a Production AI systems engagement: a fixed-scope architecture and production build.