SOC 2 can help a business show customers how it manages important information and technology risks. The work is not just a binder of policies: it involves defining what is in scope, putting controls into practice, and keeping evidence that shows how those controls operate. A practical plan makes that work easier to manage and more useful after the audit.
Talk with IGTech365 about this article
Send a note and we will reply from this page.
Talk with IGTech365 about your IT environment
What does SOC 2 tell a customer?
SOC 2 is an independent examination and report concerning controls at a service organization. It is commonly relevant when a business handles customer data or provides a service that depends on systems, people, and processes. A report can give customers a structured way to understand how controls are designed and, for a Type II report, how they operated over a period of time.
SOC 2 is not a government license, a product feature, or a one-time technical installation. The report is produced by an independent CPA firm following an examination. A business should avoid describing itself as “SOC 2 certified”; it may instead describe the report it has completed, subject to the report’s terms and any restrictions on sharing it.
The Trust Services Criteria used in SOC 2 address security, availability, processing integrity, confidentiality, and privacy. Security is the common foundation. The other categories may be included when they fit the services and commitments being examined. The right scope depends on what the company does and what its customers expect, not on choosing every category by default.
For formal information about SOC reporting, consult the American Institute of CPAs. An auditor can explain how the criteria apply to a specific engagement.
Which SOC 2 report type fits your goal?
The choice between Type I and Type II affects what the examination demonstrates and how much preparation is needed. A Type I report addresses whether controls are suitably designed at a specified point in time. A Type II report considers design and operating effectiveness across a defined period. The auditor and the business agree on the examination scope and period.
| Consideration | Type I | Type II |
|---|---|---|
| What it evaluates | Control design at a point in time | Control design and operation during a period |
| Evidence focus | Policies, configurations, and evidence that controls are in place on the examination date | Those materials plus evidence showing recurring controls operated throughout the period |
| Typical planning implication | Prepare for a defined point-in-time review | Plan ahead for repeated evidence collection and consistent execution |
| Useful question to ask | Will this meet the immediate request, and what follow-up is expected? | Can we sustain the controls and evidence routine over the agreed period? |
Neither report is automatically the right choice for every company. Ask customers or prospects what they require, whether they specify a report type or period, how they expect the report to be shared, and whether a bridge letter or other information will be requested later. Also confirm the expected scope with the auditor before making commitments.
How should you define the scope?
Start with the service that prompted the request. Map how customer information enters, moves through, and leaves that service. Include the systems, locations, employees, vendors, and processes that support it. A cloud application may be part of the picture, but so can identity management, endpoints, backup, change approval, and staff onboarding.
Write down the boundaries in plain language. For example: “The examination covers the hosted service used by these customers and the staff who administer it.” Then identify systems that are outside the boundary and explain why. A vague boundary creates confusion: teams may overlook a supporting platform or spend effort documenting systems that do not affect the service.
Use a simple flow diagram or inventory to connect data to systems and owners. For each system, record its business purpose, the information it handles, who administers it, and whether a vendor operates part of it. If the service depends on Microsoft 365 or cloud infrastructure, include the relevant administration and access processes rather than assuming that a provider’s security controls cover everything your company does. IGTech365’s Microsoft 365 services and cloud migration guidance provide relevant context for these environments.
What should you assess before the audit?
Compare your current practices with the commitments you make to customers and the controls the auditor expects to examine. This is a readiness review, not a promise that every gap can be fixed by a particular date. Assign an owner to each gap, record the risk it addresses, and set a realistic due date.
- Access: Who approves access, how is it removed when someone changes roles or leaves, and how are privileged accounts reviewed?
- Devices and configuration: Are company-managed endpoints identified, protected, updated, and handled consistently?
- Change management: Are changes tested, approved, recorded, and reversible when needed?
- Security events: Do employees know how to report a suspected incident, and can the responsible people find the response steps?
- Backups and recovery: Are backup jobs monitored, recovery responsibilities clear, and restoration tests recorded?
- Vendors: Which providers support the service, what information or access do they have, and how are their risks reviewed?
- People and policies: Are responsibilities, training, acceptable use, and disciplinary processes documented and followed?
Do not rely on policy language alone. If a written procedure says access is reviewed quarterly, retain evidence that a review happened and that identified changes were completed. If backups are tested, keep the date, scope, result, and follow-up actions. Evidence should be genuine and produced through normal work—not reconstructed to create the appearance that a control operated when it did not.
How can you prepare in a manageable sequence?
- Confirm the business need. Ask the requesting customer what report, service boundary, Trust Services Criteria, and timing they expect. Note any contract language or procurement deadline that needs review.
- Choose the scope and auditor. Document the service boundary and discuss it with an independent CPA firm early. Ask about evidence expectations, the examination period, communication cadence, and how exceptions are handled.
- Assign owners. Name an accountable person for each control area. The owner may coordinate work across IT, operations, HR, legal, and leadership; responsibility should not disappear into a shared inbox.
- Perform a gap review. Compare current practice with planned controls. Prioritize gaps that affect customer data, system access, service availability, or contractual commitments.
- Implement and test changes. Put procedures into daily use. Check that technology settings and staff workflows match the written process, and record remediation when a test reveals a problem.
- Collect evidence as work happens. Store approved policies, access reviews, change records, training completion, incident records, vendor reviews, and backup or recovery tests in a controlled location.
- Review readiness with the auditor. Confirm the scope, evidence format, dates, and open issues before fieldwork. Do not promise a clean report or an outcome before the independent examination.
- Plan to maintain the controls. Put recurring tasks on a calendar, define who checks completion, and review changes to systems, vendors, and customer commitments.
A spreadsheet can be enough to coordinate the first pass, provided it has an owner, due date, status, evidence location, and review history for each item. Keep access to evidence limited to people who need it. Avoid placing sensitive logs or customer records in an uncontrolled shared folder.
How do you make evidence useful?
Good evidence answers three questions: what happened, when did it happen, and who performed or approved it? A screenshot with no date or context may be difficult to interpret. A dated access-review record that lists the reviewer, systems checked, exceptions, and closure evidence is much stronger.
Set a consistent naming and storage approach. For example, keep evidence by control area and period, and use filenames that identify the task and date. Preserve source records where possible rather than relying only on copied images. Record exceptions honestly and attach the remediation plan. If a control did not operate as intended, the team should investigate and document the response instead of hiding the gap.
Automate evidence collection only when the result is reliable and the person responsible can explain it. Automation can reduce repetitive work, but it does not establish that a control is appropriately designed or that someone followed up on a failure.
What mistakes commonly create extra work?
- Starting with a generic checklist. A template may help organize thinking, but it cannot determine your service boundary or customer commitments.
- Writing policies before learning the real workflow. Procedures that staff cannot follow create a mismatch between documentation and operation.
- Leaving ownership unclear. Controls that depend on “the IT team” can be missed when no one is accountable for completion and evidence.
- Waiting until fieldwork to collect records. A Type II examination requires evidence over time, so late preparation can reveal missing history that cannot simply be recreated.
- Assuming a vendor covers your responsibilities. Providers may operate some controls, while your business remains responsible for its users, configurations, decisions, and customer communications.
- Treating the report as the finish line. Systems and staff change. Recurring reviews help keep controls relevant and make future examinations less disruptive.
If your preparation exposes foundational IT work—such as unclear device ownership, inconsistent access removal, or backups without a tested recovery process—address those issues as operational risks, not merely audit paperwork. A structured managed IT approach can help coordinate ongoing technology operations. Businesses considering outside support should first define responsibilities and review the service scope; IGTech365 also outlines its managed services agreement.
Discuss your SOC 2 readiness questions
How does business continuity relate to SOC 2?
Business continuity is not a substitute for a SOC 2 examination, and a continuity plan alone does not establish that the relevant controls are in place. But continuity planning can support the dependable operation of a service. Define how the business will respond if a critical system, office, provider, or key employee is unavailable. Identify decision-makers, communication steps, recovery priorities, and dependencies.
Make plans testable. A tabletop exercise can walk through who will make decisions and how teams will communicate. A recovery test can show whether the documented steps work for a chosen system. Record the scenario, participants, results, and follow-up tasks. Keep scope realistic, and do not claim a recovery time or outcome unless the business has validated it. IT operations such as server management and a reviewed managed IT service plan may be part of the underlying operational picture.
Frequently asked questions
Is SOC 2 a certification?
No. SOC 2 results in an independent report about controls within a defined scope. Be precise about the report completed and avoid calling it a certification.
How long does SOC 2 preparation take?
There is no single timeline that fits every organization. Scope, current practices, open gaps, auditor scheduling, and the report type all affect the plan. A Type II examination also requires an agreed operating period, so discuss timing with the auditor before setting expectations.
Can a small business pursue SOC 2?
Company size alone does not answer whether SOC 2 makes sense. Consider customer requirements, the service being examined, available owners, and the effort to operate controls consistently. An early scope discussion can help determine whether the work aligns with a real business need.
Does SOC 2 guarantee that a business will not have a security incident?
No. A report describes an examination of controls within its defined scope and period. It is not a guarantee against incidents, and customers should review the report and its limitations rather than assume it eliminates risk.
Call IGTech365 at (866) 365-7798
What should you do next?
Start by confirming what your customer needs, mapping the service and systems in scope, and identifying who will own the work. Then speak with an independent auditor about the appropriate report and build a realistic plan for controls and evidence. This approach helps turn SOC 2 preparation into repeatable operating practice rather than a last-minute document exercise.