Preface

In the B2B SaaS start-up andscale-up space, especially in the USA, SOC 2 reports are considered a “must-have” to sell to larger clients successfully. Based on helping dozens ofSaaS companies achieve the SOC 2 Type II attestation reports, we can confidently state that there is a lot of confusion and misunderstandings about SOC 2, its requirements, the audit process, and the whys and hows. This article aims to help SaaS companies and consulting firms understand the basic concepts of SOC 2 andanswer the most important questions, such as how you do it, how long it takes, how much it costs, and what effort is required.

TL;DR: SOC 2 is an audit methodology that defines certain controls (Trust Service Criteria) for which your company will be audited. The audit process will validate whether the controls are established and effectively operated, the auditor will issue an attestation letter stating that. The attestation letter states that in the CPA firm opinon you have established and/or effectively operated the controls. SOC 2 Type I (1)report will focus on the control establishment at a given date (point in time audit), and Type II (2) will validate control establishment and effective operation for a specific time period (called observation period) of the past (for example, between 1 Jan 2025 – 31 March 2025).

SOC 2 reports are lagging measures by default as the audit methodology requires validation of objective evidence (for example, a bug ticket addressing the process of closing a reported application vulnerability). Your job as a business owner is to operate everything securely, continuously collect evidence, then validate the observation period (minimum 3 months, maximum 15 months) by an independent CPA firm, get the report, and, if requested, share it with your current clients and future prospects (only after NDA is signed) showing that you had things in order for the observation period.

Okay, you probably already knew this (or could have known this) by searching online for SOC 2, checking Wikipedia, or asking your favorite Gen AI copilot/prompt. To get to the meaty stuff, I have to dig into the history of auditing to provide context. There is a wall of text below, and you can jump to the important questions and answers section here.

History – Auditing IT Systems, SAS 70, SSEA 16, IASE 3402 and 3000

SAS 70

It all started with financial audits. I mean the audit, where you imagine the bookkeeper company comes in, checks the financial records and ledgers, and gives a report stating all checks and balances are OK. The company being audited should have internal controls preventing fraud, embezzlement, cheating, etc. These audits in the USA (and other countries) were conducted by Certified Public Accountants (CPA). To create a standardized reporting format over internal controls impacting financial reporting,  the American Institute of CPAs (AICPA) issued the “Statement on Auditing Standards No. 70 (SAS 70)” as a recommended methodology for auditing controls in 1992. As part of the financial audits, the auditor firms checked on some IT controls too (like who has access to the accounting software, etc.)

The result of the SAS 70 audits was a letter from the CPA firm stating that internal controls over financial reporting were effectively operated. During the 1990s and early 2000s, outsourcing and offshoring boomed, and companies placed their payroll, accounting, and IT operations with external firms. These “external firms” called service organizations started to use SAS 70 reports as part of their marketing/sales efforts, which became problematic as the scope of the report was explicitly financial controls, not general IT, data security, or privacy controls.

During this period, auditing internal controls over financial reporting became a challenge for the CPA firms, as each company designs its controls (for example, company A has implemented the four-eye principle for large payments [like the CFO and CEO required to send the payment], at company B all payments were only made by the CEO), no “standard set” of controls existed.

Each company was responsible for designing its own control set as it seemed to fit the organization's operation and objectives (it was the accountant's version of “Wild Wide West”).

SSAE 16 – SOC 1 and SOC 2

Based on the CPA firm's feedback and the market demand for IT-specific attestations, the AICPA issued the Statement on Standards for Attestation Engagements No. 16 (SSAE 16) in 2010, which replaced SAS 70 and was aligned with the ISAAB (International Auditing and Assurance Standards Board established in 1978) 3402 auditing methodology (brace yourself and don’t lose track of the abbreviations).

The SSAE 16 brought several significant changes:

• SOC 1 audit reports were introduced, and they effectively function as SAS 70 audits, e.g., focusing on controls related to financial reporting. The service organization can design its control framework.

• SOC 2 audits focus on controls related to the set of predefined Trust Service Principles/Criteria—a fancy name for a set of controls that the AICPA defined to address the broader IT and data protection requirements split into five categories: Security, Availability, Process Integrity, Confidentiality, and Privacy. The TSC enables CPA firms to assess everyone for these controls “equally.” SOC 2 reports are for limited release due to the sensitive information they may contain. The reports are not for public release.

• SOC 3 reports, which are actually a summary and general-use format of the SOC 2 report, that can be shared with anyone.

The biggest change is the split of reporting on controls impacting financial reporting (SOC 1) and general(ish) IT controls (SOC 2).

The timing was perfect; in the early 2010s, cloud computing, including SaaS solutions, started to take over, and sensitive data quickly accumulated at cloud service providers. Of course, this led to significant data breaches. That kicked in third-party assessments, which the SOC 2 reports addressed perfectly. As CPA firms were already “in-house” doing audits on the books (accounting), they easily accessed clients and provided the SOC 2 audits.

SSAE 18 – The present

AICPA updated the standard in 2017, aligning the requirements with COSO’s (Committee of Sponsoring Organizations of the Treadway Commission) Internal control framework – this is a general best practice list for companies to manage (financial and operational) risks, prevent fraud, and operate prudently.

Sidenote: The creation of the COSO framework was driven by the Enron, WorldCom, and other scandals.

The Trust Service Criteria was last updated in 2020 (mostly related to privacy controls), and I’m sure AICPA will continuously update the TSC and its methodology.

While SOC 2 provides a comprehensive set of controls, it is not a formal standard. A formal standard is a strictly formalized set of rules, guidelines, or specifications, and the current information and cybersecurity standards are the members of the ISO/IEC 27000 family, PCI-DSS, or NIST 800-53. We can consider SOC 2 (of its Trust Service Criteria) as an informal standard, and having a SOC 2 report had essentially become a requirement for software companies aiming to cater to clients in finance, healthcare, or Fortune 500 sectors by the mid-2010s in the USA. As of now, in Europe and the APAC region, it has become equivalent to the ISO/IEC 27001:2022 certification.

Okay, I try not to compete with the “Hardcore History” podcast by Dan Carlin (known for its lengthy sessions of 3+ hours), but there is more. Now that we understand the history, we can look at the whys and hows.

The important questions

Cyber(information) security is a marathon, not a sprint. It's not enough to reach a certain security maturity level; it needs to be maintained and (hopefully) improved. How does it look from a SOC 2 perspective?

TL;DR#2: The information below is based on a thought experience imagining a 25-strong, fully remote SaaS company developing a CRM platform operated on AWS and you are going for SOC 2 Type II with 3 month observation period.

1) DIY manually (word/docs, excel/sheet, project management tool) spending time on understanding and implementing requirements,

2) DIY with GRC tool – pay a fee for a tool, spend time on understanding and implementing requirements with the guidance of the GRC tool

3) The Way of the Consultant – utilize a consultant who done this dozen of time, taking as much of your shoulder as possible no matter if it is manual or GRC tool implementation. Ease of mind, speed, effectiveness.

It depends on where you are, how much implementation is needed, whether you have tech debt, and whether you are already following best practices.

DIY manual—If someone does not know the requirements or has no security/compliance experience, I could not imagine a duration of less than 3-4 months (not actual work hours) for implementation and a 3-month observation period after that. This is a very optimistic estimate!

DIY GRC tool -  If someone does not know the requirements or has no experience, I think it is possible to have 2-3 months of implementation and a 3-month observation period after that.

The Way of the Consultant  - 4 weeks for implementation + 3 months observation period.

How to get there? (with details)

You have several options to do it. I’ll outline the most common scenarios and paths for SaaS companies that, in this scenario, use major CSPs (AWS, Azure, GCP) and operate remotely (no on-premises infrastructure).

The DIY manual– bare knuckles

You do your homework and know that the SSEA 18 and the TSC are published on the AICPA website. After a short registration, you download the PDF. You spend countless hours understanding what the actual requirements are and which ones are relevant to you (start with common criteria, aka security requirements only) and figure out how to implement them. Maybe you feed the PDF to an LLM and save dozens of hours.

You create your own policies and conduct your own risk assessment, design the control framework, and implement the controls (if you are not familiar with general information, cloud, and endpoint security practices and tools, along with “compliance speak,” this will be a steep learning curve, with several peaks to hike).

You are smart, and you know that you need to collect evidence for the observation period and set up a sustainable security and compliance framework. You spend significant time explaining what and why needs to be done to get everyone on board internally.

Because you are smart and want to show results to your clients, you set the observation period at the shortest possible three months. Once you feel ready, you engage with CPA firms and manage the audit process, providing samples, explanations, and objective evidence to address the requirements. They send sheets where you provide answers and files. After the 4-8 weeks audit process, you wait 2-6 weeks to get the SOC 2 Type II report, which attests that during the observation period (the three months), you have effectively operated the controls.

Pop the champagne, celebrate, and happy days! Because you are smart, you don’t forget to keep operating the controls and continuously collect evidence, as after one year, your report covering the initial three months period kind of expires, and your client will ask about the time between the end of the initial report and now. But you have done your homework, so you know that 12 months later, you will redo your SOC 2 audit again, and after it is done every 12 months, you will follow the cycle.

The DIY – GRC tooling

You have heard nightmare stories from your peers about the DIY manual SOC 2 process, and you are smart, cunning, and can use search engines. You find a GRC tool, you book a demo, and you hear the right words: streamlining, automation, hundreds, thousands of happy clients, audit portal, minimal effort. You like it! You are on board! You connect your cloud systems, start checking dashboards in the tool, and create action lists, while the system will guide you if you are building your product, servicing your client, improving the team, or simply just running your business as a start or scale up, the effort will take significantly junk of your time. Mostly spent on trying to make sense of the requirements and how to operationalize them.

You will realize that not everything is automated or automatically collected, and you need to spend time crafting reports, screenshotting tickets, dashboards, and other evidence to upload them to the GRC tool. The tools are great; we love them because they provide explanations and samples. Still, if you DIY, this will take time. Hopefully, you will not get distracted or delayed as you paid for something that is not fully utilized, and the ROI you imagined initially is not realized.

You get a minimum three-month observation period audit, and as you are smart, you set up your operational framework. The tool will tell you if something needs to be done (if you configured it properly) or if evidence has expired. The best way is to set up your project management system to keep track of the activities.

The Way of a Consultant

You are building your product. You are getting questions, assessment sheets, and requests from your clients and prospects. You are busy, and you want to get things done. You hire a consultant, for example, us (the Security Consultants team) or any decent professional.

During the scoping call, the consultant will ask the following questions (or very similar ones):

• Your elevator pitch, e.g., what service/solution you are providing, what kind of data is involved (and regulated industry, what your vertical is, etc.). This immediately helps in understanding the complexity and threat landscape.

• Your tech stack, AWS/GCP/Azure, let's stick with AWS. The consultant will ask for what services you are using: ECS or Fargate, Lambda or EC2, AWS RDS, or MongoDB vs MySQL running on an EC2. Is CloudWatch, CloudTrail, or Security Hub enabled? This will help the consultant to understand the shared responsibility model (EC2 requires patching and vulnerability management at the OS level, while Lambda does not), your probable security maturity, and possible technical debt.

• Your operational model, e.g., employees or contractors, remote or office-based, company-owned devices or private laptops. These questions are aimed at understanding the complexity of the upcoming implementation; for example, SOC 2 mandates laptop encryption and the use of AV, which can be a challenge if everyone is using private laptops.

• Any hard deadline, clients/prospects banning on the table demanding the promised SOC 2 report?

Once the consultant understands the situation, it will explain the different options for implementation that are similar to the DIY way, e.g., manual processes vs using a GRC tool. The difference here is that the consultant will take care of the majority of the tasks, but you need to provide input and make calls. The overall effort on your side depends on the factors explained above (your threat landscape, complexity, and technical debt).

In our scenario, let’s say you are a 25-strong SaaS company developing a CRM solution operated on AWS with a standard tech stack and a fully remote setup where you ship a Mac to all staff members. In this case, your involvement will be somewhere between 15 and 25 hrs, where the biggest effort will be the risk assessment (approx 3 hours), policy reviews (2-4 hours), internal process operations like customizing staff on and offboarding checklist, getting background check process implemented, and some AWS hardening that you might not have (VPC flow log, immutable logging with proper retention period, alerts, tightening security groups, etc), and meet with us on the weekly progress meetings.  

If you are using a consultant, your implementation effort with minimal variables is independent of using manual methods (sheets, documents, project management tools like ClickUp, Asana, Notion, Jira, Linear, etc.) or a GRC tool.

The benefit of using a GRC tool

Using a GRC tool provides two significant and fundamental differences in the long run:

User experience (internal and external): Having everything in one place, with proper visualization like dashboards, lists, and control checks, does make a difference internally. Utilizing the trust center features provided by the GRC tools also makes a difference externally for your clients and prospects. It just looks professional.

Maintenance effort — In the long term (12 months+), collecting all the evidence and tracking tasks, reports, and statuses is more manageable with a GRC tool. While manual uploads are still required, automated evidence collection via APIs reduces manual effort, hence the overall hours and resources needed.

The manual process does not require an extra fee for the GRC tool, and in the long run, the GRC tool provides economy and a better user and client experience.

However, using a GRC tool helps to collect evidence continuously over the observation period. The CPA firms must meet with the mandated audit methodology, meaning that they are testing controls based on prescribed sample frequency; for example, if you run monthly vulnerability scans on your external surface (web app and public-facing IPs), this means that over a 12 month period, you must have collected 12 evidence of the scans being run aka scan reports. The CPA firm must validate 50%+ of the samples, e.g., at least six scan reports, and if you can’t provide those, you are failing the audit, and it will be displayed in the testing section sounding something like this: “Exception noted, X% of the six samples were not presented indicating the control is not being operated.” A sentence that you don’t want to show to your next potentially big customer.

Hence, setting up the proper control operation and compliance evidence collection process is really the key here because one mistake can ruin years' worth of effort.

How long it takes?

The honest answer is: it depends. But “it depends” is not a particularly useful answer, so let’s break it down properly. The key variables that drive the timeline are: your current security posture (how much still needs to be implemented), the amount of technical debt in your infrastructure, your team’s bandwidth and responsiveness, and whether you have any hard client deadlines pushing the schedule.

Using the same 25-person remote SaaS scenario from before, here is a realistic breakdown:

DIY — bare knuckles: Expect 3–4 months of implementation before you are even ready to start the observation period. This assumes you are disciplined, reasonably security-literate, and not distracted by your actual job of building a product and serving clients. Add the minimum 3-month observation period on top, and you are looking at 6–7 months from start to report — at the very best.

DIY — GRC tool: The tool guidance shortens the learning curve. Realistically, 2–3 months of implementation followed by the 3-month observation period puts you at roughly 5–6 months total. The caveat: this assumes you actually configure and use the GRC tool consistently, which is harder than it sounds when product deadlines are competing for attention.

The Way of a Consultant: Approximately 4 weeks for implementation (with your 15–25 hours of input), followed by the standard 3-month observation period. That means a report in your hands roughly 4 months after kick-off. Add the 4–8 week audit process and 2–6 weeks for the CPA firm to issue the final report, and you are comfortably within 5–6 months from first conversation to signed attestation letter. Our service includes everything from the GRC tool, to cloud hardening (yep, we are engineers after all and can configure and harden AWS/Azure/GCP according to security and compliance requirements), endpoint device security, to penetration testing, and dealing with the auditors. You focus on your business, we deal with security and compliance.

One important note on observation period length: while 3 months is the minimum, there is a strategic reason to extend it to 6 or even 12 months from the second cycle onwards. A longer observation period covers a larger window of time, which reduces the “gap” clients notice when your previous report is aging. More on that in the maintenance section below.

How much does it cost?

SOC 2 has three cost buckets: implementation, tooling, and the audit itself. The proportions shift significantly depending on which path you choose.

Implementation cost:

- DIY means your cost is measured in time rather than money — but time is money, especially at a company during growth period. So if you have time to understand the requirements, conduct the risk assessment, draft review and fine tune the policies, set up your security and operational activates and operate them, hire a penetration tester, run vulnerability scans, find and negotiate with the CPA firm, manage the audit process, then this is your way. At the minimum we are talking here 80-100 hours of work (even if you are using a Gen AI and template sets available), what is your hourly rate as a CEO/CTO/COO, etc? At least 100$ / hour (I hope), easy math from here.

- A consultant engagement for a standard SOC 2 Type II scoped to the Security TSC (Common Criteria only) typically falls in the low-to-mid five figures. Complexity, scope, and technical debt will push that figure upwards.

GRC tooling: Most GRC platforms aimed at startups and scale-ups are priced in the range of a few hundred to a few thousand dollars per month, depending on the feature tier and company size. Over a 12-month cycle, this is a material but manageable line tem — and as discussed earlier, the long-term efficiency gains generally justify the spend once you are past your first audit cycle.

The audit (CPA firm): This is a painful but must have cost. The attestation must be issued by an independent, licensed CPA firm. For a Type II audit covering the Common Criteria (Security only), expect to pay in the range of $10,000–$25,000 for a reputable firm, though boutique firms with a SaaS focus sometimes come in below that range.Adding additional Trust Service Categories (Availability, Confidentiality,etc.) increases scope and cost proportionally. You don't want to have your SOC 2 report issued by a certificate mill (very cheap auditor firms, signing off more or less anything for a fee).

Total all-in cost for a first SOC 2 Type II — implementation, tooling, and audit —typically lands somewhere between $20,000 and $60,000 for a company in our reference scenario, depending on the path chosen and the CPA firm engaged. Subsequent annual cycles are less expensive, as the implementation work is largely already done and the audit scope becomes more predictable.

And don't forget you need to execute all relevant activates (risk assessment, policy review, penetration test, etc plus the audit) at least annually to always have a valid SOC 2 report covering your standard 12 month observation period.

What ongoing effort is required?

This is the question most people forget to ask before starting, and the one that causes the most pain afterwards.

SOC 2 is not a project with a finish line. It is an operational commitment. Getting the first report is the beginning, not the end. Here is what “keeping the lights on” actually looks like on an ongoing basis.

Continuous evidence collection: Every control that will be tested in the next audit needs to be actively operated and evidenced throughout the observation period. Vulnerability scans must run on schedule. Access reviews must be completed. Policies must be reviewed annually. Vendor assessments must be conducted. None of this happens on its own — it requires assigned ownership and a reliable tracking mechanism, whether that is a GRC tool, a project management board, or a well-maintained spreadsheet. Trust us on this (been done all variations and several times, you want to use a GRC tool).

Staff changes: Every time someone joins or leaves the company, the onboarding and offboarding process must be followed correctly and documented. Access provisioning, background checks, security awareness training acknowledgements, and access termination are all auditable events. A single poorly handled offboarding — a former employee’s account left active for three weeks — is the kind of exception that shows up prominently in the audit testing results. This is the easiest way to fail off the rail....

Infrastructure and product changes: When your tech stack evolves — a new AWS service adopted, a new third-party integration added, a new product environment spun up — the control framework needs to reflect those changes. Change management and configuration management controls exist precisely because auditors will look at whether your documented controls match your actual operating environment.

The annual audit cycle: Approximately 12 months after your observation period ends, you will need to go through the audit process again. The good news is that subsequent audits are significantly less burdensome than the first one. The policies, the control framework, and the operational processes are already in place. The audit is then primarily a matter of presenting evidence that you kept doing what you said you were doing. The challenge is simply that you actually need to have kept doing it.

In practice, the ongoing monthly effort for a well-structured SOC 2 program at a 25-person SaaS company is modest — typically a few hours per month across the team, rising to a few days in the weeks immediately before and during the audit. The keyword is “well-structured.” Companies that treat SOC 2 as a box-ticking exercise and let evidence collection slip find themselves scrambling before every audit, which is both stressful and costly.

Final thoughts

SOC 2 is not magic. It does not make your company secure — security is what makes your company secure. SOC 2 is the independently verified, standardized way of demonstrating that security to your clients and prospects. That distinction matters, because companies that pursue SOC 2 purely as a sales tool, without genuine commitment to the underlying controls, tend to end up with reports full of exceptions and operational processes that fall apart between audits.

Done well, a SOC 2 program is genuinely valuable. It forces clarity around your security posture, surfaces technical debt before it becomes a breach, and creates internal accountability that benefits the entire organization. The attestation report is the output — the improved security maturity is the real return on investment.

To summarize the key points from this article:

• SOC 2 is an audit methodology, not a certification. You receive an attestation report from a licensed CPA firm, not a certificate from a standards body.

• Type I validates control existence at a point in time. Type II validates that controls were effectively operated over a defined observation period. Clients will almost always ask for Type II.

• The path you choose (DIY, GRC tool, or consultant) primarily affects speed, internal effort, and risk of failure — not whether the outcome is achievable.

• Total time to first report ranges from roughly 5 months (with a consultant) to 7+ months (fully DIY). The audit itself takes an additional 6–14 weeks on top of the observation period.

• SOC 2 is an annual commitment. The ongoing operational burden is manageable if the framework is set up correctly from the start — and painful if it is not.

If you are a SaaS company evaluating your options or working towards your first (or next) SOC 2, we are happy to have an initial scoping conversation at no cost. We have helped dozens of companies through this process (and helped them to sell to Amazon, Siemens, Disney, Bank of America, Google, Zeiss, etc) and a 30-minute call is usually enough to give you a clear picture of where you stand, what is involved, and what a realistic timeline looks like for your specific situation.

‍

About the author:

Attila Horvath the founder and CEO of Security Consultants, and been working in the security space for 23+ years, which of one and a half decade spent in the enterprise space working at smallish companies like Vodafone, AXA, Royal Bank of Scotland, Bank of Tokyo. Since 2019 he has helped 150+ SaaS companies to address security, privacy and complaince needs, and continously working to provide qulity focued consulting services. Security Consultants are ISO/IEC 27001 certified, member of the Cloud Security Alliance, ISACA, ISC2 and having an amazing team of security consultants to help clients to sell to enterprises.

‍