SOC 1 Type I: Internal Controls Over Financial Reporting for Service Organisations

SOC 1 reports are frequently misunderstood and confused with SOC 2. While SOC 2 addresses security and operational controls, SOC 1 has a very different and specific purpose: it addresses controls at a service organisation that are relevant to a user entity's internal control over financial reporting (ICFR). If your services affect how your clients report their financials, their auditors want a SOC 1 report.

What Is SOC 1?

SOC 1 is governed by SSAE 18 (Statement on Standards for Attestation Engagements No. 18), issued by the AICPA. It replaced the older SSAE 16 and SAS 70 standards. A SOC 1 report provides an independent CPA firm's opinion on whether a service organisation's controls are suitably designed (Type I) or operating effectively (Type II) with respect to the financial reporting of the service organisation's clients.

The key question a SOC 1 report answers is: "Does this service organisation have controls in place that protect the financial reporting integrity of its clients?"

Who Needs a SOC 1 Report?

SOC 1 is relevant to any service organisation that processes transactions or maintains data that could affect the financial statements of its clients. Common categories include:

• Payroll processors — processing employee compensation, tax withholdings, and benefits deductions that flow directly into clients' financial statements
• Loan servicers and mortgage processors — managing loan portfolios and payment processing that affect financial reporting
• Insurance claims processors — handling claims data that affects insurers' loss reserves and liabilities
• Data centre operators and managed IT service providers — when they host systems that process financial transactions for clients
• Healthcare claims processors — processing claims and payments that affect healthcare organisations' financial reporting
• Custody and trust service providers — holding client assets that must be accurately reported
• Third-party administrators (TPAs) — administering employee benefit plans, retirement accounts, or insurance programmes
• Financial technology platforms — processing accounting, billing, or treasury transactions for clients

The trigger is not the industry — it is whether your service creates, modifies, or maintains data that flows into your clients' financial statements.

The Difference Between SOC 1 and SOC 2

This distinction is fundamental and frequently confused:

Many organisations need both SOC 1 and SOC 2 — SOC 1 for their clients' financial auditors and SOC 2 for enterprise procurement and security teams.

SOC 1 Report Structure: What It Contains

A SOC 1 Type I report contains:

1. Management's Description of the Service Organisation's System

A detailed description of the service organisation's system — the services provided, the nature of the processing, the components of the system (infrastructure, software, people, procedures, data), and the control environment that supports financial reporting.

2. Management's Assertion

A formal written assertion from management that the description is fairly presented and that the controls described are suitably designed to achieve the stated control objectives (Type I) or were operating effectively (Type II).

3. The Independent Service Auditor's Report

The CPA firm's opinion on whether the description is fairly presented and whether controls are suitably designed or operating effectively, as applicable.

4. Detailed Description of Tests and Results (Type II only)

For Type II reports, a section describing the tests performed by the auditor and the results of those tests, including any exceptions noted.

Defining Control Objectives for SOC 1

Unlike SOC 2, which uses the AICPA's Trust Services Criteria as its standard framework, SOC 1 control objectives are management-defined — you define the control objectives relevant to your clients' financial reporting, and the auditor assesses whether controls are designed and operating to achieve those objectives.

Common SOC 1 control objective categories include:

Transaction processing controls:

• Transactions are processed completely and accurately
• Transactions are authorised in accordance with client specifications
• Duplicate transactions are detected and prevented
• Transaction cutoffs are properly applied

Data integrity controls:

• Client data is maintained accurately and completely
• Data access is restricted to authorised personnel
• Data backup and recovery procedures protect against data loss

Change management controls:

• System changes are properly authorised, tested, and approved before implementation
• Emergency changes follow an expedited but controlled process

Logical access controls:

• Access to systems processing client transactions is restricted to authorised personnel
• Terminated employee access is revoked promptly
• Privileged access is appropriately controlled and monitored

Reporting controls:

• Client reports are generated completely and accurately
• Report delivery is complete and timely

The SOC 1 Type I Readiness Journey

Phase 1: Scope and Control Objective Definition

The first and most critical step is defining the scope of the SOC 1 report and the control objectives. This requires:

• Identifying which of your services affect clients' financial reporting
• Understanding what your clients' financial auditors expect to see covered
• Defining control objectives that accurately represent the controls relevant to financial reporting
• Mapping control objectives to existing controls or identifying gaps

A critical insight: The control objectives defined in a SOC 1 report become the standard against which your controls are assessed. Objectives that are too broad create unrealistic audit expectations. Objectives that are too narrow may not satisfy your clients' financial auditors. Getting this definition right — typically with guidance from your CPA firm — is essential.

Phase 2: Gap Assessment

With control objectives defined, a systematic gap assessment identifies:

• Controls that exist but are not documented
• Controls that are documented but not operating consistently
• Control objectives for which no adequate controls currently exist
• Evidence collection gaps that will prevent the auditor from testing effectively

Phase 3: Control Design and Remediation

For any gaps identified, controls must be designed and implemented. For SOC 1, control design focuses specifically on financial reporting integrity:

• Configuring system-level controls (access restrictions, automated validation checks, processing controls)
• Establishing manual controls with clear procedures and accountability
• Creating documentation that describes each control, its frequency, the responsible owner, and how evidence is captured
• Establishing approval workflows and segregation of duties where required

Phase 4: Documentation and Description Development

The System Description is the narrative heart of the SOC 1 report. It must accurately describe:

• The nature of the services provided
• The classes of transactions processed
• The information technology components (systems, databases, interfaces)
• The boundaries of the system included in the scope
• The control environment, risk assessment, monitoring, and information communication processes
• Each control objective and the specific controls designed to achieve it

Phase 5: Pre-Audit Readiness Review

Before engaging the CPA firm for the formal examination, a readiness review confirms:

• All controls documented in the description actually exist and are in place
• Evidence of control design is available for auditor inspection
• The System Description accurately reflects the system as it currently operates
• Control owners are prepared to be interviewed and can explain their responsibilities

Phase 6: CPA Examination

For Type I, the auditor:

• Reviews the System Description for fair presentation
• Traces controls described in the description to evidence of their existence
• Interviews personnel to verify they understand their control responsibilities
• Assesses whether the design of controls is suitable to achieve the stated objectives

Common SOC 1 Findings and How to Avoid Them

Overly broad control objectives: Writing control objectives that are aspirational rather than precise creates audit risk. Every objective must be achievable by specific, testable controls.

Segregation of duties gaps: SOC 1 auditors are particularly focused on whether the same person can both execute and approve transactions. Manual or system-level segregation of duties is expected across key financial reporting processes.

Incomplete system descriptions: Omitting key processing components, data flows, or interfaces from the description creates a mismatch between what the description says and what the auditor finds in testing.

Undocumented manual controls: Many organisations have effective manual controls — supervisory reviews, exception reports, reconciliations — that are never documented formally. Undocumented controls cannot be tested and cannot appear in the report.

Change management gaps: Changes to systems that process client transactions must follow a documented, authorised change management process. Evidence of testing and approval before changes go live is essential.

How User Entities Use SOC 1 Reports

Your clients' financial auditors use your SOC 1 report as part of their audit of your clients' financial statements. Specifically, they:

• Review the report to understand the controls at your organisation that affect their client's financial reporting
• Identify Complementary User Entity Controls (CUECs) — controls that your clients must implement on their end to ensure the overall control objective is achieved
• Test those CUECs as part of their audit fieldwork
• Rely on your SOC 1 report to reduce the extent of their own testing of controls at your organisation

This means that a clean, comprehensive SOC 1 report directly reduces the audit burden on your clients — making you a more valuable and lower-risk vendor.

Why Organisations Choose Savadub

Deep GRC Expertise

Our team holds practitioner-level expertise across every major compliance framework — not just theoretical knowledge, but hands-on implementation experience across multiple industries and organisation sizes.

Engineers, Not Just Consultants

We implement controls, not just recommend them. Our GRC engineers configure the systems, write the integrations, and build the monitoring pipelines that make compliance operational.

Global and African Regulatory Coverage

We understand both the global frameworks and the African regulatory environment — NDPR, NDPA, CBN directives, NITDA guidelines, and regional data protection laws — making us uniquely positioned for organisations operating across Africa and internationally.

Internal and External Audit Capability

We provide both embedded internal audit functions and independent third-party audit support, including CPA-accredited audit coordination for SOC examinations.

End-to-End Engagement

From initial gap assessment through certification, continuous monitoring, and ongoing compliance management — we are your long-term GRC partner, not a one-time consultant.

Industries We Serve

Financial Services · Healthcare · Technology & SaaS · Manufacturing · Logistics & Trade · Government & Public Sector · Energy & Critical Infrastructure · Education & EdTech · Media & Broadcasting · Retail & E-Commerce · Professional Services · Food & Beverage

Deliverables You Receive

Working with Savadub, every engagement delivers a concrete set of outputs:

• Gap Assessment Report — prioritised findings with effort estimates and risk ratings
• Compliance Roadmap — milestone-based plan from current state to certification or attestation
• Risk Register — organisational risk register with treatment plans
• Policy Pack — all required policies authored, reviewed, and approved
• Technical Control Implementation Evidence — configurations, screenshots, and audit trails
• Internal Audit Report — independent assessment of control effectiveness
• Audit Evidence Repository — organised, auditor-ready evidence collection
• Executive Summary Presentation — board and leadership-ready compliance status
• Remediation Tracker — structured tracking of open findings and closure evidence
• Continuous Monitoring Setup — ongoing CCM pipeline for post-certification compliance

Get Started with Savadub

Savadub's GRC practice combines deep compliance expertise with technical engineering capability. We don't just advise — we build, implement, and operate your compliance program from the ground up.

Book a free GRC consultation with our team. We will review your current posture, identify your most critical gaps, and give you a clear, costed roadmap to compliance.

Contact us:

• Email: grc@savadub.com
• Phone: +234 816 734 2201
• WhatsApp: +234 903 234 8435
• Website: www.savadub.com