Skip to content
Compliance8 min read

SOC 2 Compliance Software Built for Audit Readiness

A successful SOC 2 program requires more than a software platform; it needs a defined audit scope, closed remediation gaps, and organized evidence before the independent examination begins. Compliance software centralizes controls and evidence, while expert support covers the scoping, remediation, and audit preparation that still require human judgment.

JP
Written byJohn Price
Share

SOC 2 Reports Measure Control Operations, Not a Pass/Fail Grade

A licensed CPA firm issues a SOC 2 report, which is an independent opinion on how your controls operate. SOC 2, or Service Organization Control 2, is a reporting framework from the American Institute of Certified Public Accountants (AICPA). The framework examines the controls that support the security and reliability of the service you provide to customers against a defined set of Trust Services Criteria.

The Trust Services Criteria define what the CPA firm evaluates. Every SOC 2 examination includes Security, which looks at how the organization protects systems and data from unauthorized access.

The other criteria added when they are relevant to the service include:

  • Availability: assesses how the organization keeps systems accessible and performing as promised to customers.
  • Processing Integrity: evaluates whether the organization processes data completely, accurately, and on time.
  • Confidentiality: examines how the organization protects information that should remain restricted.
  • Privacy: reviews how the organization collects, uses, retains, discloses, and disposes of personal information.

SOC 2 reports come in two forms, depending on whether the CPA firm is evaluating controls at a point in time or over a period of operation. A Type I report evaluates whether the controls are suitably designed as of a specific date. A Type II report evaluates whether those controls operated effectively over a defined period, and most enterprise buyers ask for the Type II.

A SOC 1 report covers controls that affect a customer's financial reporting. A SOC 3 report covers the same general subject matter as SOC 2 but presents the results in a shorter public-facing form suitable for publishing on a website.

Follow These 7 Steps to Prepare for Your SOC 2 Audit

To prepare for a SOC 2 audit, your team should first define the audit scope, assess controls against the Trust Services Criteria, and close every identified gap. The process ends with engaging a licensed CPA firm to conduct the independent examination and issue the final SOC 2 report.

1. Define your audit scope before collecting evidence

Define your audit scope before you collect any evidence. Your team needs to decide exactly what the SOC 2 examination will cover, which systems support the service, and which people administer them.

Scope also depends on your services and customer commitments. If customers rely on your platform being available 99.9% of the time, Availability may be added alongside the mandatory Security criteria. Confidentiality may also apply when your service stores or processes confidential customer information.

Those scoping decisions determine the controls you need, and they shape every policy, evidence request, and remediation task that follows. Collecting evidence too early risks gathering records for systems that do not belong in the examination while missing evidence for systems that do.

2. Assess Controls Against the Trust Services Criteria to Find Gaps

A gap is a control that does not exist or operates inconsistently. It can also be incomplete evidence, unclear ownership, an outdated policy, or a security weakness that needs remediation.

Most companies already have some of the practices SOC 2 expects before they begin the process. Employees may already need approval before getting access to important systems, developers may already review code before it goes live, vendors may already go through a security check, and the company may already have a process for responding to security incidents.

The assessment looks at those existing practices to see which ones already meet the SOC 2 requirements, which need stronger evidence or documentation, and which controls still need to be added.

The assessment must go deeper than identifying what is missing. It needs to establish why the gap exists and what has to change. A missing record and a control that never operated as documented are different problems, even when both first appear as the same blank box.

3. Update Policies to Match Actual Business Operations

Policies describe how your organization says it manages security and compliance. The procedures and evidence behind them need to show that those practices actually happen.

For example, an incident response policy may state that the company tests its incident response plan every year. If no test took place, the problem is not simply an outdated document. The underlying process has not operated as described. The company needs to perform the test, retain evidence of it, and make sure someone owns the recurring requirement.

The opposite problem also occurs. A company may already review vendors before giving them access to sensitive systems, but its vendor management policy may still describe an older approval process. In that case, the operating practice may be sound while the documentation needs updating.

The assessment therefore needs to determine what should change. Sometimes the policy needs updating to reflect a valid existing process. In other cases, the business process needs to change to meet the control requirement. If both are out of alignment, both need correction.

4. Assign Owners and Deadlines to All Remediation Tasks

Once the assessment identifies a gap, turn it into a remediation task with a clear owner, deadline, required action, and evidence needed to show that the issue is closed.

Different findings require different fixes. A technical vulnerability may need an engineer to patch the affected system and provide evidence of the change. A missing vendor review process may require someone to define the review criteria, assess existing vendors, and establish a recurring schedule. An outdated policy may need both a documentation update and a change to the underlying business process.

Compliance software keeps each finding connected to the control, risk, remediation task, owner, and supporting evidence. That gives the team one place to see what remains open and what has already been resolved.

Some findings still require expert judgment. The team needs to determine how serious the gap is, what remediation is appropriate, and what evidence will demonstrate that the control now operates as intended.

5. Consolidate all audit evidence in one workspace

Once a control is operating, you need evidence that shows it happened. That evidence may include access review records, security logs, approval records, policy acknowledgments, vulnerability scan results, or screenshots from systems in scope.

Without one place to manage those records, evidence ends up spread across spreadsheets, shared folders, email threads, screenshots, and separate systems. SOC 2 compliance software connects evidence to the control it supports, making it easier to see which controls have sufficient documentation and where evidence is still missing.

A compliance workspace keeps controls, evidence, policies, findings, and risks connected, giving the team a clearer view of the audit trail and where documentation is still missing.

Evidence also needs context. A screenshot showing that a user exists in a system does not prove that someone approved the access. A completed access review may still be weak evidence if it does not show who performed the review, when it happened, or what action followed.

6. Reuse SOC 2 Controls Across Other Frameworks When Relevant

If your organization also works toward ISO 27001, HIPAA, PCI DSS, or another compliance framework, you may not need to build a separate control for every requirement.

Many frameworks address similar security practices. For example, SOC 2 and ISO 27001 both include requirements around controlling access to systems. Instead of running one access review for SOC 2 and another for ISO 27001, the organization may use the same underlying access review process and map it to the relevant requirements in both frameworks.

A shared-control approach keeps one underlying control and its evidence connected to the requirements it supports across different frameworks. The organization still needs to identify where requirements overlap and where another framework requires additional controls or evidence.

The overlap is not always exact. A control that supports a SOC 2 requirement may satisfy only part of an ISO 27001 or HIPAA requirement. Mapping shared controls reduces duplicate compliance work and lets the organization manage one control environment instead of maintaining separate versions of the same process for every framework.

7. Complete the Independent Examination With a Licensed CPA Firm

The final stage is the independent SOC 2 examination performed by a licensed CPA firm. By the time formal testing begins, your scope should be defined, controls should be operating, evidence should be organized, and major findings should already be resolved.

The CPA firm reviews the controls in scope, examines the supporting evidence, tests how those controls operated, and forms the independent opinion that appears in the SOC 2 report.

Budget for the Full Cost of SOC 2 Audit Cycle

The software subscription is only one part of the cost of SOC 2. Your total budget also needs to account for advisory support, the independent CPA examination, remediation, security testing, and the time your internal team spends on the program.

  1. Scoping and advisory support: Companies without an experienced compliance lead may need outside help to define the audit scope, assess existing controls, identify gaps, review policies, and plan remediation. SubRosa provides this support when additional compliance expertise is needed.
  2. Remediation costs: The readiness assessment may uncover controls that need to be added or strengthened before the examination. Remediation may involve engineering changes, access control improvements, new processes, policy updates, or additional security tooling.
  3. Security testing costs: Your risk assessment or control environment may call for penetration testing, vulnerability scanning, or other security testing. These costs sit outside the compliance platform and should be identified early enough to avoid delaying the examination.
  4. CPA firm examination fees: A licensed CPA firm charges separately to perform the independent examination and issue the SOC 2 report. The fee varies with factors such as the scope of the examination, the number of systems and controls involved, and whether the engagement covers Type I or Type II.
  5. Internal team time: Engineering, IT, operations, security, and leadership still need to review controls, approve policies, implement fixes, provide evidence, and answer audit questions. A platform and external support reduce the administrative burden, but they do not remove the need for internal participation.

Looking at all five costs gives you a more realistic SOC 2 budget than comparing software subscription prices alone.

Keep Your SOC 2 Program Current Between Examinations

The first SOC 2 report captures the control environment during a specific examination period. The business keeps changing after that period ends, so the controls and evidence need to change with it.

New employees receive access. Existing employees change roles. Vendors are added. Systems move into production. Products evolve. Customer commitments change. Each of those changes affects a control that supported the previous examination.

Ongoing SOC 2 work therefore includes reviewing access, updating risk assessments when the environment changes, testing security and incident response processes where required, keeping policies aligned with actual operations, and collecting evidence for controls that continue to operate.

Sable keeps the continuing record of controls, evidence, policies, risks, and findings in one place, giving the team a clearer view of what has changed since the previous examination.

Where those changes affect the control environment, SubRosa supports the judgment required to determine whether a control needs updating, new evidence is required, or additional remediation should happen before the next examination.

Maintaining SOC 2 therefore means keeping the control environment current rather than rebuilding the program when the next audit approaches.

Frequently Asked Questions About SOC 2

What is the difference between SOC 1 and SOC 2?

SOC 1 focuses on controls that affect a customer's financial reporting. SOC 2 focuses on controls related to Security and, where relevant, Availability, Processing Integrity, Confidentiality, and Privacy. SaaS and technology companies usually pursue SOC 2 when customers want assurance about how the service protects systems and data.

How long does a SOC 2 Type II report take?

The timeline depends on how prepared the organization is before the examination begins. A first-time SOC 2 Type II project usually includes scoping, gap assessment, remediation, an observation period during which controls need to operate, and the CPA firm's examination and reporting work.

Organizations with mature controls and organized evidence move through readiness more quickly. Companies that need significant remediation, new policies, or changes to security processes should expect the preparation stage to take longer. The CPA firm will also agree on the observation period and examination timeline with the organization.

Do I need a penetration test for SOC 2?

SOC 2 does not require every organization to complete a penetration test. The organization needs security controls that address the risks relevant to the systems and services in scope.

A penetration test is part of that security program when it is appropriate to the organization's risk profile, infrastructure, customer commitments, or control design. Other organizations rely on vulnerability scanning and additional security testing alongside their broader vulnerability management process.