Contracts and renewals
Finance-adjacent customers often make a SOC 1 report a condition of onboarding or renewal. Without it, their auditors may need to test you directly, which slows deals.
Board and leadership view
Why SOC 1 matters to your board
The work is technical. The consequences of getting SOC 1 wrong show up in revenue, liability and reputation, which is why we report on it in the language of the boardroom first.
Liability and exposure
Errors in financial processing can flow into your customers' statements. Well-defined, tested controls reduce the chance of disputes over who was responsible.
Reputation with auditors
Customers' auditors talk to each other. A clean, well-organised report makes you easy to rely on, and exceptions handled openly build trust.
Deadlines and ownership
The reporting period drives the calendar. Someone senior needs to own scope, evidence and the date customers expect the report.
Fit
Who usually needs SOC 1
Payments and billing providers
If you process transactions or invoices for customers, their auditors need comfort over accuracy and completeness.
Payroll and HR outsourcers
Payroll runs feed customers' ledgers directly, so auditors ask how calculations and changes are controlled.
Hosting and platform providers for finance systems
When a customer's ERP or ledger runs on your infrastructure, access and change controls come under review.
Fund administrators, lenders and loan servicers
Valuation, cash movement and reporting for investors and borrowers are classic SOC 1 territory.
Scope of work
What Summit delivers for SOC 1
One accountable team takes you from scoping to retest. The people who test your systems are the people who explain the findings to your leadership.
Gap analysis
A clear view of your controls against the objectives and ITGC expectations, with owners and a prioritised fix list.
Penetration testing
Manual testing of in-scope applications and infrastructure, focused on access and transaction integrity.
Control validation
We test your controls the way an examiner would, so weaknesses surface before the period starts.
Evidence pack
Organised, dated evidence mapped to each control so the examination runs smoothly.
Remediation support and retest
Guidance while your team fixes findings, then a retest to confirm they are closed.
Board-ready report
A plain-English summary of status, risks and decisions for executives, with technical detail behind it.
Fixed scope, one team, no hand-offsYou get a named lead, a clear scope document before work starts and a report your leadership, customers and reviewers can read without a translator. We stay with you through your review to answer questions about what we tested and found.
How it works
A realistic SOC 1 roadmap
Timelines are typical ranges, not promises. Yours depends on scope, team size and how much is already in place.
- 1
Define scope and objectives
Weeks 1 to 2Confirm the services, systems and customer financial processes in scope, and draft control objectives with your auditor in mind.
- 2
Run a gap analysis and close gaps
Weeks 2 to 12Compare existing controls with the objectives and ITGC expectations, then fix what is missing so controls leave evidence by default: tickets, approvals, review sign-offs and logs.
- 3
Validate controls and test security
Month 2 to 3Test the controls as an auditor would, and run penetration testing on in-scope systems so access weaknesses are fixed before the period starts.
- 4
Operate through the period
3 to 12 monthsFor Type II, controls must run consistently for the whole period. Keep evidence organised as you go.
- 5
Examination and report
4 to 8 weeksThe CPA firm tests samples, raises questions and issues the report with its opinion.
Deliverables
What your leadership team receives
Every engagement ends with material written for two audiences: a plain-language view for executives and the board, and full technical detail for the engineers who fix things.
Which services touch customer financials?
Name the processes whose errors would change a customer's numbers. That defines scope.
Who owns each control?
Every control needs a named owner who will produce evidence, not just a policy.
Have we told customers what they must do?
Complementary user entity controls only work if customers know about them.
Are our subservice organisations covered?
Decide how cloud and processing vendors are treated and what evidence you hold.
When does the period start?
Do not start a Type II period until controls run reliably; exceptions inside the period are permanent.
The detail
What SOC 1 actually is
SOC 1 is an attestation report on the controls at a service organisation that are relevant to your customers' financial reporting. It is issued by a licensed CPA firm under SSAE 18 in the United States, or under ISAE 3402 internationally. The aim is simple: let a customer's auditor rely on your controls instead of testing them one customer at a time.
Unlike SOC 2, where the criteria are fixed, a SOC 1 starts with control objectives you define for the services you provide, such as "payments are processed completely and accurately". The auditor tests the controls that meet those objectives, plus the IT general controls (ITGCs) underneath them: access, change management and operations.
A Type I report covers design on a single date. A Type II report also tests whether controls operated effectively across a period, which is what most customers' auditors want. The report is restricted to your management, your customers and their auditors, and it lists complementary user entity controls (CUECs), the things your customers must do on their side for the control objectives to hold.
Key terms in plain English
- Service organisation
- The company being examined, such as a payroll, payments, billing, hosting or claims-processing provider.
- User entity
- A customer whose financial reporting relies on the service you provide.
- ITGCs
- IT general controls over access, change management and operations that support the systems producing financial data.
- CUECs
- Complementary user entity controls: controls your customers must operate for your control objectives to be met.
Requirements
What auditors test in a SOC 1
A SOC 1 has no fixed checklist. The control objectives are yours to define and the auditor tests against them. These are the building blocks that most reports contain.
1
Control objectives tied to the service you provide
You and the auditor agree what could go wrong for a customer's financial statements, then write objectives that cover it. Good objectives are specific to your service, not generic.
What it looks like in practice
- Objectives written in terms of completeness, accuracy and authorisation
- Each objective mapped to named controls and owners
- A clear boundary showing which systems and processes are in scope
2
ITGC: logical access
Auditors check that only the right people can reach systems and data that affect customer transactions, and that privileged access is limited and reviewed.
What it looks like in practice
- Joiner, mover and leaver processes with evidence
- Periodic access reviews signed off by owners
- Multi-factor authentication and tight control of administrator accounts
3
ITGC: change management
Changes to applications, databases and infrastructure should be requested, tested, approved and released in a controlled way, so a calculation cannot be altered unnoticed.
What it looks like in practice
- Tickets showing approval before release
- Separation between those who build and those who deploy
- Emergency changes reviewed after the event
4
ITGC: computer operations
Jobs run, backups complete and incidents are handled. Auditors look for monitoring that shows failures are noticed and fixed.
What it looks like in practice
- Batch job monitoring with exception follow-up
- Backup success checks and restore tests
- Incident records with root cause and closure
5
Application and process controls
These are the controls closest to the numbers: input checks, reconciliations, approvals and report review. They are usually where customers' auditors focus first.
What it looks like in practice
- Reconciliations performed and reviewed on schedule
- Automated validation of inputs and calculations
- Management review of exception reports
Where testing fits
How penetration testing supports SOC 1
SOC 1 does not prescribe penetration testing. It does expect strong logical access and change controls over systems that process financial data, and a manual test is a practical way to show those controls hold up against a real attacker.
ITGC
Logical access
Testing shows whether authentication, authorisation and privilege boundaries on in-scope applications can be bypassed.
ITGC
Change management
Findings from testing feed the change process, and a retest proves fixes were released and verified.
Control objective
Authorisation of transactions
Business-logic testing checks whether a user can approve, alter or replay a transaction they should not.
Evidence
Independent testing record
A clear report, remediation log and retest give the examiner something concrete to read alongside your own control evidence.
Avoid these
Common SOC 1 mistakes, and how to avoid them
!
Writing vague control objectives
Generic objectives are hard to test and do not help customers' auditors. Tie each one to a financial process you actually run.
!
Ignoring complementary user entity controls
If your customers do not operate the controls you rely on, the objectives may not be met. State them clearly and tell customers early.
!
Choosing SOC 1 when customers want SOC 2
SOC 1 is about financial reporting. If buyers ask about security, availability or confidentiality, SOC 2 is usually the report they mean.
!
Forgetting subservice organisations
If a cloud or processing vendor supports your service, decide whether to carve it out or include it, and manage the controls you depend on.
FAQ
SOC 1 questions, answered
What is a SOC 1 report?
A SOC 1 report is an attestation by a licensed CPA firm on controls at a service organisation that are relevant to its customers' financial reporting. Customers' auditors use it to rely on your controls.
How is SOC 1 different from SOC 2?
SOC 1 covers controls relevant to financial reporting, against control objectives you define. SOC 2 covers security, availability, processing integrity, confidentiality and privacy against fixed AICPA criteria. Many providers need both.
What is the difference between Type I and Type II?
Type I looks at whether controls are suitably designed on one date. Type II also tests whether they operated effectively over a period, commonly six to twelve months for a first report.
What are ITGCs?
IT general controls are the access, change management and operations controls that support the systems producing financial data. Auditors test them because weak ITGCs undermine every automated control above them.
What are complementary user entity controls?
They are controls your customers must perform for your control objectives to be achieved, such as reviewing user access to your platform. The report lists them so customers and their auditors know their part.
Is SOC 1 the same as ISAE 3402?
They are closely aligned. SSAE 18 is the US standard and ISAE 3402 is the international one, and a single examination can often be reported under both.
Does SOC 1 require a penetration test?
No. Penetration testing is not named as a requirement, but many service organisations use it as supporting evidence for logical access and change controls over in-scope systems.
Related frameworks
Often assessed alongside SOC 1
Security assuranceSOC 2The report enterprise buyers ask for first. Learn the five Trust Services Criteria, Type I vs Type II, and where penetration testing fits.Security assuranceISO 27001The international standard for an information security management system. Clauses, the 93 Annex A controls, and how certification works.Third-party riskVendor & TPRMHow to pass vendor security reviews faster: questionnaires (SIG, CAIQ), evidence packs and the vendor risk lifecycle.
Browse all 23 security and compliance frameworks or see our penetration testing services.
Helpful resources
ChecklistPre-launch security checklistKeep reading on the Summit resources hub.ReportSample VAPT reportKeep reading on the Summit resources hub.GlossarySecurity glossaryKeep reading on the Summit resources hub.
Last reviewed October 2026. Requirements change; confirm current texts and dates before you commit to a plan.