SOC 2 Type II Compliance

Prepare for your SOC 2 Type II audit with a security-led gap analysis. We assess your controls against the Trust Services Criteria, identify gaps, and provide remediation recommendations so you're ready when your independent CPA auditor arrives.

Start SOC 2 Readiness

Framework

Trust Services Criteria

Security

Protection against unauthorized access, both physical and logical. Firewalls, intrusion detection, MFA, and more.

Availability

Systems are available for operation and use as committed. Includes disaster recovery, failover, and performance monitoring.

Confidentiality

Information designated as confidential is protected as committed. Encryption, access controls, and data classification.

Processing Integrity

System processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives.

Privacy

Personal information is collected, used, retained, disclosed, and disposed of in conformity with commitments.

Our Process

Your Path to SOC 2

Readiness Assessment

Evaluate your current controls against SOC 2 Trust Services Criteria to identify gaps and priorities.

Control Design & Implementation

Design and implement controls that meet SOC 2 requirements while fitting your operational workflow.

Policy & Procedure Documentation

Create comprehensive security policies, procedures, and evidence documentation for audit readiness.

Evidence Collection & Audit Prep

Compile evidence artifacts, prepare walkthroughs, and conduct internal control testing before the audit.

Audit Support

Direct support during your independent auditor's fieldwork - helping you answer auditor questions, produce evidence, and address findings. The audit itself is performed by a licensed CPA firm, not SiegePal.

Overview

What is SOC 2?

SOC 2 (System and Organization Controls 2) is a compliance framework developed by the AICPA that defines criteria for managing customer data based on five Trust Services Criteria. It's the gold standard for SaaS companies and service organizations.

A SOC 2 Type II report evaluates the design AND operating effectiveness of your controls over a period of time (typically 6-12 months), providing assurance to customers and prospects that their data is protected. It's increasingly a requirement in enterprise sales cycles.

Type I vs Type II

SOC 2 Type I vs Type II: What the Difference Actually Means

A SOC 2 Type I report assesses whether your controls are suitably designed at a single point in time. An auditor examines your control environment, confirms that the controls you describe exist and are designed to meet the relevant Trust Services Criteria, and issues a report. It does not assess whether those controls were actually operating during any prior period. Type I is useful for demonstrating that a control program exists. It does not demonstrate that it works.

A SOC 2 Type II report covers both design and operating effectiveness over an observation period, typically six to twelve months. The auditor tests whether controls actually operated as described throughout that period. Evidence is collected for each control: access provisioning logs, change management records, encryption configuration screenshots, incident response documentation, and vulnerability scan results. Enterprise procurement teams increasingly require Type II because it demonstrates sustained operation, not just a point-in-time snapshot.

The practical implication is timeline. You cannot receive a Type II report without first completing the observation period with controls operating. Organizations that want a Type II report in twelve months need to have their controls designed and running within the first quarter. A readiness assessment and gap closure program that starts immediately is the only way to meet that timeline without extending the engagement or accepting a shorter, lower-credibility observation window.

Infrastructure Layer

What SOC 2 Requires at the Cloud Infrastructure Level

Access Control and IAM

The SOC 2 Security criterion covering logical and physical access controls requires that access to systems is restricted to authorized users, that provisioning and de-provisioning are documented, and that access reviews occur on a defined cadence. In cloud environments this means IAM policies that enforce least privilege, documented access request and approval workflows, and periodic reviews that produce evidence. We assess the actual IAM configuration in your AWS, GCP, or Azure environment and compare it against what your access control policy describes.

Encryption and Data Protection

Confidentiality controls require that customer data is encrypted both at rest and in transit. Auditors will ask for evidence of encryption configuration on every storage resource in scope: S3 buckets, RDS instances, Kubernetes secrets, and application databases. They will also ask about key management practices, rotation schedules, and who has access to decryption capability. We verify encryption configuration directly from your cloud environment rather than from the data classification policy that describes the intent.

Logging and Change Management

SOC 2 auditors examining security and availability criteria will test your logging and change management controls. CloudTrail must cover all accounts and regions in scope, with integrity controls and retention configurations that match your policy commitments. Change management controls require that infrastructure and code changes go through a documented review process with evidence of approval. We build both into your control program from the start, designed to produce audit evidence continuously rather than assembled before each audit cycle.

Deliverables

What You'll Receive

SOC 2 Readiness Assessment Report

Control Matrix with Gap Analysis

Security Policy Library (20+ policies)

Evidence Collection Templates

Remediation Roadmap

Audit Preparation Checklist

Auditor Q&A Support

Ongoing Compliance Monitoring Plan

Our Approach

SOC 2 Readiness Built to Hold Up Under Audit, Not Just to Start One

The most common SOC 2 failure mode is not a bad audit. It is a program that was built for the readiness assessment and then encountered the observation period. Controls that were designed in theory, never fully implemented in production, and never tested before the auditor arrived. The first time the change management process is exercised under the new policy is during the audit window. The first time the access review produces documentation is when the auditor asks for it.

We build SOC 2 programs to operate from the day controls go live. Access provisioning workflows are configured and tested before the observation period starts. Logging is verified against the audit evidence standard before a single day of the observation window counts. Change management is integrated into your existing engineering workflow rather than bolted on as a parallel process. Controls are designed around what your team will actually sustain, not around what looks best in a policy document.

We also verify controls against your live infrastructure throughout the engagement. IAM policies, encryption configuration, logging coverage, and network segmentation are pulled directly from your cloud environment and compared against the control requirements. When an auditor asks for evidence during the observation period, we have already confirmed that the evidence exists and matches the control description exactly.

The Cost of Delaying SOC 2 Readiness

Without a current SOC 2 Type II report, enterprise deals stall - procurement teams increasingly require one before signing contracts. Delays in readiness translate directly to lost revenue, extended sales cycles, and competitive disadvantage against organizations that already have a report in hand.

Explore our full range of compliance services

FAQ

Common Questions About SOC 2 Compliance

Does SiegePal certify us or issue the SOC 2 report?

No. SOC 2 is not a certification - it results in an attestation report issued by an independent licensed CPA firm after their audit. SiegePal is not that auditor, and the same firm cannot both prepare you for a SOC 2 audit and conduct it. What we do is a security-led gap analysis: we assess your current controls against the SOC 2 Trust Services Criteria, identify gaps, and provide remediation recommendations. If you implement those recommendations, that work is what prepares you for the audit performed by your chosen CPA firm, which is what produces the SOC 2 report.

What is the difference between SOC 2 Type I and SOC 2 Type II?

A SOC 2 Type I report assesses whether your controls are suitably designed at a single point in time. It confirms that the controls you describe exist and are designed to meet the relevant Trust Services Criteria. A SOC 2 Type II report covers both design and operating effectiveness over an observation period, typically six to twelve months, and requires evidence that controls actually operated throughout that period. Enterprise procurement teams increasingly require Type II because it demonstrates sustained operation rather than a point-in-time snapshot. If a customer or prospect asks for your SOC 2 report, they almost always mean Type II.

Which Trust Services Criteria do we need to include in our SOC 2 report?

Security is the only mandatory criterion. Availability, Confidentiality, Processing Integrity, and Privacy are optional and included based on the nature of your service and what your customers require. Most SaaS companies include Security and Availability as a minimum. Companies handling sensitive customer data, healthcare information, or financial records often include Confidentiality as well. The selection should reflect what your customers actually care about, because the auditor will assess whether your controls are sufficient for the criteria you claim. Including criteria you cannot adequately support creates more audit risk than omitting them.

How long does it take to obtain a SOC 2 Type II report?

The minimum timeline for a SOC 2 Type II report is approximately nine to twelve months from the start of a readiness engagement. The readiness and gap closure phase typically runs twelve to sixteen weeks. The observation period, during which controls must be operating and evidence collected, runs a minimum of six months for most auditors. The audit itself takes four to eight weeks after the observation period closes. Organizations that want a Type II report within a calendar year need to begin their readiness engagement in the first quarter. Starting later compresses the observation period or pushes the report into the following year.

Does SiegePal perform the SOC 2 audit or just prepare us for it?

SOC 2 audits must be conducted by a licensed CPA firm. SiegePal prepares you for the audit: we assess your controls against the Trust Services Criteria, close gaps, develop policies and procedures, build your evidence collection program, and support you through the audit itself. We work alongside your chosen auditor rather than replacing one. This separation is structurally important: the same firm cannot both prepare you for a SOC 2 audit and conduct it. Our role is to ensure there are no surprises when the auditor arrives, because we have already verified the controls they will test.

What evidence do SOC 2 auditors typically ask for?

Evidence requirements vary by control and criterion, but common requests include access provisioning and de-provisioning logs showing the full user lifecycle, access review documentation from periodic reviews conducted during the observation period, change management records showing approval and testing for infrastructure and code changes, encryption configuration screenshots for all in-scope storage resources, vulnerability scan results and remediation tracking, incident logs and response records, and CloudTrail or equivalent audit log samples demonstrating coverage, integrity controls, and retention. We design your evidence collection program around these requirements from the start, so evidence exists continuously rather than being assembled retrospectively before each audit.

Insights