SOC 2 for the US Market

For any American business founder, SOC 2 often seems like a burden of bureaucracy. Meanwhile, this audit can significantly speed up the deal cycle by 30-50% and maximize their number, as compliance in the corporate sector is no longer the concern of the security department only – instead, it opens the opportunity to capture the enterprise market (by the way, this is the unobvious answer to the question: “What does SOC 2 stand for?”). Below, we've outlined a number of aspects demonstrating the benefits of passing the SOC 2 audit, revealed all aspects of preparation for it, and described potential pitfalls.

Why SOC 2 in the US Is Sales-Driven, Not Compliance-Driven

While the EU market relies on GDPR requirements, for US companies, the main driver is liability, confirmed by the SOC 2 framework. Indeed, no one wants to assume the risk of vendors’ data breach – that's why procurement departments of large US corporations typically use SOC 2 as a filter. This means that if a vendor doesn't have a SOC 2 report, they won't even get to the shortlist.

Moreover, without certification, your sales managers are often forced to find excuses for why your company hasn't yet been audited. So why not resolve all these doubts immediately by obtaining SOC 2 certification, and how to get it? Let's find out!

Common Early Confusion

Let's start by reviewing the basic concepts related to SOC 2. First, it's an attestation, not a certification, as in practice, SOC 2 is not a certificate (unlike ISO 27001). This means that an independent auditor doesn't simply give you a document; they sign off on the fact that your controls are operating as stated – actually, this is the direct answer to the question: “What is SOC 2 compliance?”.

Also, in this context, there are differences between SOC 2 Type I and Type II. The former records specific aspects of your IT infrastructure and its processes at a specific point in time. This confirms that you've created them correctly and securely. This is quick (it can be done in a month), but for large corporations, it's not considered sufficient. Type II, on the other hand, involves daily process monitoring over a period of 3, 6, or 12 months, which is the standard for enterprise deals.

It's also important to understand the appropriate scope. Quite often, companies mistakenly broaden their focus to encompass all company processes, while it's far more appropriate to narrow it – for example, to the production environment.

Finally, it's worth noting that attempts to implement all five trust criteria at once – Security, Availability, Processing Integrity, Confidentiality, and Privacy – often lead to team burnout. It's far wiser to take a step-by-step approach, starting with the Security criteria, which is typically sufficient for closing 90% of deals.

Controls That Break SOC 2 Audits Most Often

Passing a SOC 2 audit is a test of your discipline. Most companies fail audits not because of actual deficiencies in their IT infrastructure, but simply because they cannot demonstrate SOC 2 compliance with their own rules. Specifically, you may face non-compliance because of:

• Access control issues. If an employee leaves your company, but their access to GitHub, Slack, and other systems remains active after 24 hours, you'll receive a warning. This also includes shared credentials and the lack of MFA on nodes that process sensitive data. Ultimately, you'll need to provide the auditor with an offboarding log of when the employee left the company and when exactly their access was revoked.
• Imperfections in change management. SOC 2 requires that every code change be submitted through a pull request, peer reviewed, and documented. At the same time, any direct commit to main or bypassing CI/CD pipelines is considered a violation, resetting your monitoring period.
• Vendor management issues. Modern companies subscribe to dozens of services through a corporate card, which is a risk in the eyes of the auditor. So, if you use a third-party tool to process customer data but don't have its SOC 2 report, you haven't passed the audit.
• Poor incident response. A PDF file with an action plan isn't sufficient – you'll also need to prove that you conducted a tabletop exercise and that the logging system allows you to reconstruct the chronology of events. If an incident occurs and there's no documented trace of its investigation, the audit will fail as well.

Are you worried that these issues might affect you during the audit? Don't worry – just email or call us, and we'll handle all the preparation!

Evidence vs Documentation Gap

The main rule is that if something isn't in the SOC 2 documentation, it doesn't exist. This explains why auditors always require certain artifacts, including logs, tickets, screenshots with metadata, and so on. Recognizing this, some companies mistakenly begin collecting them manually at the end of the observation period.

However, the catch is that screenshots taken on the same day for the entire previous month look suspicious (and are therefore often rejected). Furthermore, manual documentation collection often leads to in-house team fatigue and stretched timelines. This is why it's so crucial to deploy automated evidence collection systems like Vanta or Drata in time – with them, the risk of human error will be reduced to zero.

Timeline Breakers

The main mistake many US companies make is rushing into an audit without fully understanding their readiness. So, let's look at what can disrupt your deadlines:

• Cultural friction. Engineers inherently dislike anything related to bureaucracy, so if your team perceives the need to create a ticket for every access or document every change as pointless work, they will sabotage processes.
• Breaking the clean window. Continuity is crucial in Type II audits, so if you forget to revoke a terminated employee's access mid-observation period or miss a quarterly risk review, the window will be considered “dirty” and, as a result, will restart the audit clock.
• Manual artifact collection. Manually collecting evidence through screenshots and log extracts quickly leads to errors and burnout – that's why it's so important to ensure timely automation through specialized platforms.
• Lack of single ownership. A specific person on your team (usually the CTO or Head of Operations) should be responsible for preparing for the SOC 2 audit. It's important that they have the resources and authority to do this; otherwise, tasks will endlessly bounce between departments.

As we can see, preparing for a SOC 2 audit entails a fair amount of routine work – so if you haven't yet addressed the needs described above, it could drag on for a long time.

Indicators of SOC 2 Readiness

If you can agree with these points, your company is definitely ready for preparation:

• You have a centralized identity provider like Google Workspace or Azure AD, whose policies are strictly enforced (meaning there are no orphan accounts, and access to all corporate resources is managed through a single point);
• Your production environment is isolated, ideally by completely eliminating SSH access for individual engineers (access itself is granted only through automated systems or privilege management systems);
• You have implemented change management policies: the development process via pull requests has become standard practice, and every change undergoes peer review with subsequent automatic saving of each action;
• You have centralized logging configured, meaning all logs are collected in one place and stored for the required period, making it possible to reconstruct the history of events for a specific request.

If you haven't checked all the boxes on our SOC 2 compliance checklist, you can contact us, and we'll quickly address these and other, less obvious gaps.

Reasons to Hold Off on SOC 2

Obtaining a SOC 2 certification isn't always justified. In particular, if your IT infrastructure features any of the following characteristics, you have to consider whether you should abandon or at least postpone this idea:

• Using shared root passwords (e.g., for servers or databases that are shared via Slack or stored in shared notes);
• A ClickOps culture, according to which infrastructure changes are made manually through the AWS/Google Cloud console rather than through code (the fact is that any manual changes are almost impossible to trace and prove their legitimacy to the auditor);
• Lack of separation of production and development environments – that is, when developers have the same rights in production as in the development environment, or if test data is mixed with real customer data.

The absence of a process owner empowered to change the company's operational practices is also considered a compelling reason to postpone the audit.

Role of External Partner

When a company decides to obtain SOC 2 certification, it faces a dilemma: handle everything in-house or engage an external expert. However, given that the first option drags out preparation for many months, the second is often more cost-effective, especially when an external expert can both provide recommendations for optimizing the existing IT infrastructure and propose a new compliance system architecture. For example, WEZOM performs the following tasks within such projects:

• Gap analysis. We conduct an end-to-end audit of current processes even before the official auditor sees them, to find and fix hidden issues such as missing logs or gaps in access policies.
• Translating audit expectations into specific engineering requirements. SOC 2 requirements are often formulated in compliance language, which is incomprehensible to the average DevOps engineer. To eliminate this problem, we translate the abstract idea of ”ensure change control” into a specific issue in Jira.
• Support during the remediation phase. In addition to identifying issues, we also assist with remediation: implementing Terraform scripts, configuring the identity provider, building synchronous processes, and more.
• Preventing costly restarts. The biggest frustration in a SOC 2 audit is having to restart monitoring due to a minor error. This is precisely what we can help you prevent.

Are you thinking about obtaining a SOC 2 certification? Feel free to  contact us, and we'll be your reliable support in preparing for your audit!

Business Risks of Delays

For American companies, the lack of SOC 2 certification can be detrimental in the following ways:

• Lost deals. While you're debating whether you need certification, your potential clients are leaving for competitors who do;
• Delays in existing contracts. Many large clients include a clause requiring SOC 2 certification within a certain timeframe; failure to comply with this deadline can lead to payment freezes or contract termination;
• The need to justify yourself to clients. Instead of communicating the benefits of your product, your sales reps are forced to fill out multi-page security questionnaires and explain why you haven't yet received certification.

Ultimately, SOC 2 certification is an indicator of a company's maturity, while its lack can delay a company's due diligence.

Practical Pre-Audit Advice

Now, when you’ve understood “What is a SOC 2 report?”, it’s time to start pre-audit. In particular, to help companies move toward SOC 2 certification as quickly as possible, we typically follow this scenario:

• Narrowing the scope to production only. We don't attempt to certify absolutely everything, especially if the infrastructure is large. It's better to limit the audit scope to only those elements where client data is stored and processed.
• Selecting security criteria. SOC 2 allows you to select criteria. Therefore, if this is your first audit, you can select only the basic set of criteria – Security. You can add Confidentiality or Availability next year, once the processes have been streamlined.
• Using bridge letters. If your Type II report is complete and a new one is not yet ready, we recommend using bridge letters, which is considered standard practice in the US, to confirm to the client that system and organization controls 2 are still in place.
• Conducting a tabletop exercise. Finally, you’ll need to rehearse an incident scenario (e.g., a data breach) with your in-house team. This will be the best way to verify the true readiness of the incident response process before an independent auditor does.

Overall, audit preparation typically takes between a couple of months and a year, while the audit itself lasts 3-12 months (for Type II), so you must manage your timelines wisely to satisfy both your clients and, of course, the auditor.

SOC 2 Cost Expectations for the US Market

In this section, we’d like to answer the question: “How much does a SOC 2 audit cost?”

Generally speaking, the SOC 2 cost should be estimated on time, as in addition to the cost of the audit itself, it includes the costs of tools, consulting, and formal verification, too. For example, for most B2B companies, the total first-year costs (from preparation to receipt of the Type II report) range from $50,000 to $85,000. This implies:

• Preliminary audit and gap analysis – these cost items typically range from $5,000 to $10,000 and involve an external tech partner or automated platform identifying inconsistencies in your processes and creating a detailed remediation plan. 
• Remediation and SOC 2 compliance software licensing – this will cost you around $15,000-$30,000, including subscriptions to SOC 2 security compliance automation tooling like Vanta or Drata, implementation of solutions like Okta or a logging system, and hiring consultants to help you align your existing infrastructure with SOC 2 standards.
• CPA firm fees – this SOC 2 compliance cost item varies within the $20,000-$40,000 range, but ultimately the price will depend on the auditor's reputation and the complexity of your system. It's important to remember that a Type II audit is always more expensive than a Type I audit due to the length of the monitoring period.

If you're looking for a technology partner to help you pass the audit on the first try at minimal cost, just email or call us.

FAQ