They expertly mapped the overlapping controls between SOC 2 and ISO 27001, which saved us from duplicating work.
Jasreet Kaur B.Silicon Physical Design Engineer · Small-BusinessSOC 2 + ISO 27001 · August 2026
AT-C 320 · FIVE COSO COMPONENTS
SOC 1 Deep Dive · SSAE 18 / ISAE 3402
SOC 1 ICFR Control
Objectives: The Complete Guide
Internal Control over Financial Reporting is the foundation of every SOC 1 engagement. This guide breaks down the six core ICFR control categories, how auditors test them, where organizations most commonly fail, and how to build a control environment that passes on the first attempt.
Key Takeaways
- ICFR (Internal Control over Financial Reporting) is the specific domain SOC 1 evaluates — controls that affect the accuracy, completeness, and timeliness of your clients' financial statements.
- Control objectives are specific to your services, not generic checklists. A payroll processor and a payment gateway have fundamentally different ICFR scopes, even though both fall under SOC 1.
- The six core ICFR categories (transaction processing, access & SoD, change management, data integrity, monitoring, subservice organizations) appear across virtually all SOC 1 engagements.
- The three most common audit findings are stale user access, undocumented emergency changes, and segregation-of-duties violations — all preventable with the right controls and evidence practices.
Foundation
What Is ICFR?
Internal Control over Financial Reporting (ICFR) refers to the processes, procedures, and controls that an organization maintains to ensure its financial statements are reliable, accurate, and compliant with applicable accounting standards. For service organizations, ICFR extends to any control that could affect the financial statements of your user entities — the clients who rely on your services.
The concept originates from the Sarbanes-Oxley Act (SOX) of 2002, which mandated that publicly traded companies maintain effective internal controls over their financial reporting. When those companies outsource functions like payroll processing, payment handling, or loan servicing, their auditors need assurance that the service organization's controls are also effective. SOC 1 provides exactly that assurance.
Under SSAE 18 (AT-C Section 320) in the United States — and ISAE 3402 internationally — an independent CPA firm examines the service organization's ICFR controls and issues an opinion on whether those controls are suitably designed (Type I) and operating effectively (Type II) to achieve the stated control objectives.
The key insight is that ICFR control objectives are not a fixed checklist. They are defined by the services you provide and the specific ways those services could materially affect your clients' financial statements. This is why SOC 1 scoping is a professional judgment exercise — and why working with consultants who have deep ICFR experience matters.
Regulatory Context
SOX-driven demand: Publicly traded companies subject to SOX Section 404 require SOC 1 reports from service organizations that affect their financial reporting. Non-public entities increasingly request SOC 1 reports as well, driven by auditor requirements and enterprise procurement standards. The governing standards are AICPA SSAE 18 (AT-C 320) domestically and IAASB ISAE 3402 internationally — ensuring global reciprocity of SOC 1 reports.
Deep Dive
The 6 Core ICFR Control Categories
While specific control objectives vary by organization, virtually every SOC 1 engagement maps to these six categories. Each category below includes the subcategories auditors examine and practical examples of what effective controls look like.
01
Transaction Processing Controls
Controls ensuring financial transactions are authorized, complete, accurate, and timely throughout the processing cycle.
Authorization Controls
Define who can initiate, approve, and execute financial transactions. Authorization limits, dual-approval thresholds, and delegation matrices ensure no single actor can push through a transaction beyond their mandate.
Practical Examples
- Dollar-amount approval thresholds (e.g., transactions above $10,000 require VP sign-off)
- Segregated initiation and approval roles in the workflow engine
- Documented delegation-of-authority matrices with effective dates
- Automated enforcement of approval limits within the application layer
Completeness Controls
Ensure every transaction that enters the system is processed — none are lost, duplicated, or silently dropped. Batch totals, sequence checks, and reconciliation counts are the primary mechanisms.
Practical Examples
- Batch control totals reconciled at input, processing, and output stages
- Sequential numbering with automated gap detection (missing invoice numbers)
- End-of-day reconciliation of transaction counts against source systems
- Exception reports for unprocessed or rejected items requiring manual review
Accuracy Controls
Validation rules and edit checks that catch erroneous data before it corrupts financial records. These operate at field level (format checks), record level (cross-field validation), and batch level (hash totals).
Practical Examples
- Field-level validation: currency format, date ranges, numeric bounds
- Cross-field edits: debits must equal credits within a journal entry
- Hash totals on non-additive fields (e.g., sum of account numbers) to detect transposition errors
- Automated three-way matching (purchase order, goods receipt, invoice)
Timeliness Controls
SLA-based processing windows and cutoff procedures that ensure transactions post to the correct accounting period. Late processing is one of the most common sources of material misstatement.
Practical Examples
- Defined processing windows with automated cutoff enforcement
- SLA dashboards tracking aging of unprocessed transactions
- Month-end and year-end cutoff procedures documented and tested
- Escalation workflows when processing backlogs breach threshold
02
Access & Segregation of Duties
Logical access restrictions and segregation of duties that prevent any single person from initiating and approving financial transactions.
Role-Based Access Control Design
Financial systems must enforce least-privilege access through well-defined roles. Each role maps to a specific set of capabilities — and critically, the role definitions must be documented, approved, and reviewed periodically.
Practical Examples
- Formally documented role definitions with mapped system entitlements
- Automated provisioning tied to HR job-code changes
- Quarterly access recertification by business owners (not IT)
- Same-day deprovisioning verified against HR termination records
Segregation Matrices
A segregation-of-duties (SoD) matrix identifies incompatible function pairs — combinations that, if held by the same person, create an unacceptable risk of fraud or error. Auditors test this rigorously.
Practical Examples
- Documented SoD matrix mapping incompatible pairs (e.g., "create vendor" vs. "approve payment")
- Automated SoD conflict detection integrated into the IAM provisioning workflow
- Quarterly SoD conflict reports reviewed and signed off by management
- Formal exception process for temporary SoD overrides with compensating controls
Privileged Access Management
Admin and superuser accounts bypass normal controls. Privileged access management (PAM) ensures these accounts are inventoried, just-in-time provisioned where possible, and subject to enhanced monitoring.
Practical Examples
- Inventory of all privileged accounts with named owners
- Just-in-time (JIT) elevation with automatic session expiry
- Session recording and command logging for privileged operations
- Separate break-glass accounts for emergency access, with post-incident review
Compensating Controls for Small Teams
Organizations with fewer than 10-15 people in finance cannot achieve textbook SoD. Compensating controls — management review, detailed logging, and independent reconciliation — fill the gap. Auditors accept these when properly documented.
Practical Examples
- Documented justification for each SoD exception with named compensating control
- Daily or weekly management review of all transactions processed by the dual-role individual
- Independent reconciliation by a person outside the conflicting function
- Enhanced audit logging on every action taken under the conflicting roles
03
Change Management
Controls over changes to financial applications, ensuring proper approval, testing, and separation of development from production environments.
Change Request & Approval Workflows
Every change to a financial system — from a configuration tweak to a full release — must be formally requested, risk-assessed, and approved before deployment. The approval authority depends on the change risk level.
Practical Examples
- Categorized change types (standard, normal, emergency) with distinct approval paths
- Risk-impact assessment for each change request, documented in the ticketing system
- Approval from both a technical reviewer and a business owner for changes to financial logic
- Automated workflow enforcement — deployment pipelines reject unapproved changes
Testing & QA for Financial System Changes
Changes to systems that process financial data require testing that explicitly verifies financial accuracy — not just functional correctness. Test cases must cover end-to-end transaction flows and reconciliation checks.
Practical Examples
- Dedicated test environment with production-equivalent data (anonymized)
- Test cases covering financial calculations, rounding, currency conversion
- User acceptance testing (UAT) sign-off from finance stakeholders, not just developers
- Regression test suites that re-verify existing financial logic after every change
Emergency Change Procedures
Emergency changes bypass the standard approval workflow. Auditors scrutinize these closely. The control is not to prevent emergency changes, but to ensure retroactive documentation, approval, and review happen within a defined window.
Practical Examples
- Defined criteria for what qualifies as an emergency change (production down, data corruption)
- Mandatory retroactive documentation and approval within 24-48 hours
- Post-incident review that evaluates whether the emergency designation was appropriate
- Reporting to management on emergency change frequency and root causes
Development/Production Separation
Developers must not have the ability to promote code directly into production financial systems. Separation of environments — enforced by access controls, not policy alone — is a foundational SOC 1 control.
Practical Examples
- Physically or logically separate development, staging, and production environments
- Developers cannot deploy to production, and a separate operations or release team handles deployments
- Production data is never used in development without anonymization
- Automated CI/CD pipelines that enforce the approval gate before production deployment
04
Data Integrity & Reconciliation
Validation, reconciliation, and error-handling controls that ensure financial data remains accurate and complete throughout processing.
Input Validation Controls
Data entering financial systems must be validated against business rules before acceptance. Input validation is the first line of defense against data corruption — and the most cost-effective one.
Practical Examples
- Mandatory field validation on all financial transaction inputs
- Format checks (valid account numbers, currency codes, date formats)
- Referential integrity checks (vendor exists in master file before payment is created)
- Duplicate detection at the point of entry (matching on key fields)
Processing Reconciliation
Reconciliation controls compare data across systems or processing stages to identify discrepancies. They are the primary detective control for ICFR — catching errors that preventive controls missed.
Practical Examples
- Daily automated reconciliation between subledger and general ledger
- Bank reconciliation performed and reviewed within defined SLAs
- Intercompany reconciliation for multi-entity organizations
- Automated matching with tolerance thresholds and exception routing
Output Verification
After processing, outputs (reports, feeds, payments) must be verified for accuracy and completeness before distribution. Output verification catches processing errors before they propagate to downstream systems.
Practical Examples
- Control totals on outbound payment files (count, sum, hash) verified before transmission
- Management review and sign-off on key financial reports before distribution
- Automated checksums on data feeds sent to downstream systems
- Sample-based manual verification of processed output against source documents
Exception Handling & Error Correction
When errors occur — and they will — a documented correction process ensures they are identified, logged, corrected by authorized personnel, and re-verified. Undocumented corrections are themselves a control deficiency.
Practical Examples
- Centralized exception queue with aging reports and escalation triggers
- Error correction requires approval from someone other than the person who made the error
- Full audit trail of all corrections including original value, corrected value, reason, and approver
- Root cause analysis for recurring exceptions fed back into preventive controls
05
Monitoring & Oversight
Management oversight processes including exception reporting, control self-assessments, and periodic reviews of financial controls.
Management Review Processes
Periodic management reviews evaluate whether controls are operating as designed. These are not rubber-stamp exercises — auditors look for evidence that reviewers identified issues, asked questions, and drove corrective action.
Practical Examples
- Monthly management review of key financial metrics with documented sign-off
- Quarterly review of control exceptions and remediation status
- Annual control effectiveness assessment presented to senior leadership
- Documented evidence that review findings led to specific corrective actions
Exception Reporting
Automated exception reports surface transactions and events that deviate from expected patterns. The control is not the report itself but the documented review and disposition of each exception.
Practical Examples
- Automated alerts for transactions exceeding defined thresholds
- Daily exception reports for failed reconciliations or processing errors
- Aging reports for unresolved exceptions with escalation thresholds
- Management sign-off on exception disposition (resolved, accepted, escalated)
Control Self-Assessments
Control owners periodically attest to the operating effectiveness of their controls. Self-assessments supplement — but do not replace — independent testing. They drive ownership and surface issues early.
Practical Examples
- Quarterly self-assessment questionnaires completed by control owners
- Evidence requirements tied to each self-assessment question
- Follow-up process for identified gaps with remediation timelines
- Results aggregated into a control health dashboard for management review
Key Performance & Risk Indicators
KPIs and KRIs provide early warning when control performance degrades. A rising error rate, growing exception backlog, or increasing access-review overdue count signals control weakness before it becomes a finding.
Practical Examples
- Processing error rates tracked against defined thresholds
- Access review completion rates monitored monthly
- Change management approval-cycle times measured against SLAs
- Exception resolution aging tracked with trend analysis
06
Subservice Organization Controls
Controls over third-party vendors and subservice organizations whose services affect your clients' financial reporting.
Vendor Due Diligence
Before onboarding a subservice organization, you must assess their control environment. This includes reviewing their SOC reports, evaluating their financial stability, and confirming their controls align with your ICFR obligations.
Practical Examples
- Annual review of subservice organization SOC 1 or SOC 2 reports
- Evaluation of CSOCs (Complementary Subservice Organization Controls) for applicability
- Assessment of subservice organization financial stability and business continuity posture
- Documented risk acceptance when subservice organization lacks a SOC report
Complementary Subservice Organization Controls (CSOCs)
CSOCs are controls that a subservice organization expects your organization to implement. They are the subservice equivalent of CUECs — and auditors verify that you have identified and implemented all applicable CSOCs.
Practical Examples
- Inventory of all CSOCs from each subservice organization SOC report
- Mapping of each CSOC to an implemented control in your environment
- Documented evidence of CSOC implementation and operating effectiveness
- Gap analysis when a subservice organization updates their CSOCs
Inclusive vs. Carve-Out Method
SOC 1 reports can include subservice organizations (inclusive method) or exclude them (carve-out method). The choice affects audit scope, cost, and what your clients' auditors need to do separately.
Practical Examples
- Inclusive method: subservice organization controls are tested within your SOC 1 report
- Carve-out method: subservice organization is excluded, and their own SOC report covers their controls
- Most organizations use the carve-out method — it is simpler and more common
- Your system description must clearly identify which subservice organizations are carved out
Ongoing Monitoring of Subservice Organizations
Due diligence is not a one-time exercise. Continuous monitoring of subservice organization performance, control changes, and SOC report findings ensures your ICFR environment remains sound.
Practical Examples
- Annual SOC report review cycle with documented assessment of findings
- SLA monitoring dashboards for subservice organization performance
- Incident notification procedures and escalation paths with subservice organizations
- Contractual right-to-audit clauses and periodic exercise of those rights
Scoping
How Control Objectives Are Defined
A critical misconception is that SOC 1 control objectives come from a standard checklist. They do not. Unlike SOC 2 — which maps to the five fixed Trust Service Criteria — SOC 1 control objectives are derived from your specific services and the ways those services could create material misstatement in your clients' financial records.
The scoping process starts with identifying which of your services are relevant to user entities' financial reporting. For each relevant service, you then identify the transaction flows, data elements, and processing logic that could go wrong — and define control objectives that address each risk.
Step 1: Service Mapping
Identify every service that touches client financial data. Map each service to the specific financial statement assertions it affects (completeness, accuracy, existence, valuation, presentation).
Step 2: Risk Identification
For each service, identify what could go wrong — unauthorized transactions, incomplete processing, inaccurate calculations, untimely posting. Each risk maps to one or more control objectives.
Step 3: Objective Definition
Write clear, testable control objectives that state what the control environment must achieve. Each objective should be specific enough that an auditor can design a test to evaluate it.
Example: A payroll processor might define the objective: “Controls provide reasonable assurance that payroll calculations are accurate, including gross pay, deductions, and net pay, based on authorized employee data and applicable tax tables.” This is specific to payroll processing — a payment gateway would never have this objective. The specificity is the point.
How Auditors Test
Control Testing Methods
CPA auditors use four methods to test whether your ICFR controls are designed appropriately and operating effectively. Understanding these methods helps you prepare evidence and train your team for auditor walkthroughs.
Inquiry
The auditor interviews control owners and operators to understand how the control works, who performs it, and what happens when exceptions occur.
Strengths
Fast, inexpensive, good for understanding control design and intent.
Limitations
Weakest form of evidence when used alone. Always combined with other methods for Type II reports.
Example
Interviewing the AP manager about how vendor payment approvals are handled and what happens when the primary approver is unavailable.
Inspection
The auditor examines documents, records, and system configurations to verify that the control exists and has operated as described.
Strengths
Provides tangible evidence of control existence and operation. Good for policy reviews and configuration verification.
Limitations
A document may exist without the control actually operating. Must be combined with other methods.
Example
Reviewing the change management log to verify that each sampled production change has documented approval, testing evidence, and deployment sign-off.
Observation
The auditor watches the control being performed in real time. Particularly useful for physical controls and manual processes.
Strengths
Confirms the control actually operates as described, not just that documentation exists.
Limitations
Point-in-time evidence only. The control may not operate consistently outside the observation window.
Example
Observing the month-end close process to verify that reconciliation reviews are performed, exceptions are investigated, and sign-offs are obtained.
Reperformance
The auditor independently re-executes the control to verify it produces the expected result. This is the strongest form of evidence.
Strengths
Highest assurance. Proves the control actually works, not just that someone claims it does.
Limitations
Most time-consuming and expensive. Typically used for the highest-risk controls.
Example
Re-running the three-way match on a sample of invoices to verify the system correctly identifies mismatches between purchase orders, goods receipts, and vendor invoices.
Practitioner Intelligence
Common Control Deficiencies & How to Remediate
Based on 100+ SOC 1 engagements, these are the findings we see most frequently in first-time and renewal engagements. Every one is preventable.
High Risk
Stale User Access
Terminated employees retaining system access after their last day. This is the single most common SOC 1 finding and the most preventable.
Remediation
Automate deprovisioning through HR-IAM integration. Implement same-day offboarding procedures with verification against HR termination records. Run quarterly access reviews with documented business-owner sign-off.
High Risk
Undocumented Emergency Changes
Production changes deployed under the emergency process without retroactive documentation or approval within the required window.
Remediation
Define strict criteria for emergency changes. Implement mandatory 24-48 hour retroactive documentation and approval. Track emergency change frequency and report to management monthly.
High Risk
Segregation of Duties Violations
A single individual holding incompatible access — such as the ability to both create vendors and approve payments — without documented compensating controls.
Remediation
Implement and enforce an SoD matrix with automated conflict detection. Where SoD cannot be achieved (small teams), document formal compensating controls with management sign-off.
Medium Risk
Incomplete Reconciliation Evidence
Reconciliations performed but not documented, or documented but missing evidence of management review and exception resolution.
Remediation
Standardize reconciliation templates that capture preparer, reviewer, date, exceptions identified, and resolution. Implement workflow tools that enforce the review step.
Medium Risk
Lack of Dev/Prod Separation
Developers with the ability to deploy directly to production financial systems, bypassing change approval and testing controls.
Remediation
Enforce environment separation through access controls. Implement CI/CD pipelines that require approval gates. Remove developer access to production and audit the access monthly.
Medium Risk
Missing Subservice Organization Monitoring
No documented review of subservice organization SOC reports, or failure to identify and implement applicable CSOCs.
Remediation
Establish an annual SOC report review calendar. Create a CSOC mapping document for each subservice organization. Document gap analysis and remediation for any unimplemented CSOCs.
Putting It Together
From Control Objectives to Clean Opinions
Building an ICFR control environment that produces a clean SOC 1 opinion is a structured process. It starts with scoping (which services affect client financial reporting), moves through control design and implementation, then into evidence collection and audit readiness.
The organizations that struggle are those that treat SOC 1 as a checklist exercise — downloading generic templates, filling in blanks, and hoping the auditor does not look too closely. The organizations that succeed are those that understand their specific ICFR risks, design controls that genuinely mitigate those risks, and build evidence collection into their daily operations rather than scrambling retroactively.
ICFR Control Category Quick Reference
| 01 | Transaction Processing Controls | Controls ensuring financial transactions are authorized, complete, accurate, and timely throughout the processing cycle. |
| 02 | Access & Segregation of Duties | Logical access restrictions and segregation of duties that prevent any single person from initiating and approving financial transactions. |
| 03 | Change Management | Controls over changes to financial applications, ensuring proper approval, testing, and separation of development from production environments. |
| 04 | Data Integrity & Reconciliation | Validation, reconciliation, and error-handling controls that ensure financial data remains accurate and complete throughout processing. |
| 05 | Monitoring & Oversight | Management oversight processes including exception reporting, control self-assessments, and periodic reviews of financial controls. |
| 06 | Subservice Organization Controls | Controls over third-party vendors and subservice organizations whose services affect your clients' financial reporting. |
Proof
In their words.
Quotes verbatim from G2. Company names added where the client confirmed them.
Instead of simply providing generic templates or checklists, their team took the time to understand our environment and requirements.
Anand .Market Risk Analyst · Mid-MarketCompliance readiness · September 2026
The team’s willingness to work with us and ease of communication.
sam v.CEO · Small-BusinessSOC 2 Type I + ISO 27001 · August 2026
They delivered the project with speed, accuracy, and cost-effectiveness.
Maneet P.Mid-MarketSOC 2 · August 2026
My only regret is that we didn’t engage them sooner in our compliance journey, which would have saved us even more time.
Mahesh Raju C. · XonarSmall-BusinessSOC 2 · GRC · August 2026
They were always responsive and willing to go the extra mile whenever we had questions or needed guidance.
Chandan J. · DsiderSmall-BusinessSOC 2 Type I · August 2026
Managing the auditor relationship on our behalf was especially valuable — it took a lot of pressure off our internal team.
Achyut B.Senior Software Engineer · Small-BusinessSOC 2 + ISO 27001 · September 2026
Their focus on ensuring that we were genuinely audit-ready rather than simply completing documentation.
Ravi V.Founder & CEO · Mid-MarketSOC 2 Type II · August 2026
The guidance was not generic or simply based on a standard checklist — they suggested practical approaches that made sense for our business.
Verified UserInternational Trade and Development · Small-BusinessSOC 2 + ISO 27001 · September 2026
What I like best is the hands-on support and clear guidance throughout the SOC 1 and SOC 2 process.
Sai Sudha S. · ExcersSmall-BusinessSOC 1 + SOC 2 · September 2026
ICFR Controls FAQ
Common questions about ICFR control objectives in SOC 1 engagements.
What does ICFR stand for, and why does it matter for SOC 1?
ICFR stands for Internal Control over Financial Reporting. It refers to the processes and controls an organization uses to ensure the reliability and accuracy of its financial statements. SOC 1 specifically evaluates the controls at a service organization that are relevant to user entities' ICFR — meaning the controls that affect your clients' ability to produce accurate financial statements. If your services touch client financial data (payroll, payments, loan servicing), your ICFR controls are what auditors test in a SOC 1 engagement.
Are ICFR control objectives the same for every SOC 1 report?
No. ICFR control objectives are specific to the services your organization provides. A payroll processor will have control objectives around payroll calculation accuracy and tax withholding completeness, while a payment gateway will focus on transaction authorization and settlement accuracy. The six categories (transaction processing, access, change management, data integrity, monitoring, subservice organizations) are common themes, but the specific objectives within each category are tailored to your service scope.
How many control objectives does a typical SOC 1 report have?
Most SOC 1 reports contain 8 to 25 control objectives, depending on the complexity of the services in scope. A straightforward payroll processor might have 10-12 objectives, while a multi-service financial platform could have 20+. Each control objective may have multiple individual controls supporting it. Tranquility Cybersecurity scopes objectives precisely to your service model — avoiding over-scoping that inflates audit cost and under-scoping that leaves gaps.
What is the difference between a control objective and a control activity?
A control objective is the goal — what the control environment should achieve (e.g., "transactions are processed completely and accurately"). A control activity is the specific action or mechanism that achieves the objective (e.g., "batch control totals are reconciled daily by the operations team"). Each control objective is supported by one or more control activities. The auditor tests the control activities to determine whether the control objective is met.
What happens when an auditor finds a control deficiency?
Control deficiencies are categorized by severity. A deficiency exists when a control is not designed properly or does not operate effectively. A significant deficiency is a deficiency, or combination of deficiencies, that is less severe than a material weakness yet important enough to merit attention. A material weakness means there is a reasonable possibility that a material misstatement would not be prevented or detected. Deficiencies are reported in the SOC 1 report. The auditor can still issue an opinion, but the exception will be visible to all report readers.
How does Tranquility Cybersecurity help with ICFR controls if it is not the auditor?
Tranquility acts as the readiness consultant and implementation partner — not the CPA auditor. We design your control objectives, write control descriptions, implement control activities, build your evidence collection processes, and prepare your team for auditor walkthroughs. When your controls are ready, we coordinate with an independent CPA firm from our network to perform the SSAE 18 attestation. This two-party model preserves auditor independence as required by AICPA standards.
What is the difference between CUECs and CSOCs?
CUECs (Complementary User Entity Controls) are controls that your clients must implement on their end to complete the control environment. CSOCs (Complementary Subservice Organization Controls) are controls that your subservice organizations expect you to implement. Both are documented in the SOC 1 report. CUECs tell your clients what they need to do, while CSOCs tell you what you need to do in relation to your vendors.
What does "carve-out" vs. "inclusive" method mean for subservice organizations?
These are the two methods for handling subservice organizations in a SOC 1 report. The carve-out method excludes the subservice organization's controls from your report — your system description identifies the carved-out entity, and your clients' auditors must obtain a separate SOC report from that entity. The inclusive method includes the subservice organization's controls in your SOC 1 report — the auditor tests them as part of your engagement. Most organizations use the carve-out method because it is simpler and avoids the logistical complexity of coordinating inclusive testing.
How often should ICFR controls be tested?
For SOC 1 Type II, controls must be tested across the entire observation period (typically 6 to 12 months). Daily controls are sampled across the period, while weekly and monthly controls may be tested at every occurrence. Annual controls (like access certifications) must have at least one instance within the period. Between audit cycles, Tranquility recommends continuous monitoring and quarterly self-assessments to catch control drift before the next audit window opens.
Can we use the same controls for SOC 1 and SOC 2?
Yes — significant overlap exists. Access management, change management, vendor oversight, and incident response controls appear in both frameworks. The difference is the lens: SOC 1 evaluates these controls for their relevance to financial reporting accuracy, while SOC 2 evaluates them against Trust Service Criteria (security, availability, etc.). Tranquility Cybersecurity designs integrated control frameworks that satisfy both, reducing duplicate effort and audit cost for organizations pursuing dual attestation.
Keep Exploring
Related Reading
SOC 1
SOC 1 Knowledge Hub
Every SOC 1 guide — Type I vs II, ICFR controls, timelines, costs — in one place.
Read moreSOC 1
Who Needs a SOC 1 Report?
The one-question test: does your service change customers' financial numbers?
Read moreSOC 2
Types of SOC Reports
SOC 1 vs SOC 2 vs SOC 3 — audiences, criteria, and which one buyers ask for.
Read moreSOC 1
SOC 1 vs SOC 2
ICFR financial controls vs security and trust — which one, or both.
Read moreSOC 1
SOC 1 Cost Guide
What to budget for SOC 1 Type I and Type II — consulting + CPA fees.
Read moreSOC 1
SOC 1 Timeline
From scoping to CPA-attested report — phase-by-phase roadmap.
Read moreThe Learn Library
Go deeper.
SOC 1 · Learn
AT-C 320, Explained
The attestation standard every SOC 1 examination runs under.
Read moreSOC 1 · Learn
SOC 1 Bridge Letters
Covering the gap between report periods without losing assurance.
Read moreSOC 1 · Learn
SOC 1 Description Criteria
What the system description must contain — and how auditors read it.
Read moreSOC 1 · Learn
SSAE 18 vs SSAE 21
How the governing standards changed and what it means for your report.
Read moreLearn
SOC 1 vs SOC 2 vs SOC 3
Which report answers which question, and who may rely on each.
Read moreLearn
CUECs & CSOCs Explained
The controls a report assumes of you — the most skipped step in vendor risk.
Read more