How client accounts fit into your agency's SOC 2 audit and client security reviews

An agency’s clients hand it their social, ad and store accounts, and its staff do the work inside them. So when a client reviews your security, or when a CPA examines your controls for a SOC 2 report, those accounts come up. Expect to show five things: which client accounts you hold, who can use each one, who used it and when, when each person’s access ended, and what your contracts promise.

Why client accounts come up

The AICPA describes a SOC 2 engagement as an “examination of a service organization’s description of its system and its controls”. Its guide notes that customers often ask a service organization for its SOC 2 report. The AICPA guide’s title lists the areas a report can be relevant to: “Security, Availability, Processing Integrity, Confidentiality, or Privacy”.

Clients also have their own reasons to check you. The NIST Cybersecurity Framework (CSF) 2.0 lists due diligence before formal supplier relationships as an outcome (GV.SC-06), along with monitoring what outside service providers do (DE.CM-06). The California Consumer Privacy Act (CCPA) covers for-profit companies doing business in California that meet at least one of its thresholds. One is annual gross revenue over $25 million, adjusted for inflation (Cal. Civ. Code 1798.140(d)). If your client is covered, its contract with you as a service provider must give it rights to check. It must be able “to take reasonable and appropriate steps to help ensure” that you use the data the way the CCPA requires (1798.100(d)(3)).

Where client accounts sit in a SOC 2 report

The AICPA’s sample SOC 2 Type 2 report has four parts: management’s assertion, the system description, the auditor’s report, and the auditor’s tests of controls with their results. The system description follows the AICPA’s description criteria, known as DC 200. The AICPA calls these criteria benchmarks for preparing and evaluating the description.

If your service is running clients’ accounts, access to those accounts is part of how you deliver the service. So it can come up in two parts of the report: the description of your system, and the controls over who gets in and how access is taken back. Whether the description includes this work is worth settling early. Ask your auditor how they will treat it. Clients can ask about these accounts whether or not they end up in the report.

Some clients ask for ISO/IEC 27001 instead. ISO describes it as the requirements an information security management system must meet. That system is the way a company runs security as a whole. Whichever standard the client names, its questions about its own accounts come down to the same records: who can get in, who used each account, and when access ended.

What to show, account by account

Keep one list of the client accounts you hold: client, platform, account, how you get in, and the person responsible for it. The table maps each piece of evidence to the question it answers and the CSF 2.0 outcome behind it. The mapping is this article’s own reading of the CSF wording, not an official crosswalk.

For the last row, the CCPA adds a duty. A service provider that brings in another person to help process personal information it handles for the client must notify the client. It must also bind that person by written contract (1798.140(ag)(2)).

How the access method changes what you can show

The way your staff get into each account decides which rows are easy to fill. With a shared login, the rows on when access ended and who used each account are hard. Taking someone off your list doesn’t stop them, because they still know the password until the client changes it. And the platform’s history shows the login, not the person, so you can’t say who did what without a separate work log. For each shared login that remains, add two notes to the list: who knows the password, and the date you last changed it after someone left.

With delegated access, the client invites each of your staff by name. The platform’s own user list shows who can get in, and its history shows each person, as far as the platform keeps one. An access tool that signs staff in without showing them the password works the same way. Its list of who may use each account and its per-person sign-in record fill those same rows.

A Type 2 report includes the auditor’s tests of your controls and their results. A list rebuilt the week before the audit can’t show who had access, or when it ended, in the months before. So update the list and the records every time staff change. For reporting your work to clients from the same records, see Reporting your work in client accounts to the client.