When your SOC 2 auditor asks for more than the criteria require
Most oversized requests come from a template list, a description you wrote too broadly, or a system you never meant to include. Ask which criterion the request tests and whether it sits inside your agreed boundary. If neither answer holds up, the request comes off the list.
A SOC 2 request list for a small company runs to somewhere around eighty to a hundred and fifty items. Most of it is legitimate and some of it is not, and the difference is rarely obvious to a team going through its first audit. This page sorts the two, with the requests that come up most often in Canadian software companies, and gives the wording to raise the ones that should not be there.
Why do SOC 2 auditors over-request?
Not usually to pad the fee. The common causes are mundane:
- A template list. Firms start from a standard request list and prune it to your scope. When the pruning is rushed, items for criteria you did not elect or systems you do not run stay on.
- Your own description. If the system description says "all production data is encrypted with customer-managed keys" when only one database is, the auditor will ask for evidence of the sentence you wrote.
- Unclear boundary. Without a scope memo, an associate who sees a second AWS account or an internal admin tool reasonably asks about it.
- Staff turnover. A new associate on a renewal reads the scope afresh and asks for things the previous team had already agreed were out.
Every one of those is fixed by a conversation, not a dispute. The broader approach, including the scope memo that prevents most of them, is on managing your SOC 2 auditor.
Which requests are legitimate and which are not?
| Request | Usually | What to send instead, or why it stands |
|---|---|---|
| Full population of changes, hires, leavers or access reviews for the period | Legitimate | The auditor cannot sample without it. Send it first, from the system of record, with the export date visible. |
| Penetration test report | Legitimate | Supports monitoring and vulnerability management. Send the executive summary and remediation evidence; the full report under NDA if asked. |
| SOC 2 reports for your cloud provider and key vendors | Legitimate | Supports vendor oversight and complementary controls. Send the reports and your record of having reviewed them. |
| Board or management minutes | Legitimate | Supports governance and oversight. Send redacted excerpts showing security was discussed, not the whole board pack. |
| Export of a production database | Not appropriate | Customer data never goes to the auditor. Send configuration evidence, such as encryption settings, or a redacted schema. |
| Access to your source code | Rarely needed | Change management is tested through tickets, pull requests and approvals, not code. Ask what the code would show that the pull request record does not. |
| Background check reports for sampled staff | Over-reach | Send confirmation that a check was completed and when. The reports contain personal information covered by PIPEDA that the control does not need. |
| A year of raw system logs | Over-reach | The control is usually log review or alerting. Send evidence that alerts fired and were handled, for the sampled dates. |
| Office badge logs, when the company is fully remote | Out of scope | Physical access is carved out to the data centre provider. Point to the carve-out in the scope memo. |
| Evidence from before the period starts | Depends | Legitimate for an annual control whose last run fell just before the window. Otherwise outside the period. |
| Policies for a category you did not elect | Out of scope | A Security-only report does not test the Privacy criteria. Point to the criteria in the engagement letter. |
| Screenshots of every server's configuration | Over-reach | Configuration is sampled. Offer a configuration export for the sample, or read access to the configuration management tool. |
How big should the samples be?
In a Type 2 the auditor tests a sample of each recurring control, and the size depends on how often the control runs and how large the population is. Firms set their own sampling methodology, so exact numbers differ, but most fall in a narrow band. If a request asks for far more than the ranges below, ask how the sample size was set.
| Control runs | Items usually sampled over a 12 month period |
|---|---|
| Annually | 1 |
| Quarterly | 2 |
| Monthly | 2 to 5 |
| Weekly | 5 to 15 |
| Daily | 20 to 40 |
| Many times a day (changes, tickets) | 25 to 60, depending on population |
A shorter period means smaller samples for the frequent controls, and a population under about twenty-five items is often tested in full. The change management version of this, with population sizes, is on SOC2Prep's page on shipping during the observation window.
How do you push back on a request without souring the audit?
In writing, specifically, and with an alternative. A reply that says "this is out of scope" starts an argument. A reply that names the boundary and offers the evidence that does fit usually ends one. Something along these lines:
Wording that works
"On request 47, the office badge logs: our scope memo of 12 March carves out physical security to our hosting provider, and our staff work remotely. We have attached the provider's SOC 2 report and our annual review of it under request 31. Could you confirm that covers the criterion, or tell us which point of focus you still need evidence for?"
That message does four things: it names the request, cites the agreement, points to evidence already provided, and asks a question that only has a criterion as an answer. If the answer is a genuine criterion you had missed, you have learned something useful. If it is not, the request comes off the list.
Escalate only when a request keeps coming back after a written answer. The route is the engagement manager first, then the partner who signs the report. Keep the tone factual; the same people will be back next year.
When is it your system description's fault?
More often than teams expect. The auditor tests the description you wrote, so every absolute in it, every "all", "always" and "within one hour", becomes a request. If you find the list keeps asking for evidence of things you do not quite do, read the description again. You cannot change it for the period already under test, but you can tell the auditor now that a statement was broader than your practice, which turns a future exception into a correction, and fix the wording for the next report. Preparing for SOC 2 covers writing a description you can live with.
Common questions
Is my SOC 2 auditor allowed to ask for anything they want?
They can ask for anything that supports their testing of the criteria in scope and the controls in your description. Requests outside that, such as systems you excluded or categories you did not elect, can be declined by pointing to the engagement letter and scope memo.
Should we ever send customer data to the auditor?
No. Evidence that a control operated never requires the protected data itself. Send configuration, metadata, redacted extracts or a screen share instead, and treat any request for raw customer data as a scope question.
Will pushing back make the auditor harder on us?
Not if it is done in writing, specifically and with an alternative. CPA firms deal with scope questions on every engagement. What sours a relationship is pushback on findings, not on requests.
Why does the auditor want the same thing twice?
Usually because the first submission could not be matched to the request, or it did not show the date. Label every file with the request number and the period it covers, and point to the earlier submission when an item repeats.
Can we refuse a request and still get a clean report?
For an out-of-scope request, yes, because it does not test anything in the report. Refusing a legitimate request leaves the auditor without evidence a control operated, which becomes an exception or, for enough controls, a limitation on the opinion.
Get help with a request list that keeps growing
Firms that prepare companies for SOC 2 also run the audit liaison.
Get matched