Introduction to SOC 2

Service Organization Control (SOC) 2 is an information security audit framework developed by the American Institute of CPAs (AICPA). It provides assurance that a service organization has implemented effective controls to protect customer data across security, availability, processing integrity, confidentiality, and privacy. In practice, SOC 2 has become a de facto requirement for B2B startups to establish trust with customers and is also a requirement for some regulators as well. By earning a SOC 2 report, companies demonstrate a strong control environment and commitment to enhanced data security, which can be crucial for closing deals in regulated or security-conscious markets.

SOC 2 is organized around five Trust Service Criteria (TSC) principals:

• Security: Protect systems and data against unauthorized access or modifications (i.e. enforcing access controls and encryption).
• Availability: Ensure systems remain operational and accessible (i.e. maintaining uptime and disaster recovery readiness).
• Processing Integrity: Guarantee that system processing is complete, accurate, timely, and authorized (i.e. preventing errors or unauthorized changes in data processing).
• Confidentiality: Safeguard sensitive information from unauthorized disclosure (through data classification, encryption, and access restrictions).
• Privacy: Properly collect, use, retain, and dispose of personal information in line with commitments and privacy principles (e.g. GDPR or other privacy laws).

To meet the above criteria, organizations implement controls in several broad categories:

• Logical and Physical Access Controls: Restricting access to systems, networks, and facilities.
• System Operations and Monitoring: Oversight of system activities, incident detection, and response.
• Change Management: Procedures to manage and track software/infrastructure changes.
• Risk Assessment & Mitigation: Identifying risks and implementing measures to reduce them. 

Auditors will expect to see documented policies and technical measures in each area. For example, a SOC 2 audit typically reviews things like firewall configurations (network security), identity and access management, backup and disaster recovery processes, security incident response plans, and other critical operational procedures. By covering these control domains, SOC 2 provides a comprehensive check on an organization’s data security maturity.

(Note: SOC 2 reports come in two types. Type I evaluates the design of controls at a point in time (a snapshot of your control environment today), while Type II evaluates control effectiveness over an observation period, usually 3–12 months (SOC2 Compliance: A Comprehensive Guide to Certification). Resonance Security’s recent achievement is a SOC 2 Type I, indicating our controls have been designed and implemented properly as of the audit date. A Type II will be the next goal to prove these controls operate effectively over time.)

‍

The SOC 2 Journey

Achieving SOC 2 compliance is a multi-step journey that blends project management, data security engineering, and audit preparation. It’s not an overnight task, and can take anywhere from 2 - 6 months to achieve, – companies must systematically build out controls and gather evidence before an independent auditor can certify them. The journey is not an easy one, even for a company as security focused as Resonance Security. Below is an outline of how an organization typically attains SOC 2 Type I, based on our recent experience becoming certified:

1. Scoping and Gap Analysis: The process begins by determining the scope of the audit – which systems, products, and trust criteria will be included. Resonance Security decided to include our core SaaS platform under the Security criterion (and relevant common criteria) for Type I. A gap analysis is performed to compare existing practices against SOC 2 requirements. This helps identify control gaps early, such as missing policies or data security measures, so the team knows what to remediate.
   
   
2. Risk Assessment: An internal risk assessment is conducted to wrap our arms around hidden vulnerabilities and identify potential threats. This is a formal process where we catalog risks (e.g. “unauthorized access to production environment” or “data breaches from system failure”) and rate their likelihood and impact. The outcome guides which controls are most critical. For example, if the risk assessment flags a high risk of insider credential misuse, the company will prioritize strong access controls and monitoring. SOC 2’s criteria explicitly require a risk assessment process to ensure controls address the most relevant risks.
   
   
3. Policy Development: Documentation is a cornerstone of SOC 2. We created and updated a suite of data security policies and procedures covering areas like access control, acceptable use, change management, incident response, business continuity, and more. These policies formalize expectations (e.g. “All engineers must enable MFA and unique credentials for production access”) and provide a framework for governance. While writing policies can feel like a paperwork exercise, they are essential. Auditors verify that you not only have these policies, but also follow them in practice. Compliance automation tools often provide policy templates to accelerate this work, but tailoring them to actual processes at Resonance was key.
   
   
4. Implementing Controls & Technical Measures: With policies in place, the team proceeded to implement the actual data security controls and improvements.
    
5. Audit Readiness via Automation Tools: Throughout steps 3 and 4, Resonance Security leveraged a compliance automation platform to continuously monitor controls, gather evidence, and ensure audit readiness. Modern tools like Vanta, Secureframe, or Drata integrate with tech stacks to automate evidence collection, reducing manual effort and providing real-time visibility into compliance status. We connected our compliance tool to key systems such as Google Workspace (for MFA enforcement and IAM permissions), GitHub (for repo access and branch protection), AWS (for cloud security configurations), and our HR system (for onboarding/offboarding controls). These integrations automatically pulled critical data. For example, listing all AWS S3 buckets and flagging any with public access or verifying that all employee laptops had disk encryption enabled. Many evidence items came directly from cloud services via API, eliminating the need for manual collection. This was crucial in preventing data breaches caused by misconfigurations or human error.
   As the audit date approached, we compiled an evidence package directly within the compliance platform, including screenshots, configuration exports, policy documents, and system records demonstrating each control in action.

6. Audit Execution (with AICPA Auditor): Finally came the moment of truth – an AICPA-certified auditor (in our case, Modern Assurance LLC) was engaged to perform the SOC 2 Type I examination. Modern Assurance’s auditors are experienced in tech company audits and took a “trust but verify” approach. Over about a week of auditing, they reviewed all of our provided evidence and also held live interviews/demos with our team to validate the controls. For instance, they interviewed our DevOps lead to walk through how code changes are reviewed and deployed, verifying that our described change control process is real and not just on paper. They inspected configurations directly – we granted them read-only access to a portion of our compliance tool, so they could see for themselves the evidence. All of this culminated in the auditor’s report.
   Modern Assurance issued an opinion that Resonance Security’s controls were suitably designed to meet the SOC 2 Security criteria as of the audit date.

During the audit, having organized evidence was crucial. We gave Modern Assurance a structured list of artifacts mapped to each SOC 2 criterion. Using a platform like Secureframe or Vanta simplifies this hand-off: many auditors (including Modern Assurance) can be given guest access to the platform to directly review evidence items. In our case, evidence such as policy documents and screenshots of AWS settings were shared through a secure portal. The auditor examined items like our firewall rules, access logs, and onboarding checklists to verify compliance. Because we had done our homework with automation and pre-audit checks, the audit went smoothly with minimal back-and-forth. The output was a SOC 2 Type I report affirming that our controls (under the Security TSC and related criteria) are well-designed. This report can now be provided to customers under a NDA, giving them independent assurance of our security posture.

‍

Debunking SOC 2 Criticism

It’s often said in the security community that “SOC 2 is just a marketing checkbox” or a compliance rubber stamp. Critics point out that SOC 2 heavily emphasizes documentation, process, and attestation, rather than deep technical testing. There is some truth to the criticism, but it’s important to understand what SOC 2 really provides and why it’s still valuable, especially for a growing company like Resonance.

“SOC 2 is just a checkbox.” – False. While some might treat it as a mere compliance tick-mark to satisfy sales requirements, SOC 2 done right is far more meaningful. A SOC 2 report is not just a checkbox requirement; it’s a powerful tool for establishing trust and credibility in the SaaS market. The process of achieving SOC 2 forces a company to take a hard look at its security practices: you must document your procedures, implement controls, and prove you follow them. For a young company with limited formal process, this exercise can greatly improve discipline and security awareness across the team. The value of SOC 2 is in creating a baseline of security hygiene – things like regular access reviews, incident response drills, least-privilege access, change control, and so on become ingrained in how the business operates. Yes, the resulting certificate has marketing value (clients ask for it), but the journey towards it ideally leaves the company much stronger.

Focus on GRC over tech? It’s true that a SOC 2 audit will not dive deep into an application’s code quality or attempt to hack your networks. The audit provides a “snapshot of an organization’s controls at a point in time” and does not guarantee ongoing security or cover all possible threats. Notwithstanding, penetration testing and detailed vulnerability assessments are asked as a control for SOC 2, even if it’s not mandatory. This leads some to dub SOC 2 “security theater.” However, the absence of a mandatory penetration testing requirement doesn’t mean SOC 2 is useless. Think of SOC 2 as building the security foundation; it ensures you have the essential processes and controls from which more advanced security measures can grow. Penetration tests, code audits, and advanced threat detection can and should be layered on in addition to or after SOC 2. In fact, many criteria implicitly encourage such practices (for example, risk management and monitoring activities naturally drive a mature organization to do regular vulnerability scanning or penetration tests, even if not mandated). SOC 2 is a floor, not a ceiling for security programs. It establishes consistent policies and a control framework that young companies might lack, serving as a springboard to reach higher security maturity. Resonance Security recognizes that the framework we built for SOC 2 actually makes doing those things easier, because we now have clear ownership and procedures for handling security issues.

Another critique is that SOC 2 is too flexible – companies define their own controls and an auditor just checks if they follow their self-defined rules. This is by design. SOC 2 trusts each organization to implement controls suitable for their environment, rather than imposing a one-size-fits-all checklist. The downside is that one company’s SOC 2 report might be very robust, and others might be bare-bones, yet both get a “compliant” report. This is why savvy customers may still send security questionnaires or do their own assessments of a vendor, even if that vendor is SOC 2 certified – so they can know the specifics.

The bottom line: SOC 2 on its own does not make you invincible, and it’s not a guarantee against breaches. It does not replace technical security reviews, continuous monitoring, and penetration testing. Instead, SOC 2 should operate in tandem with those efforts. In the early stages of a company, achieving SOC 2 can jump-start a security program by introducing structure and accountability. It’s a way to prove to external parties (and to yourself) that you have baseline controls in place. From there, a culture of security can take root, dispelling the notion that it’s “just paperwork.” At Resonance, we treated SOC 2 compliance as an opportunity to level-up our internal processes and governance, not as a nuisance. By doing so, we’ve set ourselves on a path of continuous improvement rather than one-time compliance.

‍

Conclusion

Achieving SOC 2 Type I compliance is an important milestone for Resonance Security, but we recognize it’s not a silver bullet. Security is an ongoing journey. SOC 2 gives you a structured path to get the basics right and prove it via an independent audit. It’s a bit like earning a quality certification – it validates that we have the right controls at this point in time, and it lays a foundation to build upon. As we move forward, we will treat SOC 2 as a continuous process (preparing for Type II and annual renewals) rather than a one-time trophy.

For other security-conscious companies, our advice is to approach SOC 2 as an opportunity, not just a compliance obligation. If you only aim to “check the box,” you might get the report, but miss out on the real benefits. Instead, use the framework to instill data security best practices early in your company’s life. In doing so, you’ll not only satisfy your clients and auditors, but you’ll also reduce the likelihood of security incidents and data breaches and pave the way for scaling securely. From implementing least privilege access to automating audits in CI/CD, the effort you invest will pay dividends in resilience and trust.

Resonance Security’s successful SOC 2 Type I certification is a stepping stone toward long-term security maturity, but because we are a cybersecurity company, we’re fully aware that true security is a continuous endeavor. With the SOC 2 framework as our guide and an internal culture that values data security, we’re well on our way on that journey. SOC 2 is more than a badge for us – it’s a baseline we’re committed to exceeding. By sharing our technical journey, we hope to inspire others to seize SOC 2 compliance as a chance to build a stronger security foundation for the future.

‍

About the Author

Ilan Abitbol is a cybersecurity expert and a member of the Resonance Security team.