If you sell software to businesses, you will eventually hear the question: "Do you have a SOC 2 report?" For many SaaS companies, that question arrives right when a large deal is on the line. A missing report can stall procurement for months, while a clean one can shorten security reviews to days.
SOC 2 is not a certification you buy. It is an independent audit of how your company protects customer data. This guide explains what the framework requires, which controls matter most, how to evaluate vendors (and their reports), and the mistakes that cost teams time and money.
What SOC 2 Actually Is
SOC 2 (System and Organization Controls 2) is an attestation framework created by the American Institute of Certified Public Accountants (AICPA). A licensed CPA firm examines your controls and issues a report stating whether they are designed appropriately and, in some cases, whether they operated effectively over time.
Two points surprise newcomers. First, there is no pass or fail checklist handed down by a regulator. You define your own controls, and the auditor tests them against the criteria. Second, the result is a report, not a badge. Customers read it, so its scope and any exceptions matter as much as the cover letter.
The Five Trust Services Criteria
SOC 2 is organized around five Trust Services Criteria:
- Security (required): Protection against unauthorized access. Every SOC 2 report includes this, sometimes called the Common Criteria.
- Availability: Systems are accessible as committed, supported by monitoring, capacity planning, and disaster recovery.
- Confidentiality: Information designated confidential is protected throughout its lifecycle.
- Processing Integrity: Data processing is complete, accurate, and timely.
- Privacy: Personal information is collected, used, retained, and disposed of according to your commitments.
Most software companies start with Security alone, then add Availability and Confidentiality as customers ask. Adding criteria increases audit scope and effort, so choose based on what your contracts and buyers actually require rather than collecting all five by default.
Core Controls Software Teams Need
Controls are the specific policies and technical safeguards you operate daily. While every company's set is different, auditors consistently look for the following areas.
Access control
This is the most heavily tested area. Expect to demonstrate single sign-on and multi-factor authentication for production systems, role-based access with least privilege, prompt removal of access when someone leaves, and periodic access reviews. Auditors will sample terminated employees and ask for proof that access was revoked on time.
Change management
Every production change should be traceable. In practice that means pull requests with required reviews, protected main branches, automated tests, and a documented path from ticket to deployment. If engineers can push straight to production without review, that is a finding waiting to happen.
Logging, monitoring, and incident response
You need centralized logs, alerts for suspicious activity, and a written incident response plan that you have actually rehearsed. Auditors often request evidence of a tabletop exercise or a real incident handled according to the plan.
Vulnerability and patch management
Regular vulnerability scans, dependency monitoring, and defined remediation timelines (for example, critical issues within a set number of days) show that you find and fix weaknesses systematically. Annual penetration testing is common, though not strictly mandated.
Data protection
Encrypt data in transit and at rest, manage secrets properly, and define retention and deletion practices. Backups should be tested, not merely configured.
Risk management and governance
A documented risk assessment, an information security policy approved by leadership, security awareness training, and background checks where appropriate round out the people-and-process side. These are less glamorous than encryption but are frequently where audits go wrong.
Vendor management
Your own subprocessors matter. You are expected to inventory vendors, assess their risk, and review their security posture, which brings us to evaluation.
Type I vs. Type II: Which Do You Need?
A Type I report evaluates whether controls are suitably designed at a single point in time. It is faster, often achievable in a couple of months, and useful for getting past early-stage buyer questions.
A Type II report tests whether controls operated effectively across an observation window, typically three to twelve months. This is what mature buyers want, because it shows consistent behavior rather than a snapshot.
A common path is a Type I first, followed by a Type II with a three- to six-month window, then annual twelve-month renewals. If you already know enterprise customers will demand Type II, consider going straight there to avoid paying for two audits.
Evaluating Vendors: Two Perspectives
Vendor evaluation cuts both ways in SOC 2. You will be evaluated by your customers, and you must evaluate your own suppliers. Here is how to approach each side, along with the tooling and audit partners you may need to choose.
Reading a vendor's SOC 2 report
Do not treat "we have SOC 2" as a checkbox. When a supplier shares a report, check these items:
- Report type and period. Is it Type II? Does the observation window end within the last twelve months? A stale report tells you little.
- Scope. Does the system description cover the product and infrastructure you will actually use, or only a small corner of the business?
- Trust criteria covered. If you need confidentiality or availability assurances, confirm they are included.
- Auditor opinion. An unqualified opinion is the goal. A qualified opinion signals significant control failures.
- Exceptions. Read the testing results. Occasional exceptions are normal; repeated failures in access control or change management are not.
- Complementary User Entity Controls (CUECs). These are controls you are expected to operate on your side. Missing them can undermine the vendor's protections.
- Subservice organizations. Note whether cloud providers are carved out or included, and whether you have their reports too.
If there is a gap between the report's end date and today, request a bridge letter in which management states that no material changes have occurred.
Choosing compliance automation and auditors
Many teams use compliance automation platforms to collect evidence from cloud providers, identity systems, and code repositories. When comparing options, consider integration coverage with your actual stack, how well the tool supports ongoing monitoring rather than a one-time sprint, and whether it locks you into proprietary policy templates you cannot edit.
For auditors, reputation and fit matter more than price. Ask how many companies of your size and technology profile they have audited, how they handle scope questions, whether the same team stays through the engagement, and how their reports are received by enterprise buyers. A very cheap audit can backfire if customers question the firm's credibility. Remember that the platform does not audit you; only a licensed CPA firm can.
Common Pitfalls
Teams repeat the same mistakes with surprising consistency. Avoid these.
Treating SOC 2 as a documentation project. Beautiful policies mean nothing if engineers do not follow them. Auditors test operation, so build controls into existing workflows rather than writing aspirational documents.
Scoping too broadly or too narrowly. Including every internal system inflates cost and risk. Excluding the core production environment makes the report worthless to buyers. Define scope around the systems that store or process customer data.
Starting the observation window too early. If controls are not running reliably on day one, early failures become exceptions in your Type II report. Run a readiness assessment first and begin the window only when the controls hold.
Evidence gaps. Controls that happen but leave no record effectively did not happen. Access reviews, training completion, and risk assessments need dated, retrievable proof.
Ignoring offboarding and onboarding. Late access removal and missed security training are among the most common exceptions. Automate them where possible.
Forgetting vendor risk. Many companies list vendors but never review them. Keep a current inventory, tier vendors by risk, and collect their reports annually.
Letting compliance live with one person. If a single engineer owns everything, the program collapses when they leave. Assign clear owners and review progress regularly.
Assuming the report ends the work. SOC 2 is annual. Controls must keep operating, and each audit expects continuity.
Getting Started: A Practical Roadmap
Begin by defining which customers and contracts are driving the requirement, then pick the criteria and report type that satisfy them. Run a gap assessment against your current practices, fix the highest-risk gaps first (typically access control, logging, and change management), and choose tooling and an auditor that fit your stage. Start the observation window only once controls operate consistently, and set a calendar for recurring tasks such as quarterly access reviews.
Done well, SOC 2 is more than a sales enabler. It forces useful discipline around how software is built, shipped, and protected, and it gives your customers evidence rather than promises.
Frequently Asked Questions
1. How long does it take to get a SOC 2 report?
A Type I report can often be completed in two to four months, including preparation. A Type II requires an observation period of three to twelve months, plus audit fieldwork and report writing, so plan on six to twelve months from kickoff for a first Type II.
2. How much does SOC 2 cost?
Costs vary widely based on scope, company size, and tooling. Expect audit fees from the low tens of thousands of dollars upward, plus compliance software subscriptions and the internal time your team spends. Always get written quotes and confirm what is included.
3. Is SOC 2 legally required?
No. SOC 2 is voluntary and driven by customer demand and contract requirements. However, regulated industries and large enterprise buyers often make it a de facto prerequisite for doing business.
4. What is the difference between SOC 2 and ISO 27001?
SOC 2 is an attestation report issued by a CPA firm and is most common in North America. ISO 27001 is a certification of an information security management system issued by an accredited certification body and is more widely recognized internationally. They overlap significantly, and many companies pursue both.
5. Can I fail a SOC 2 audit?
There is no formal pass or fail, but the auditor can issue a qualified or adverse opinion if controls are inadequate. Exceptions within an otherwise unqualified report are common and usually acceptable if they are isolated, explained, and remediated. A readiness assessment before the audit greatly reduces surprises.
Work with eSparks IT Solutions
Planning a project around this? We help businesses across the USA, UK, Canada, Australia and the GCC ship it. See how we work with clients in the USA. Explore our Security services and portfolio, estimate your project cost, or book a free call.
Top comments (0)