SOC Report: Which One Your Customer Is Actually Asking For
What a SOC Report Is, and Who Can Issue One
SOC stands for System and Organization Controls. The AICPA renamed the framework in 2017. It used to be Service Organization Control, and plenty of vendor contracts still carry the old phrase. A SOC report is an attestation engagement: an independent CPA firm examines the controls a service organization claims to have, tests them, and issues a written opinion on whether management’s description is fairly presented and whether the controls did what management said they did.
That word attestation is doing real work. Only a licensed CPA firm can issue a SOC report. Your penetration testing vendor cannot. Your compliance automation platform cannot, whatever the dashboard implies. The engagement runs under the AICPA’s attestation standards, AT-C section 320 for a SOC 1, AT-C sections 105 and 205 for a SOC 2, and the firm signing it is bound by independence rules and subject to peer review.
What you get back is a document, usually 40 to 120 pages, in five recognizable parts: the independent service auditor’s report (the opinion), management’s written assertion, a description of the system, the applicable criteria alongside the auditor’s tests and results, and a final section of unaudited information management wanted to include. Most readers skim section 1, hunt for exceptions in section 4, and ignore the rest. Section 3, the system description, is where the scope actually lives, and it is the part most likely to contradict what the salesperson promised.
One structural point people miss: the report is about a defined system, not about your company. A vendor with six products can scope a SOC 2 around one of them. The cover page will still carry the company name.
SOC 1 vs SOC 2 vs SOC 3
The three reports differ in subject matter, audience, and how freely they can be handed out.
A SOC 1 covers controls at a service organization that are relevant to a user entity’s internal control over financial reporting. Payroll processors, claims administrators, transfer agents, loan servicers, and cloud accounting platforms get asked for these because their processing runs straight into somebody else’s general ledger. The intended reader is the user entity’s financial statement auditor. Public company clients need it to support their own testing under Sarbanes-Oxley, and the auditor’s use of the report is governed by PCAOB AS 2601 for issuers and AU-C section 402 for everyone else.
A SOC 2 covers controls relevant to security, availability, processing integrity, confidentiality, and privacy, the Trust Services Criteria. This is the report SaaS companies, data centers, managed service providers, and anyone holding customer records gets asked for. The reader is a customer, a prospect, or a vendor risk team. It is a restricted-use report, which is why it arrives under an NDA and a click-through.
A SOC 3 is the general-use version of a SOC 2. Same underlying examination, same criteria, but the report strips out the detailed system description, the tests performed, and the results. You get the opinion, an abbreviated description, and management’s assertion. It can be posted on a website. It tells a sophisticated reader almost nothing, which is exactly the point. It exists so marketing has something to publish without exposing control detail.
| Report | Subject matter | Primary reader | Distribution |
|---|---|---|---|
| SOC 1 | Controls affecting user entities’ financial reporting | The customer’s financial statement auditor | Restricted |
| SOC 2 | Security, availability, processing integrity, confidentiality, privacy | Customers and vendor risk teams | Restricted |
| SOC 3 | Same as SOC 2, summarized | The general public | Unrestricted |
Two more sit alongside these. SOC for Cybersecurity examines an entity-wide cybersecurity risk management program and is general use. SOC for Supply Chain covers controls over production, manufacturing, and distribution. Neither shows up in ordinary vendor questionnaires yet, and a customer asking for “a SOC report” almost never means either one.
Type 1 vs Type 2, and Why the Dates Matter More Than the Type
Both SOC 1 and SOC 2 come in two flavors. The AICPA writes them as Type 1 and Type 2; the market usually writes Type I and Type II. Same thing.
A Type 1 asks whether the controls were suitably designed as of a single date. December 31, say. The auditor reads the design, confirms the control exists, and opines on whether it would achieve the stated objective if it operated. Nobody tests whether it actually ran. A Type 1 is a snapshot of intent.
A Type 2 asks the design question and then the harder one: did the controls operate effectively throughout a period? The auditor pulls samples across the window, traces evidence, and reports what failed. A first-year Type 2 usually covers three to six months. Mature programs run twelve.
Here is the part that costs deals. A customer’s vendor risk team does not just want a Type 2. It wants a Type 2 whose period covers the customer’s own reporting year with no gap. If your report period ends September 30 and your customer closes December 31, three months are uncovered. The customary patch is a bridge letter, sometimes called a gap letter, in which management represents that no material changes occurred between the report end date and the customer’s year end. A bridge letter is signed by you, not by the auditor. It carries no assurance whatsoever. Some vendor risk teams accept them without comment, some reject them flatly, and banks and insurers reject them more often than anyone else.
Pick your report period once and then keep it. Shifting the window creates either an overlap year or a gap year, and both generate questions you would rather not answer during a renewal.
The Five Trust Criteria
A SOC 2 is built on five categories, and this is where most first-time scoping decisions go sideways.
Security is mandatory in every SOC 2. It is delivered through the common criteria, numbered CC1 through CC9, which map to the seventeen principles of the COSO 2013 internal control framework plus supplemental criteria covering logical access, system operations, change management, and risk mitigation. Roughly two thirds of the control population in a typical SOC 2 sits here.
Availability covers whether the system is available for operation and use as committed. It brings in capacity monitoring, environmental protections, backup, and tested recovery. If your contracts carry uptime commitments, expect customers to ask for it.
Processing Integrity covers whether processing is complete, valid, accurate, timely, and authorized. Payment processors, payroll engines, billing platforms, and anything computing a number somebody relies on should carry it. Most SaaS companies do not, and most do not need to.
Confidentiality covers information designated as confidential, protection, retention, and disposal. It is the cheapest category to add to a security-only scope, because the controls largely already exist as encryption, access restriction, and a documented destruction process.
Privacy covers personal information across collection, use, retention, disclosure, and disposal, and it is the most expensive by a wide margin. It requires a published privacy notice, consent mechanics, data subject request handling, and evidence you honored those requests. Companies already running a GDPR or state privacy program can absorb it. Companies that are not should scope it out and say so plainly.
Adding a category is not free. Every category you select multiplies the control population, the evidence collected, and the sample sizes the auditor pulls. Scoping all five on a first SOC 2 is the single most reliable way to turn a $40,000 project into a $110,000 one.
Reading the Opinion, and What a Qualification Means
The opinion sits in section 1 and comes in four grades.
An unmodified opinion, the market calls it unqualified or clean, says the description is fairly presented, the controls were suitably designed, and in a Type 2 they operated effectively throughout the period. It does not mean zero exceptions were found. It means the exceptions found were not severe enough to change the conclusion. They are still listed in section 4, and any competent vendor risk analyst reads that section first.
A qualified opinion says everything holds except for one identified matter. The auditor names it: a control that did not operate for part of the period, a description that omits something relevant, an objective not achieved. The rest of the report stands. A qualified opinion is not a failure, and treating it like one is a mistake buyers and sellers both make.
An adverse opinion says the description is not fairly presented or the controls did not achieve the objectives, full stop. A disclaimer says the auditor could not obtain enough evidence to form any opinion at all, usually because records were missing. Both are rare, and both produce a document nobody can sell with.
The calibration a buyer should apply: read the exceptions before you read the opinion. A clean SOC 2 scoped to security only, covering a three-month period, with a carve-out for the subservice organization that runs the actual infrastructure, tells you far less than a qualified twelve-month report covering four categories where the single exception was a terminated employee whose access lingered nine days. The first document is clean and nearly empty. The second is honest and mostly reassuring.
Complementary User Entity Controls and the Carve-Out Question
Two mechanics buried in the middle of every SOC report shift responsibility away from the service organization, and almost nobody on the customer side reads them.
Complementary user entity controls, CUECs, are the controls the service organization assumes you are performing. The report only holds together if you do them. A payroll processor’s SOC 1 will state that the user entity reviews the payroll register before approving the run and reconciles the funding total. If your controller has never once opened that register, the control objective is not met at your end, and no amount of clean opinion on the vendor’s side fixes it. There is typically a list of eight to twenty of these near the back. Pull it, assign an owner to each line, and keep evidence.
Subservice organizations are the vendors your vendor depends on. The report handles them one of two ways. Under the carve-out method, the subservice organization’s controls are excluded from the description and from the auditor’s testing, and the report simply names them and lists complementary subservice organization controls. Under the inclusive method, those controls are described and tested inside the report. Carve-out is far more common because it is far easier to arrange. The consequence is that a SOC 2 from a company running entirely on a hyperscaler may carve out nearly all infrastructure controls, and you are then expected to go collect that provider’s own SOC 2 and read it too.
Vendor risk programs that stop at “we have their SOC 2 on file” and never open the CUEC list or chase a carved-out subservice report have a documentation program, not a risk program.
Who Gets Asked for One, and How to Prepare
The demand almost never comes from a regulator. It comes from a customer, usually mid-deal, usually through a security questionnaire that lands after verbal agreement on price. Financial firms subject to the Gramm-Leach-Bliley Safeguards Rule ask earliest, healthcare buyers are close behind, and enterprise procurement asks universally. Once one customer asks, the rest follow within a year.
Preparation runs in a predictable order. Start with a readiness assessment, scope the system boundary, pick the categories, inventory what controls actually exist, and get an honest gap list. Fix the gaps, which is where the calendar goes: writing policies is fast, but proving that access reviews happened quarterly requires quarters to pass. Then run the observation period, collecting evidence as you go rather than reconstructing it in week eleven. Then fieldwork, sampling, and drafting. Then the report, typically three to six weeks after fieldwork closes.
Two decisions determine whether the first cycle is painful. The first is the system boundary: draw it around what customers actually buy, not around the whole company. The second is evidence discipline. A ticket showing the change was approved before it shipped is evidence. A screenshot taken in month eleven of a setting that is currently correct is not. Auditors sample from populations, incomplete populations mean expanded samples, and expanded samples mean exceptions.
Worth saying out loud: your independent auditor cannot write your controls, implement your policies, or run your access reviews for you. Independence rules prohibit it. The firm helping you get ready and the firm signing the opinion have to be different firms, and any provider offering both in one package should be asked to explain how that works. This page is general information, not tax, legal, or assurance advice for your situation; talk to a licensed CPA about your specific scope, timing, and reporting obligations before you commit to a period or sign an engagement letter.
Related Services from The Reed Corporation
Helpful Guides You Might Also Like
Sources & References
Frequently Asked Questions
What is the difference between a SOC 1 report and a SOC 2 report?
They answer different questions for different readers, and the fastest way to work out which one a customer wants is to ask who will actually read it. If the answer is “our external auditors,” it is a SOC 1. If the answer is “our security team” or “our third-party risk group,” it is a SOC 2. That one question settles most of the confusion, and it settles it before anybody has spent money.
A SOC 1 report addresses controls at a service organization that are relevant to a user entity’s internal control over financial reporting. The engagement runs under AT-C section 320 within the AICPA’s attestation standards. The control objectives in a SOC 1 are written by the service organization’s own management, not handed down by a standards body, and they read like this: “Controls provide reasonable assurance that payroll disbursements are processed completely, accurately, and in the period intended.” Because management writes them, two payroll processors can issue SOC 1 reports with different objectives, different numbering, and wildly different granularity. That is convenient for the service organization and irritating for the reader.
The intended audience is your financial statement auditor. When they plan your audit and find that a material process runs outside your four walls, payroll, claims adjudication, custody of securities, loan servicing, subscription billing that feeds revenue recognition. They need evidence about controls they cannot reach. A SOC 1 Type 2 is that evidence. For public company clients the mechanics live in PCAOB AS 2601; for private companies the parallel is AU-C section 402. Without the report your auditor has three choices: obtain it, send staff to the service organization to test controls directly, or expand substantive testing on your books. The first is by far the cheapest, which is the entire reason the SOC 1 market exists.
A SOC 2 addresses something else. It reports on whether controls meet the Trust Services Criteria, security always, plus any of availability, processing integrity, confidentiality, and privacy that management selects. Those criteria are fixed by the AICPA, published openly, and identical in every SOC 2 issued anywhere. That is the structural difference worth remembering: SOC 1 objectives are bespoke, SOC 2 criteria are standardized. You can put two SOC 2 reports side by side and compare control coverage line for line. Putting two SOC 1 reports side by side mostly teaches you how differently two managements can describe the same process.
Distribution differs too, though less than people think. Both are restricted-use reports. A SOC 1 is restricted to management of the service organization, user entities during the covered period, and their auditors, which means a prospect who is not yet a customer technically has no standing to receive it, and plenty of service organizations hand it over anyway. A SOC 2 is restricted to parties with sufficient knowledge to understand it, which in practice means existing and prospective customers under NDA. Only a SOC 3 is genuinely public.
Here is what the choice looks like with real numbers. Take a 40-person payroll and benefits administration firm in Manhattan running roughly $9.4 million of revenue and serving 300 employer clients. Four of those clients file with the SEC, and their audit firms have been asking for a SOC 1 for two years. Separately, a hospital system in the pipeline sent a 240-question security questionnaire and said a SOC 2 Type 2 is a contractual precondition to signing a $1.2 million three-year deal.
The firm cannot pick one. They need both, for different readers. Priced separately, the SOC 1 Type 2 came in at $38,000 and the SOC 2 Type 2 covering security, availability, and confidentiality came in at $52,000, $90,000 of audit fees. Priced as a combined engagement with one shared walkthrough phase and overlapping tests of access and change management controls, the same firm quoted $74,000. Readiness work, which has to come from a different firm for independence reasons, ran $22,000. Year one landed at $96,000 against a $1.2 million contract they could not otherwise sign, and year two dropped to roughly $78,000 once readiness fell away. Framed as a percentage of the deal it was defensible. Framed as an unbudgeted line item discovered in Q3, it was a fight.
The common mistake is assuming one report can serve both purposes. It cannot. A SOC 2 says essentially nothing about the completeness and accuracy of transaction processing feeding a client’s general ledger unless processing integrity was in scope, and even then the criteria are not written toward financial statement assertions. Handing your client’s audit partner a SOC 2 when they asked for a SOC 1 does not save you an engagement; it delays their audit and gets the question asked again, usually with less patience. The mirror-image error is a service organization that has always produced a SOC 1 and assumes it satisfies a security questionnaire. It does not, and vendor risk teams have gotten better at noticing.
The second common mistake is the report period. Your client’s auditor needs coverage of your client’s fiscal year, not yours. A SOC 1 covering January through September is close to useless to a December-year-end audit client unless the gap is bridged, and a bridge letter is your representation rather than the auditor’s. Service organizations with a concentrated client base should set the period to match the majority of clients and say so in the sales conversation.
Going forward, the sequence that works is: inventory who is asking and why, decide which report each requester actually needs, pick a period that covers the majority of your clients’ year ends, and budget for readiness plus audit as two separate line items with two separate firms. Do it in the annual planning cycle rather than mid-deal, because the calendar is the constraint that cannot be bought back. Our client accounting team works with service organizations on the close discipline and evidence retention that make either examination survivable, and our SOX compliance guide explains what your public company clients are doing with your SOC 1 once they receive it. This is general information rather than assurance advice for your situation; a licensed CPA should look at your specific client base and reporting obligations before you commit to a scope.
What is the difference between a SOC 2 Type 1 and a SOC 2 Type 2 report?
A Type 1 tests design. A Type 2 tests design and operation over time. That sentence is accurate and almost useless in practice, because the real difference is what each one lets a customer conclude, and a Type 1 lets them conclude very little.
In a Type 1 examination the auditor evaluates whether management’s description of the system is fairly presented and whether the controls were suitably designed as of a specified date. Suitably designed means that if the control operated as described, it would meet the applicable criterion. The auditor inspects the policy, walks through the process, confirms the control exists and is capable of working, and stops. Nobody pulls a sample. Nobody checks whether the quarterly access review actually happened in Q2. A Type 1 dated December 31 tells you the machine was assembled correctly on December 31. It tells you nothing about whether anyone switched it on.
In a Type 2 the auditor does all of that and then tests operating effectiveness throughout a stated period. For a control that runs daily, the auditor might sample 25 to 40 instances. For a quarterly control across a twelve-month period, the population is four and the auditor tests all four. Failures get written up in section 4 as exceptions, with the number tested, the number that failed, and management’s response. That section is the actual product. Everything before it is context.
The period length is a negotiation with reality. The attestation standards do not mandate a minimum, but a period shorter than three months invites the question of whether periodic controls could even have operated once. Three months is the practical floor for a first Type 2. Six months is common. Twelve is where mature programs settle, because a twelve-month report renews cleanly year over year and covers any customer fiscal year end without a bridge letter.
The usual sequencing advice, do a Type 1 first, then a Type 2, deserves more skepticism than it gets. A Type 1 costs real money, consumes the same readiness effort, and produces a document many enterprise vendor risk teams will accept only as a temporary placeholder. If a customer’s contract says “SOC 2 Type 2,” a Type 1 does not satisfy it. The case for a Type 1 is narrow and specific: you need something in hand within eight weeks to keep a deal alive, and the customer has agreed in writing that a Type 1 now plus a Type 2 within twelve months is acceptable. If nobody has agreed to that, skip it and put the money into a longer observation window.
Here is the arithmetic on a real decision. A 55-person SaaS company selling workflow software to regional banks had two deals stalled: one worth $340,000 in annual recurring revenue, one worth $185,000. Both buyers required a SOC 2. Readiness took eleven weeks and $26,000 with an advisory firm. The audit firm quoted $21,000 for a Type 1 dated March 31 and $46,000 for a Type 2 covering April 1 through September 30, with the report issued in late October.
Doing both cost $67,000 in audit fees plus the $26,000 of readiness, $93,000 for the year. Doing only the Type 2 cost $72,000 all in, but the report would not exist until late October, and the $185,000 buyer had a September budget deadline that would have pushed the deal into the following fiscal year. The company ran both, closed the smaller deal in April on the strength of the Type 1 and a written commitment to deliver a Type 2 by year end, and recovered the $21,000 several times over. Had both buyers been willing to wait, the Type 1 would have been $21,000 spent on a document destined for a folder.
One more mechanical point that costs companies more than it should: your first Type 2 period should start after remediation is finished, not before. If your access review control was implemented in May and your period starts in January, the auditor tests January through April and finds four months with no control. That produces exceptions and possibly a qualification, on a report you are paying full price for. Starting the period in June instead costs you five months of calendar and buys you a clean first report. Companies rush this constantly, usually because a salesperson promised a date.
The common mistake is treating a Type 1 as a lightweight Type 2 and marketing it as though the distinction is technical. It is not technical. A Type 1 contains no test results, so a customer reading it learns that controls were described and looked reasonable on one day. Publishing “we are SOC 2 audited” on the back of a Type 1 and letting prospects assume otherwise is the kind of thing that surfaces during renewal diligence, and it damages trust more than having no report at all would have.
The second common mistake is letting the report go stale. A Type 2 covering a period that ended fourteen months ago is treated as expired by most vendor risk programs even though nothing on the document says so. Renewal is annual and continuous, evidence collection for period two should begin the day period one closes, not when the next audit kickoff call is scheduled.
Going forward, the pattern that works is to pick a twelve-month period aligned to a calendar you can defend, start it after remediation is genuinely complete, collect evidence continuously rather than in a scramble, and treat the Type 1 as an optional bridge you buy only when a named deal justifies it. If you are heading toward a financing event or a listing, expect the control expectations to tighten further. Our guide to what an IPO involves covers what arrives on top. For the internal control vocabulary your auditors and your customers now share, the AICPA’s SOC materials and the NIST SP 800-53 catalog are the two references most often mapped against a SOC 2 control set. This page is general information and not assurance advice for your company; a licensed CPA should review your scope and period before you sign anything.
How much does a SOC report cost, and how long does the whole process take?
Two numbers get quoted and only one of them is the real cost. The audit fee is what a CPA firm charges to perform the examination and issue the opinion. The project cost is that fee plus readiness, plus remediation, plus tooling, plus the internal hours your engineering and operations people spend producing evidence. Companies budget the first number and get surprised by the third.
Ranges we see in the New York market, for a single SOC 2 with a normal scope, look roughly like this. Readiness or gap assessment from an advisory firm: $12,000 to $35,000 depending on how much of the control set already exists. A SOC 2 Type 1: $15,000 to $40,000. A SOC 2 Type 2 covering security only, three to six months: $25,000 to $55,000. A SOC 2 Type 2 covering three or four categories over twelve months: $50,000 to $120,000. A SOC 1 Type 2 runs in a similar band and depends heavily on the number of control objectives management writes. Compliance automation tooling adds $8,000 to $35,000 a year. Penetration testing, which most SOC 2 control sets reference and which maps to the vulnerability management families in NIST SP 800-53, adds $8,000 to $30,000. Those are ranges, not quotes, and they move with headcount, number of systems, and how many subservice organizations you carve out.
The variables that actually drive the fee are worth naming, because three of them are within your control. The number of Trust Services categories in scope is the biggest single lever, each additional category expands the criteria population and the testing. Number of in-scope systems and environments is second; a company with one production environment and one identity provider is far cheaper to audit than one with four acquired platforms on three clouds. Headcount matters because access and onboarding controls are sampled against employee populations. Period length matters. Whether you carve out or include subservice organizations matters enormously, and carve-out is both cheaper and the market default.
Timeline is more predictable than cost. Readiness runs four to twelve weeks. Remediation is the wild card and can run one week or nine months, because implementing a control is fast and accumulating four quarters of evidence that it ran is not. The observation period is three to twelve months by definition. Fieldwork is two to five weeks of auditor time, mostly asynchronous evidence requests. Report drafting, partner review, and issuance take another three to six weeks after fieldwork closes. A company starting from nothing and wanting a twelve-month Type 2 in hand is realistically eighteen months out. A company that already has decent controls and wants a six-month Type 2 is nine to eleven months out.
Here is a real-shaped budget. A 30-person fintech in Brooklyn, $6.8 million ARR, running on a single cloud account with one identity provider and no acquisitions, scoping security and confidentiality for a six-month Type 2. Readiness: $18,000. Tooling: $14,000 for the first year. Penetration test: $11,000. Remediation, mostly engineering time rather than cash, ate about 260 internal hours, call it $39,000 of loaded cost that never shows up on an invoice. Audit fee: $41,000. Cash out the door was $84,000; true project cost was closer to $123,000. In year two the readiness line disappeared, tooling renewed at $14,000, the pen test repeated at $11,000, the audit fee dropped to $37,000 for a twelve-month period, and internal hours fell to about 90. Year two cash was $62,000. That drop from year one to year two is the single most useful thing to tell a CFO who is looking at the first invoice and asking whether this is permanent.
Against what? The company had $2.4 million of pipeline gated on the report. Even at $123,000 of true year-one cost the arithmetic is not close. The projects that go badly are the ones where nobody quantified the gated revenue and the whole thing became a cost center argument.
The common mistake is buying readiness and audit from the same firm because the bundled price looks better. Independence rules under the AICPA attestation standards do not permit the firm issuing the opinion to have designed or implemented the controls it is opining on. Some providers structure around this with separate legal entities and thin walls. Ask directly, in writing, who is performing readiness, who is signing the report, and how independence is maintained. A customer’s vendor risk team that later discovers the answer will discount the report accordingly, and you will have paid full price for a document with an asterisk.
The second common mistake is choosing an audit firm on price alone. A SOC report carries the name of the firm that signed it, and enterprise vendor risk teams absolutely notice whether that name is recognizable. A $19,000 report from a firm nobody has heard of, issued in nine days, gets questions. It may also get rejected outright by a bank’s third-party risk program that maintains an approved auditor list. Ask any prospective auditor how many SOC engagements they issue annually, whether their peer review is current, and whether they have been accepted by buyers in your customers’ industries.
The third is forgetting the internal hours. Evidence production is not free. Somebody on your team is going to spend a day a week for two months pulling access exports, ticket samples, and change records. Naming that person and protecting their time up front is the difference between a nine-month project and a fourteen-month one.
Going forward, treat the SOC report as an annual operating cost with a capital spike in year one, not as a project with an end date. Put readiness in the budget one year, the audit in the next, and renew continuously after that. Ask every prospect who requests a report which specific categories and period they require, because a security-only six-month Type 2 that satisfies your top ten accounts is a far better use of $45,000 than an all-categories report nobody asked for. Our business management team helps companies model the readiness and audit spend against the revenue actually gated on it, and our financial services compliance guide covers what regulated buyers layer on top of the report itself. Fees and timelines here are observed ranges rather than quotes, and this page is general information and not assurance advice; a licensed CPA should scope your specific situation before you budget it.
What does a qualified opinion on a SOC report mean for customers relying on it?
It means the auditor found one identified thing wrong and told you exactly what it was. Everything else in the report still stands. That is genuinely different from a failed audit, and the reflex to treat a qualified SOC report as disqualifying costs buyers good vendors and costs vendors good deals.
The mechanics are worth understanding before the judgment. When an auditor completes a SOC examination they issue one of four opinions. An unmodified opinion says the description is fairly presented, the controls were suitably designed, and, in a Type 2. They operated effectively throughout the period. A qualified opinion says all of that is true except for a specific matter the auditor then describes. An adverse opinion says the description is not fairly presented or the controls did not achieve the stated objectives. A disclaimer says the auditor could not obtain sufficient evidence to reach any conclusion. Only the last two mean the document cannot be relied on at all.
A qualification arises from one of three situations. The description was not fairly presented, management said something the auditor could not support, or omitted something a user would need. The controls were not suitably designed. A control as written could not achieve its objective even if it worked perfectly. Or the controls did not operate effectively during the period. The design was fine and the execution was not. That third case is by far the most common, and it usually traces to a specific, datable failure: a quarter where access reviews were not performed, a stretch where backups were not tested, changes that shipped without documented approval during a crunch.
The right way for a customer to read a qualification is to answer four questions. Which criterion or control objective is affected? Does it touch data or processing you actually depend on? How long did the failure last, and when? What did management do about it, and can they show that the remediation itself is now operating? A qualification on availability monitoring matters enormously to a customer with an uptime-dependent workflow and hardly at all to one running batch jobs overnight. A qualification on logical access matters to everybody.
Here is a concrete version. A mid-market data processor issued a twelve-month SOC 2 Type 2 covering security and confidentiality. The opinion was qualified. The reason, spelled out in section 4: for the four months from March through June, quarterly user access reviews were not performed for two of nine in-scope systems following the departure of the IT manager who owned the control. The auditor tested nine systems, found the control operating for seven, and wrote up the two. Management’s response documented that reviews resumed in July, that a compensating detective control had caught and removed three stale accounts, and that ownership had been reassigned with a calendar-enforced ticket.
A prospective customer evaluating that vendor for a $480,000 three-year contract had a real decision. Rejecting the vendor meant restarting a six-month selection process, at an internal cost the procurement lead estimated at $70,000 of staff time plus a quarter of delay on a project with revenue attached. Accepting it meant documenting the exception in their own vendor file. What they actually did was accept with conditions: they required the vendor to provide the next period’s report within sixty days of issuance, required written confirmation that the access review control had operated for two consecutive quarters, and added a contractual right to terminate without penalty if the following report carried a qualification on the same criterion. That is a proportionate response, and it took one hour of a risk analyst’s time rather than six months of re-procurement.
Contrast that with a qualification a buyer should treat harshly: an auditor reporting that the description of the system omitted a subservice organization that processes customer data, discovered during fieldwork. That is a disclosure failure rather than an operating failure, and disclosure failures say something about management that an access review lapse does not.
The common mistake on the buyer side is a vendor risk policy that treats any modification as an automatic disqualification. Policies like that produce two bad outcomes. They push buyers toward vendors with narrow scopes and short periods, because a report covering security only for three months has far less surface area to fail on than a twelve-month report covering four categories. And they teach vendors that honesty is expensive. A vendor who knows a qualification ends deals has an incentive to scope their next report around the problem instead of fixing it.
The common mistake on the vendor side is going quiet. If your report is coming back qualified you will know weeks before it is issued, and the worst possible sequence is a customer discovering it in a PDF. Get ahead of it: send a short note describing the exception, the dates, the remediation, and the evidence that remediation is operating. Most customers accept a qualification they were told about and escalate one they found themselves.
The third mistake is not reading section 4 of a clean report. Unmodified opinions routinely contain exceptions, a control tested 40 times that failed twice, deemed not severe enough to change the conclusion. Those exceptions are real information. A buyer who reads only the opinion paragraph is reading a headline and skipping the story.
Going forward, both sides should treat qualifications as data rather than verdicts. Vendors should fix the specific control, keep the scope steady rather than shrinking it, and expect to explain the prior-year exception for one more cycle. Buyers should write vendor risk policies that classify exceptions by criterion and duration instead of counting them, and should require the next report on a defined timeline rather than issuing an ultimatum. The Trust Services Criteria and the PCAOB guidance on using service organization reports both assume a reader capable of judgment, and the FTC Safeguards Rule similarly expects financial firms to assess vendors rather than collect documents. Our SOX compliance guide walks through the parallel vocabulary of deficiencies and material weaknesses on the financial reporting side. This is general information rather than assurance advice for your situation; have a licensed CPA review the actual report language before you make an accept-or-reject decision on it.
Who needs a SOC report, and can a company produce one itself?
No federal statute orders anyone to obtain a SOC report. There is no filing requirement, no registry, no agency that checks. The obligation is contractual and commercial: your customers demand it, and at some point enough of them demand it that not having one costs more than having one. That is the whole mechanism, and it explains why demand shows up abruptly rather than gradually.
The companies that get asked share one trait. They process, store, or transmit something a customer is accountable for. Payroll and benefits administrators, claims processors, transfer agents, fund administrators, loan servicers, and billing platforms get asked for a SOC 1, because their output lands in someone else’s financial statements. SaaS platforms, data centers, colocation providers, managed service providers, marketing platforms holding customer lists, and anyone handling protected health information or cardholder data get asked for a SOC 2. Companies that do both, like a payroll processor holding sensitive employee data, get asked for both.
The demand is amplified by what sits behind your customer. Financial institutions operate under the Gramm-Leach-Bliley Safeguards Rule, which requires them to oversee service providers and select ones capable of maintaining appropriate safeguards. Federal contractors and their subcontractors get measured against control catalogs like NIST SP 800-53. Healthcare covered entities have business associate obligations. New York-regulated financial companies work under the Department of Financial Services cybersecurity regulation at 23 NYCRR Part 500, which carries explicit third-party service provider policy requirements. None of those rules name a SOC report. All of them create a documentation problem that a SOC report happens to solve, which is why the request arrives from a compliance officer who has been told to demonstrate vendor oversight.
Now the second half of the question, and the answer is flatly no. A company cannot produce its own SOC report. The examination has to be performed by an independent licensed CPA firm, and independence is not a formality. The firm signing the opinion cannot have designed the controls, implemented them, operated them, or made management decisions about them. The attestation standards govern that firm’s work, and the firm is subject to peer review. A document your security team produced describing your controls is a self-assessment. It may be a perfectly good self-assessment. It is not a SOC report, and calling it one in a sales conversation is the sort of thing that ends badly.
What a company can do internally is everything up to the examination: define the system boundary, write the control set, implement it, and run a readiness assessment. Readiness can come from a consulting firm, from your own team, or from a compliance automation platform, none of which can then issue the opinion. That separation is the reason a first SOC project involves two vendors.
Consider the arithmetic for a 22-person analytics company in Queens with $4.1 million of revenue. Three customers representing $1.35 million of annual contract value all wrote SOC 2 requirements into renewals landing within eleven months. A fourth prospect worth $290,000 made it a precondition to a pilot. Total revenue directly gated: $1.64 million. Their first-year path was readiness at $16,000, tooling at $12,000, a penetration test at $9,000, and a six-month security-and-confidentiality Type 2 at $38,000, $75,000 of cash, plus roughly 180 internal engineering hours. They considered the alternative seriously, which was to answer each customer’s security questionnaire individually. Four questionnaires at 200-plus questions each, with follow-ups, ran about 120 hours of senior engineering and legal time and produced no reusable artifact, and two of the four customers said a questionnaire would not substitute for the report at renewal anyway. The decision was not close.
People also ask how SOC 2 compares to ISO/IEC 27001, and the difference is structural. ISO 27001 is a certification issued by an accredited certification body against a management system standard, on a three-year cycle with annual surveillance audits, and it produces a certificate. A SOC 2 is an attestation report issued by a CPA firm, renewed annually, and it produces an opinion with test results attached. European and multinational buyers often prefer the certificate; North American buyers generally want the report. Companies selling into both frequently carry both, and the underlying control work overlaps by a large margin even though the deliverables do not.
The common mistake is starting the project because one customer asked, scoping it to that one customer’s requirements, and then discovering the next three customers wanted different categories or a different period. Before scoping, ask your five largest accounts and your top two prospects, in writing, which report and which categories their policy requires. Twenty minutes of that saves a scope change that costs $20,000.
The second common mistake is believing a compliance automation platform produces the report. Those platforms are genuinely useful. They collect evidence continuously, monitor control status, and cut the auditor’s evidence requests substantially. They do not perform the examination and they do not issue an opinion. A dashboard reading one hundred percent compliant is a statement about the platform’s checks, not about an auditor’s conclusion.
The third is waiting for the first request. By the time a customer asks, you are nine to eighteen months from a Type 2, and no amount of money compresses an observation period. Companies selling to regulated buyers should start readiness before the first request rather than after.
Going forward, treat the trigger as a leading indicator rather than a deadline. If your customer base is drifting upmarket, if you have started answering security questionnaires, or if a term sheet is on the horizon, begin readiness on your own schedule while the calendar is still yours. Decide which report each set of readers needs, pick a period you can hold for years, and hire the readiness firm and the audit firm separately. Our business management team works with growing companies on the control and documentation groundwork that makes a first examination survivable, and our financial services compliance guide explains what regulated buyers stack on top. This page is general information rather than tax, legal, or assurance advice for your company; talk to a licensed CPA about your specific customers, scope, and timing before committing to an engagement.