SOC 1 Deepdive

1. Overview

What SOC 1 Is

SOC 1 (System and Organization Controls 1) is an attestation engagement performed by a licensed CPA firm under SSAE 21, AT-C section 320. Unlike SOC 2, which covers the Trust Services Criteria, SOC 1 reports on controls at a service organization that are relevant to user entities' internal control over financial reporting (ICFR). The auditor (formally the service auditor) tests management's stated control objectives and provides an opinion on whether the controls are suitably designed and (for Type 2) operating effectively.

Who It Applies To

Service organizations whose processing affects their customers' financial statements. Typical examples: payroll providers, payment processors, claims administrators, fund administrators, SaaS billing platforms, loan-servicing platforms, and trust-and-custody services. If your customers' auditors need to rely on your controls when auditing your customers' financial statements, you likely need SOC 1.

Outcome

An independent service auditor's report:

• SOC 1 Type 1 — opinion on the fairness of management's description and the suitability of control design at a point in time.
• SOC 1 Type 2 — opinion on the fairness of management's description, the suitability of control design, and the operating effectiveness of controls over a defined observation period (typically 6 to 12 months).

SOC 1 reports are restricted-use: they are intended for management of the service organization, user entities, and user entities' auditors. They are not for public distribution. Security Consultants is not a CPA firm and does not issue SOC 1 reports; we prepare clients for the engagement, draft the System Description and control objectives, and represent the program through the audit. See our SOC 2 service page if you also need TSC-based assurance for non-ICFR commitments.

High-Level Goals and Risk Domains

• Provide assurance that the service organization's controls support accurate financial processing for user entities
• Support user entities' SOX 404 / external audit programs
• Reduce duplicated control testing across many customers' auditors
• Demonstrate operational maturity to financial-services and regulated buyers

2. Scope & Applicability

Typical In-Scope Elements

• Transaction processing systems and the underlying infrastructure
• General IT controls (ITGCs): access management, change management, computer operations, backup and recovery
• Application controls that prevent or detect financial misstatement (input edits, authorization, completeness checks, reconciliations)
• Reports relied upon by users for financial decisions
• Operational processes that produce financial data delivered to customers

Common Out-of-Scope Elements

• Marketing and sales systems unrelated to transaction processing
• Internal corporate HR and finance systems not tied to customer financial reporting
• Product features that do not impact customer financial statements

Subservice Organizations — Carve-Out vs Inclusive Method

If your service depends on subservice organizations (for example, a cloud hosting provider or a banking partner), you must disclose them in the System Description:

• Carve-out method — the subservice organization's controls are excluded from your scope. You document the Complementary Subservice Organization Controls (CSOCs) they are expected to perform.
• Inclusive method — the subservice organization's controls are tested in your engagement (rare; requires their cooperation).

Complementary User Entity Controls (CUECs)

User entities (your customers) have their own controls to operate alongside yours. The System Description lists the CUECs your customers must implement so their auditors know what they are accountable for — for example, reviewing reports you provide, reconciling balances, or approving transactions before submission.

3. Core Principles — Control Objectives

SOC 1 is built around control objectives defined by management, not a fixed criteria set like SOC 2's Trust Services Criteria. The service organization is responsible for stating control objectives that reflect the financial-reporting risks its service introduces for user entities. The service auditor evaluates whether the controls described are suitably designed (and, for Type 2, operating effectively) to achieve those objectives.

Typical control-objective domains include:

• Logical access (provisioning, segregation of duties, privileged access)
• Change management (application changes, database changes, infrastructure changes)
• Computer operations (job scheduling, monitoring, incident management)
• Data transmission and integrity
• Transaction processing accuracy and completeness
• Authorization controls over transactions and reports
• Reconciliation controls
• Backup and recovery

Control objectives must be specific enough that the auditor can test them and a user entity can rely on them. Vague objectives ("transactions are processed accurately") get strengthened during readiness work to be specific and testable.

4. Control Breakdown — Typical Control Objective Areas

Logical Access

Typical Objective: Controls provide reasonable assurance that logical access to the production environment and financial data is restricted to authorized personnel.
Controls: Provisioning and de-provisioning workflows; quarterly access reviews; MFA enforcement; privileged access reviews; segregation of duties between developers and production operators.
Evidence: Provisioning tickets, access review attestations, MFA enrollment reports, privileged-access logs.

Change Management

Typical Objective: Controls provide reasonable assurance that changes to the application and supporting infrastructure are authorized, tested, and approved before deployment.
Controls: Documented change process; code review and approval; test environment validation; segregation between development and production; emergency change procedure.
Evidence: Change tickets, pull request approvals, deployment logs, post-implementation reviews.

Computer Operations

Typical Objective: Controls provide reasonable assurance that scheduled processing, monitoring, and incident response operate as intended.
Controls: Job scheduling and monitoring; on-call rotation; incident response procedures; backup operations and tested recovery.
Evidence: Job run logs, incident records with resolution, backup and recovery test results.

Data Transmission and Integrity

Typical Objective: Controls provide reasonable assurance that data exchanged with user entities is complete, accurate, and authorized.
Controls: Encryption in transit; transmission logging; reconciliation of inbound and outbound batches; error handling and re-processing.
Evidence: Transmission logs, reconciliation reports, exception handling tickets.

Transaction Processing

Typical Objective: Controls provide reasonable assurance that transactions are processed completely, accurately, timely, and only when authorized.
Controls: Input validation; duplicate detection; authorization checks; processing reconciliation; exception monitoring.
Evidence: Application logs, reconciliation reports, exception queues with resolution.

Reporting and Reconciliation

Typical Objective: Controls provide reasonable assurance that reports provided to user entities are complete, accurate, and reflect the underlying transaction records.
Controls: Report generation reconciled to source data; report-version control; user-entity acknowledgement of receipt where contracted.
Evidence: Reconciliation evidence, report logs, customer acknowledgements.

5. Minimum Requirements (Non-Negotiable)

Mandatory Documents

• System Description meeting AICPA description criteria for SOC 1
• Management's assertion accompanying the report
• Stated control objectives, tested controls, and evidence references
• Risk assessment specifically addressing risks to user entities' ICFR
• Information security and access management policies
• Change management procedure
• Incident response plan
• Vendor and subservice organization disclosures (CSOCs)
• Complementary User Entity Controls (CUECs)

Mandatory Processes

• Background checks on personnel with access to financial data
• Onboarding / offboarding with timely access change
• Quarterly access reviews with documented attestation
• Change management approvals before production deployment
• Reconciliation controls operated and evidenced on schedule

Technical Controls (Baseline)

• MFA on production access
• Encryption in transit and at rest
• Centralized logging with retention sufficient for the observation period
• Segregation of duties between development and production operations
• Backups tested at least annually

Recurrence

• Annual risk assessment
• Quarterly access reviews
• Monthly or scheduled reconciliations per control objective
• Annual DR and incident response test
• Type 2 only: evidence of every recurring control retained for the full observation period (6–12 months)

6. Technical Implementation Guidance

Access Control

• SSO and MFA enforced at the identity provider
• Role-based access tied to job function; segregation of duties documented
• Quarterly access reviews; immediate revocation on termination

Change Management

• All production changes via pull request with code review and named approver
• Test evidence retained per change
• Emergency change procedure with retrospective approval

Logging & Monitoring

• Centralized log aggregation with retention covering the observation window
• Alerts on privilege escalation, unauthorized access, security tool tampering
• Job run monitoring with on-call response

Reconciliation

• Automated reconciliation where the volume warrants; manual where automation isn't yet in place
• Documented review and sign-off cadence per reconciliation
• Exception queues with timestamps and resolution evidence

Backup & DR

• Immutable backups with documented retention
• Recovery objectives defined per system
• Annual recovery test with documented results

7. Policy & Procedure Requirements

Typical documents include:

• Information Security Policy
• Access Control Policy
• Change Management Policy
• Incident Response Plan
• Business Continuity / Disaster Recovery Plan
• Backup Policy
• Reconciliation Procedure
• Vendor Management Policy
• Encryption Policy
• System Description with control objectives, CUECs, and CSOCs

For organizations also pursuing SOC 2 or ISO 27001, most of these documents can be reused with minor scope extensions — SOC 1 focuses tighter (controls relevant to ICFR), while SOC 2 and ISO 27001 cover broader information-security objectives.

8. Audit Evidence & Verification

The System Description

The System Description for SOC 1 mirrors the SOC 2 structure but with a financial-reporting lens:

• Types of services provided
• System components: infrastructure, software, people, procedures, data
• Boundaries of the system
• Subservice organizations and the method used (carve-out / inclusive)
• Control objectives (specific to ICFR risks)
• Controls tested against each objective
• Complementary User Entity Controls (CUECs)
• Complementary Subservice Organization Controls (CSOCs) for carve-out
• Significant changes during the observation period (Type 2 only)

What the Service Auditor Requests

• System Description and management assertion
• Sample transactions and reconciliations
• Access provisioning and review evidence
• Change management tickets with approval evidence
• Incident records and post-incident reviews
• Backup and recovery test results
• Vendor risk assessments and contracts where relevant

Sampling

Type 2 samples are typically 25–40 items per control objective across the observation period, with larger samples for high-volume control areas (access reviews, change management, reconciliations).

Common Remediation Items

• Control objectives written too vaguely to be tested
• Missing reconciliation evidence (process happens, evidence isn't retained)
• Segregation of duties not documented or not enforced
• Stale CUECs that don't match what customers actually do
• Job-run evidence missing for the early months of an observation period

An independent pre-audit review — typically an internal audit pass or a SOC 1 readiness assessment — catches these issues before the service auditor begins fieldwork.

9. Implementation Timeline Considerations

Typical Duration

• Type 1: 4–12 weeks from kickoff to report, depending on existing control maturity and the precision of stated control objectives.
• Type 2: the observation period adds 3–12 months on top of Type 1. The audit fieldwork itself runs in weeks after the observation period ends.

Bridge Letter

Between Type 2 reports, user entities often request a bridge letter from management (sometimes counter-signed by the service auditor) confirming no material control changes since the last report. The bridge typically covers up to 3 months.

Milestones

• Scoping and control-objective definition
• Gap assessment against stated objectives
• Remediation and process strengthening
• System Description drafting
• Evidence collection setup
• Audit readiness review
• Service auditor fieldwork
• Report issued

Dependencies

• Control objectives signed off by management
• System Description aligned with actual operations
• Subservice organization SOC 1 or SOC 2 reports available (for carve-out)
• Hiring or vCISO support if the program lacks senior security leadership (see vCISO services)

10. Ongoing BAU Requirements

• Regular access reviews with documented attestation
• Reconciliation cadence per control objective
• Continuous change management with approval evidence
• Monthly incident review and metrics
• Annual risk assessment refresh focused on ICFR-relevant risks
• Annual DR test
• Vendor and subservice organization SOC report collection
• Asset inventory updates as systems change
• Continuous evidence collection — Type 2 cannot be reconstructed retroactively

11. Maturity Levels

Minimum Compliance

• Control objectives documented but written broadly
• Manual reconciliations and access reviews
• Basic change management with informal approval evidence

Intermediate

• Control objectives precise and testable
• Automated provisioning and de-provisioning
• Reconciliations automated where volume warrants
• Documented procedures with named owners

Advanced

• Continuous control monitoring with evidence captured automatically
• Real-time exception alerting and SLA-driven remediation
• Integrated SOC 1, SOC 2, and ISO 27001 evidence collection
• Bridge letters issued without firefighting

12. FAQs

What's the difference between SOC 1 and SOC 2?

SOC 1 reports on controls relevant to user entities' internal control over financial reporting (ICFR). SOC 2 reports on controls relevant to the Trust Services Criteria (security, availability, confidentiality, processing integrity, privacy). Service organizations whose processing affects customer financial statements typically need SOC 1; SaaS providers handling customer data outside the financial-statement chain typically need SOC 2. Many fintech and regulated SaaS firms need both.

Do we need SOC 1, SOC 2, or both?

If your customers' financial statements depend on your processing — for example, payroll, payments, billing, or fund administration — your customers' auditors typically need SOC 1. If your service handles customer data but doesn't affect their financial statements directly, SOC 2 is usually sufficient. A scoping call resolves this in 30 minutes.

How long is a SOC 1 report valid?

A Type 2 report covers a specific observation period. User entities and their auditors generally rely on the report for the covered period plus a brief bridge (commonly up to 3 months) supported by a management or CPA-signed bridge letter.

Who writes the control objectives?

Management writes the control objectives. Security Consultants helps shape them in the readiness phase — phrasing them so they are specific, testable, and aligned to the actual financial-reporting risks of the service. The service auditor then tests the controls against those stated objectives.

What does a SOC 1 report cost?

Two cost components. The CPA firm's audit fee for a SOC 1 Type 2 typically runs $25,000–$75,000 depending on complexity, transaction volume, and the number of control objectives. Consulting and remediation costs depend on the gap between current state and audit-ready, scoped after an initial gap assessment.

Can SOC 1 replace SOX 404 work for our customers?

SOC 1 supports — it does not replace — your customers' SOX 404 obligations. Their external auditors will rely on a Type 2 report instead of testing your controls directly, which reduces duplicate testing but doesn't remove the customer's own SOX 404 responsibility.

Is SOC 1 publicly available like SOC 3?

No. SOC 1 reports are restricted-use and intended for management, user entities, and user entities' auditors. SOC 3 reports — based on a SOC 2 examination — are general-use and can be published.

What's a service auditor?

A service auditor is the licensed CPA firm performing the SOC 1 engagement. The terminology comes from AICPA attestation standards and is distinct from the user entity's own external auditor (the user auditor).

How does SOC 1 interact with ISO 27001?

SOC 1 controls usually map well onto ISO 27001 Annex A — particularly access control, change management, and operations security. Organizations running both standards usually consolidate the underlying control set and produce both reports against it. See our ISO 27001 service for the dual-standard approach.

Do we need separate engagements every year?

Most service organizations run continuous annual Type 2 reports with rolling 12-month observation periods. Re-scoping happens annually, but most of the program remains in steady state.

13. Summary

SOC 1 provides independent assurance that a service organization's controls support user entities' financial-reporting accuracy. It is built around management-defined control objectives tested by a service auditor under AT-C section 320. Success requires precise control objectives, a credible System Description, evidenced controls running consistently across the observation period, and clear documentation of CUECs and CSOCs.

To scope a SOC 1 engagement, book a call from the consulting services page, or talk to us about combining SOC 1 with SOC 2 or ISO 27001 for a single integrated control set.

‍