Bell Tower logo Menu

SOC 2 Compliance Consulting & Trust Services Criteria Implementation

SOC 2 compliance consulting, Trust Services Criteria mapping, and audit-ready evidence libraries for Type I and Type II attestation. We build evidence packages that auditors accept.

Bell Tower engineers security controls aligned to SOC 2 Trust Services Criteria for organizations pursuing Type I or Type II attestation.

What We Deliver

  • Trust Services Criteria Mapping: We map your controls to Security, Availability, Processing Integrity, Confidentiality, and Privacy criteria, identifying gaps and building remediation roadmaps
  • Common Criteria Implementation: Full implementation of CC1.0-CC9.0 controls with documented evidence of operating effectiveness
  • SOC 2 Evidence Library: Organized documentation with control references, evidence types, sources, owners, and refresh cadences that satisfy auditor requirements
  • Type I & Type II Readiness: Preparation for initial Type I attestation and continuous monitoring infrastructure for Type II operational audits
  • Auditor Handoff Package: Bridge letters and evidence narratives that translate compliance tool outputs into formats auditors accept

SOC 2 Implementation

Bell Tower’s SOC 2 consulting addresses all five Trust Services Criteria categories. We begin with gap assessment against the Common Criteria (CC1.0-CC9.0), which form the foundation for all SOC 2 examinations regardless of which TSC categories you include. Our Trust Services Criteria mapping identifies which controls satisfy multiple criteria—enabling efficient compliance without redundant effort.

For organizations already operating under NIST CSF, ISO 27001, or CIS Controls, we provide crosswalk documentation showing how existing controls satisfy SOC 2 requirements. This unified approach means you don’t rebuild your security program for each framework—we demonstrate how one control set satisfies SOC 2, HIPAA, and FINRA/SEC requirements simultaneously.

Common Criteria (CC) Mapping

CC1.0 — Control Environment

Tone at the top, integrity, ethical values, and board oversight. We document governance structures and oversight mechanisms.

Key deliverables:

  • Board meeting minutes with security oversight
  • Code of conduct and ethics policy
  • Organizational structure and reporting lines
  • Management review documentation

CC2.0 — Communication and Information

Internal and external communication of objectives, responsibilities, and control operation. We establish information flows that support control effectiveness.

Key deliverables:

  • Internal communication procedures
  • External communication policies (customers, vendors, regulators)
  • Information system documentation
  • Control documentation libraries

CC3.0 — Risk Assessment

Risk identification, analysis, and mitigation. We implement risk assessment processes that identify threats to TSC achievement.

Key deliverables:

  • Risk assessment methodology and schedules
  • Risk registers with likelihood and impact ratings
  • Fraud risk assessments
  • Change management risk evaluations

CC4.0 — Monitoring Activities

Ongoing and separate evaluations of internal control. We establish monitoring that detects control failures before auditors do.

Key deliverables:

  • Continuous monitoring tool configurations
  • Internal audit schedules and reports
  • Management review meeting records
  • Control deficiency tracking and remediation

CC5.0 — Control Activities

Policies and procedures that mitigate risks to objectives. We implement the specific controls that address identified risks.

Key deliverables:

  • Control matrices mapped to risks
  • Policy and procedure documentation
  • Control operation evidence (logs, configurations, test results)
  • Segregation of duties matrices

CC6.0 — Logical and Physical Access Controls

Access restriction, authentication, and authorization. We engineer access controls that limit system and data access to authorized users.

Key deliverables:

  • Access control policies and standards
  • User access provisioning and deprovisioning procedures
  • Privileged access management documentation
  • Physical access controls and visitor logs

CC7.0 — System Operations

System monitoring, vulnerability management, and incident detection. We establish operations that maintain system availability and security.

Key deliverables:

  • System monitoring configurations and alert rules
  • Vulnerability management procedures and scan results
  • Change management records
  • Capacity planning documentation

CC8.0 — Change Management

System change control, testing, and implementation. We implement change processes that prevent unauthorized modifications.

Key deliverables:

  • Change management policy and procedures
  • Change request and approval records
  • Testing documentation and evidence
  • Emergency change procedures

CC9.0 — Risk Mitigation

Vendor management, business continuity, and risk transfer. We address risks from third parties and business disruptions.

Key deliverables:

  • Vendor risk assessment procedures
  • Business continuity and disaster recovery plans
  • Insurance and risk transfer documentation
  • Third-party SOC 2 reports and contract reviews

Type I vs Type II Attestation

Type I evaluates control design at a specific point in time. Suitable for initial attestation or when operational history is limited. Timeline: 3-4 months from engagement to report.

Type II evaluates both control design and operating effectiveness over a period (typically 6-12 months). Required for vendor assessments and enterprise sales. Timeline: 9-14 months including observation period.

We recommend Type I as a foundation: implement controls, obtain Type I attestation, then operate controls for 6+ months before Type II. This staged approach provides early credibility while building toward the operational evidence Type II requires.

Regulatory Crosswalks: SOC 2 to Compliance Requirements

SOC 2 alignment accelerates compliance with multiple regulatory frameworks. Our crosswalks demonstrate how SOC 2 controls satisfy specific requirements:

HIPAA Security Rule

SOC 2 CCHIPAA RequirementEvidence Artifact
CC6.1164.312(a) Access ControlAccess control policy, user provisioning logs
CC6.7164.312(e) Transmission SecurityEncryption configuration, TLS certificates
CC7.2164.312(b) Audit ControlsSIEM logs, audit trail exports
CC4.1164.308(a)(8) EvaluationPenetration test reports, vulnerability scans
CC9.2164.308(a)(6) Security Incident ProceduresIR plan, incident tickets, AARs

FINRA/SEC Cybersecurity Requirements

SOC 2 CCFINRA/SEC RequirementEvidence Artifact
CC3.2FINRA Rule 4370 Business ContinuityRisk assessment methodology, BCP test results
CC6.1SEC Regulation S-PData classification policy, encryption at rest
CC7.1FINRA Notice 21-29Threat intelligence integration, alert tuning
CC4.1SEC Investment Advisers Act Rule 206(4)-7DR procedures, failover test documentation

GDPR Article 32

SOC 2 CCGDPR RequirementEvidence Artifact
CC6.1Art. 32(1)(b) Access ControlMFA configuration, privileged access reviews
CC6.7Art. 32(1)(a) EncryptionEncryption key management, data masking procedures
CC7.2Art. 32(1)(d) Security TestingPenetration test reports, vulnerability scans
CC4.1Art. 33 Breach NotificationBreach assessment procedures, notification logs

Audit Evidence Library

Auditors require specific evidence types for each Common Criteria. We build organized libraries with clear ownership and refresh schedules:

Control RefEvidence TypeSourceOwnerRefresh Cadence
CC1.1Board minutes, ethics attestationsDocument managementCEO/CISOQuarterly
CC2.1Internal communication recordsEmail/Slack archivesCompliance OfficerQuarterly
CC3.1Risk assessment documentationRisk management platformRisk ManagerAnnual
CC4.1Monitoring tool configurationsGRC platformSecurity OperationsMonthly
CC5.1Control operation logsSIEM/Cloud platformsControl OwnersMonthly
CC6.1Access review attestationsIAM systemsData OwnersQuarterly
CC7.1Vulnerability scan resultsScanning toolsSecurity EngineerMonthly
CC8.1Change request approvalsChange management systemChange ManagerPer change
CC9.1Vendor risk assessmentsVendor management platformProcurement/SecurityAnnual

From Automation to Auditor

Compliance automation tools (Vanta, Secureframe, Drata) generate continuous monitoring data, but auditors often require bridge letters explaining what tools validate versus manual evidence. We prepare SOC 2 auditor handoff packages that:

  1. Map tool checks to Common Criteria: “Vanta daily checks validate CC6.1 (logical access) via Okta API queries and AWS IAM analysis”
  2. Identify gaps requiring manual evidence: “Tool monitors configuration but not CC2.1 (internal communication); we provide documented communication procedures and meeting records”
  3. Translate outputs to auditor formats: Convert JSON exports to narrative control descriptions with timestamps, sampling methodology, and ownership documentation
  4. Address exceptions: Document control failures, compensating measures, and remediation timelines—transparency auditors expect

Why Bell Tower for SOC 2

Framework Integration: We implement SOC 2 alongside NIST CSF, ISO 27001, and CIS Controls—ensuring unified compliance rather than siloed efforts. One control set satisfies multiple frameworks.

Audit Experience: We’ve guided organizations through SOC 2 examinations for healthcare (HIPAA), finance (FINRA/SEC), SaaS platforms, and digital media companies.

Evidence Engineering: We know what auditors accept. Our SOC 2 evidence libraries include the specific artifacts that prove control effectiveness, not just policy existence.

Continuous Readiness: We build continuous SOC 2 readiness infrastructure—monitoring, evidence collection, and exception handling—that maintains attestation between audits.

Knowledge Transfer: We solve problems and ensure your team understands Trust Services Criteria requirements—building sustainable compliance, not dependency.

Frequently Asked Questions

How long does SOC 2 implementation take?

Type I typically requires 3-4 months from initial gap assessment to audit completion. Type II requires 9-14 months including the 6-12 month observation period. Organizations with existing security programs (NIST CSF, ISO 27001) often reduce Type I timelines by 4-6 weeks through control reuse.

What’s the difference between Type I and Type II?

Type I evaluates whether controls are designed appropriately at a specific point in time. Type II evaluates whether controls operate effectively over a period (6-12 months). Type I provides initial credibility; Type II provides operational assurance required by enterprise customers and vendor assessments.

Do we need all five Trust Services Criteria?

No. Security (common criteria) is required. Availability, Processing Integrity, Confidentiality, and Privacy are optional based on your service commitments. Most organizations start with Security + Availability or Security + Confidentiality, expanding criteria as customer requirements evolve.

Can we use existing security frameworks for SOC 2?

Yes. Organizations with NIST CSF, ISO 27001, or CIS Controls implementations can leverage existing controls for SOC 2. Our crosswalks demonstrate how existing controls satisfy Trust Services Criteria—reducing implementation effort and avoiding redundant controls.

What evidence do SOC 2 auditors require?

Evidence varies by criteria but generally includes: configuration exports, access logs, test results, policy documents with version control, training records, incident handling documentation, and management review records. We organize these into auditor-friendly libraries with clear ownership and refresh schedules that demonstrate continuous SOC 2 readiness.