SOC 2 readiness, controls and independent attestation: a practical business guide

What is SOC 2?

SOC 2 is an independent assurance examination and report about controls at a service organisation, using relevant AICPA Trust Services Criteria. It helps customers evaluate risks associated with an outsourced service. It is not an ISO certificate, a government licence or a guarantee that a business cannot experience a security incident. An independent CPA firm performs the examination; management remains responsible for its system and controls. See the AICPA overview of SOC services.

For a business preparing for SOC 2, the practical questions are straightforward: what service do customers rely on, what have you promised them, what could prevent you from keeping those promises, and what records show that your controls work? Answer those questions before counting policies or comparing the number of automated checks in a platform.

This guide combines a concise explanation of the assurance model with original implementation advice and hypothetical examples. Example workflows and suggested records are planning tools, not a universal list of mandatory controls. Your actual scope, commitments, criteria and independent examiner’s requirements govern the engagement.

Start with the customer decision, not the badge

A SOC 2 request often appears late in a sales process. Procurement may ask for a report without explaining whether it covers a specific product, data centre, outsourced operation or group of services. If your team treats that request as a demand for a generic badge, you can spend months preparing the wrong scope. Ask the customer’s security or vendor-risk contact what service they are assessing, which report type they expect and when they need it.

Put those answers into an assurance brief. Record the customer request, the service name used in the contract, relevant data, locations, dependencies, intended report users and target decision date. Distinguish a request for an issued report from willingness to review an interim readiness plan. A sales deadline does not establish that controls are ready or that enough evidence exists for an examination.

Consider a software company selling both a production application and a managed support service. A report describing only the application’s hosting environment may not answer questions about support agents who can access customer records. Similarly, a BPO’s head-office policies may say little about the delivery team, remote desktops and client-specific procedures that actually handle the work. The assurance brief exposes these mismatches early.

The commercial objective should also be explicit. Are you qualifying for enterprise tenders, reducing repeated security questionnaires, retaining a major customer or strengthening internal oversight? Each objective suggests a different way to measure value. Record both the opportunity and the operational improvement you want, such as faster access removal, clearer supplier responsibilities or reliable incident escalation.

Do not present projected sales as guaranteed returns from a report. A practical business case shows which deals request assurance, which internal weaknesses need investment and what ongoing effort the organisation can sustain. Management can then compare the cost of a properly scoped programme with the consequences of delaying it.

Type 1 and Type 2 answer different questions

A Type 1 report addresses the system description and suitability of control design at a specified date. A Type 2 report also addresses control operating effectiveness over a specified period. The period is part of the engagement, not an optional marketing label. The AICPA’s illustrative Type 2 report shows the relationship between management’s assertion, the system description, the auditor’s report and tests of controls.

There is no benefit in selecting a report type without considering its intended recipient. A Type 1 report can support a particular customer conversation, but it will not satisfy a contract that expressly requires Type 2. Conversely, insisting on an unnecessarily broad first examination may distract a small organisation from fixing more immediate control weaknesses.

Build the timetable backwards from a realistic delivery date. Separate readiness work, the examination date or period, the independent firm’s testing and reporting, and your internal approval of the final description. Leave room for queries and corrections. Ask the examiner how changes during the period, newly introduced controls and missing historical records would affect the engagement.

A hypothetical SaaS business might have sound technical controls but no reliable evidence of quarterly access reviews. Its readiness plan should arrange the review process and retain its outputs before promising historical effectiveness. Producing a policy today cannot demonstrate that a review took place months ago. Genuine contemporaneous evidence is more useful than a polished explanation written at the last moment.

Define the system customers actually use

A useful scope describes a service rather than merely a legal entity or a list of servers. Start with a plain-language statement: who uses the service, what it does, what information it handles and which commitments matter. Then trace how people, technology and external providers deliver that service. Include interfaces where information enters, changes, moves and leaves.

Run a scoping workshop with operations, engineering, information security, HR, procurement and the commercial owner. Give each participant a concrete task. Engineering explains deployment and support access. Operations shows how work is assigned and checked. HR explains joiners, movers and leavers. Procurement identifies critical providers. Sales produces relevant commitments instead of relying on recollection.

For a BPO, trace one representative transaction from receipt to completion. Ask where the data is displayed, whether it can be downloaded, who supervises processing, how exceptions are escalated and what happens when an employee leaves. Include client-owned systems where your staff have access, even when your business does not own the infrastructure. Ownership and responsibility are different questions.

For a software provider, trace a production change and a support request. Identify source repositories, build systems, cloud accounts, customer environments, privileged support tools and monitoring services. Decide which products, locations and organisational functions are included. If a recently acquired business is excluded, describe the boundary and test whether shared personnel or systems create dependencies.

Record assumptions and exclusions with reasons. An exclusion should survive a simple challenge: could a failure in this excluded area affect the in-scope service or the commitments described? If yes, examine the interface and relevant responsibilities. A scope that looks convenient but leaves a critical dependency unexplained can create more questions than it resolves.

The output should be a concise scope statement, an understandable architecture or service-flow diagram and a responsibility map. Keep them consistent with customer-facing descriptions. Changes to products, outsourcing or service delivery should trigger review; the scope should not remain frozen while the business changes underneath it.

Choose relevant Trust Services Categories

The AICPA Trust Services Criteria address security, availability, processing integrity, confidentiality and privacy. The appropriate engagement scope depends on the system and relevant commitments; the categories should not be treated as a package of interchangeable badges. Use the official Trust Services Criteria when establishing the criteria for your programme.

Our recommended planning method is to build a commitments register before expanding the scope. Take statements from contracts, service descriptions, security responses, privacy notices and internal policies. Assign an owner to each commitment and identify how it is implemented. A promise that cannot be connected to an operating practice needs attention regardless of which assurance programme you pursue.

For availability, explore the actual service commitments: permitted downtime, recovery expectations, maintenance windows and dependencies. A backup-success dashboard alone does not establish that a service can be restored within the times your customers expect. Design a recovery exercise that tests a meaningful business service and produces actions, owners and follow-up evidence.

For processing integrity, consider the processing outcomes your service promises. A BPO may need to control completeness, accuracy and handling of exceptions in a customer workflow. A software service may need checks around input validation and failed transactions. The precise controls depend on that system; a generic infrastructure checklist may miss the operational issue.

For confidentiality and privacy, separate different obligations and information types. Commercially sensitive product designs, patient information and employee records do not create identical responsibilities. Identify the commitments and applicable legal questions, involve the appropriate advisers and avoid treating inclusion of a category as automatic compliance with a particular law.

Review the category decision with the independent examiner before significant implementation work. Record why the selected scope answers the customer’s need. This is more defensible than adding categories simply to make a proposal sound comprehensive, or excluding one without checking a contractual promise.

Use the readiness assessment to make decisions

A readiness assessment should produce an actionable view of the work ahead. It is not just a percentage score, and it is not the independent SOC 2 report. The useful outcome is a set of supported findings that distinguishes missing controls, weak design, inconsistent operation and missing evidence. Those are different problems and require different remedies.

For each proposed control, ask an owner to demonstrate a recent example. If the control is access removal, follow an actual leaver through HR notification, identity disablement, application permissions and equipment return. If the control is change approval, trace an actual production change through request, review, test, release and any emergency exception. Inspect a reasonable range of cases for planning rather than selecting only the neatest example.

Classify each gap by its business consequence, dependencies and effort. A missing policy title might take an afternoon to correct. Unmanaged privileged access across customer environments may require architecture changes, account discovery, migration and staff training. Giving both findings the same red status hides the management decision that matters.

Build a remediation register with an accountable owner, target date, expected evidence and acceptance method. Include an escalation path where delivery depends on a customer, supplier or budget decision. The sponsor should see blocked actions separately from overdue tasks so that management can remove obstacles rather than repeatedly asking teams to update a spreadsheet.

A hypothetical finding might read: support engineers share a privileged account; individual activity cannot be reliably attributed; introduce individual privileged access with approved emergency access; retain provisioning records and review logs; operations owns implementation; security reviews completion. That finding gives management a problem, an action and a way to check the result.

Use the readiness review to test the programme’s practicality. If a proposed control needs weekly manual evidence from a team that cannot perform it, revise the process before publishing the policy. A realistic process that addresses risk and can be demonstrated is stronger than an ambitious statement that staff routinely ignore.

Give controls clear owners and workable procedures

Controls are performed by people and systems, not by the compliance folder. Each significant control needs an owner who understands its purpose, a repeatable activity, a defined trigger or frequency, evidence and an escalation route. The owner may delegate tasks, but accountability for checking that the process works should remain clear.

Start with the workflows already used by the organisation. Put approval into the existing ticketing process, offboarding into the existing HR workflow and change records into the development tool where work happens. Creating a parallel process solely for an examination often leads to duplicate effort and contradictory records.

Write procedures at the level the performer needs. “Review access regularly” gives little help. A usable procedure identifies the systems, the reviewer, the list being checked, what to challenge, how exceptions are resolved and where the decision is retained. It should also cover the unavailable reviewer, unusual account and overdue action.

Leadership oversight should focus on decisions. A management dashboard can show unresolved high-risk issues, missed controls, supplier changes and recurring exceptions. The meeting record should explain what was decided and who will act, rather than simply noting that management “reviewed compliance”. Staff need evidence that escalation leads to action.

Consider segregation and reviewer independence proportionately. A small company may have limited people, but it can still identify where self-approval creates a risk and arrange a meaningful second review. Document the arrangement and test whether it operates. Avoid copying the organisational model of a large enterprise into a business that cannot sustain it.

Training should follow responsibility. A developer needs to understand secure changes and secret handling; a support agent needs customer-data handling and escalation; a manager needs approval responsibilities and exceptions. General awareness is useful, but it cannot replace learning how to perform an assigned control correctly.

For a procedure you need to build, follow the relevant workflow guide: access decisions, software changes, incident handling or supplier oversight.

Collect evidence as work happens

Evidence collection works best when it is part of normal operations. Decide what a completed control should leave behind, where that record is stored and who can access it. Avoid a year-end search for screenshots from systems that retain information for only a few weeks. Retention and export settings should be checked before the relevant period begins.

Use an evidence map with a control reference, owner, frequency, source system, expected record, retention location and review status. A useful record shows the activity, timing, relevant population and result. Depending on the process, it may be a ticket, approved review, system export, meeting decision or test output. The format matters less than whether another person can understand and corroborate it.

Check completeness as well as presence. An access-review screenshot might show that someone opened a spreadsheet, but not which accounts were included or whether discrepancies were resolved. A change ticket might contain approval but no link to the actual release. Look for the chain connecting the activity to its purpose and outcome.

Distinguish evidence preservation from evidence creation. If an activity was missed, record the gap honestly, investigate its effect and fix the process. Do not backdate a review, fabricate a ticket or describe a current screenshot as historical proof. An examiner needs truthful records, and management needs an accurate view of its operating weaknesses.

Keep evidence secure. Audit material can reveal privileged accounts, architecture, employee information and sensitive customer data. Agree access, sharing and retention with the examiner. Use redaction carefully: remove unnecessary sensitive information without removing the details needed to understand the control. Do not upload credentials, production secrets or unrelated personal records to a general enquiry form.

Run a monthly evidence health check as an internal management practice. Look for missing owners, empty periods, broken exports, inaccessible records and recurring reviewer comments. Correcting these early reduces disruption later. The purpose is a dependable record of operation, not a growing archive that nobody can interpret.

Use automation to reduce administration, with human review

Automation can organise tasks, link evidence, remind owners and collect information from connected systems. It can reduce repetitive administration, but a green dashboard does not prove that your scope is complete or that a control meets your business commitments. People still need to decide what matters and investigate exceptions.

Before selecting a platform, ask which workflows it will support. Can it reflect your service scope, control owners and approval process? Can evidence be exported in a usable form? How are connector permissions managed? What happens when a connected system changes or an integration stops collecting records? Those questions are more useful than comparing headline counts of automated tests.

Test one representative process before expanding. For example, connect an access-review workflow, trace the population, assign a reviewer, resolve an exception and export the final evidence. Check whether the result is understandable without relying on the platform’s proprietary score. If the process cannot be explained, adding more integrations will not solve the underlying issue.

CyberVantage360 can discuss how Effivity ISO & GRC software and Sterling Academy training fit the agreed programme. Confirm the product scope, licensing, available workflows and learning needs in the proposal. Software and training should support your control owners; neither substitutes for management’s responsibility or the independent examiner’s work.

Keep the assurance relationship clear when software, consulting and examination are offered together. Know which legal entity provides each service, who has access to evidence and how fees and responsibilities are separated. Choose the combination that helps the organisation operate effectively and lets the independent firm exercise its own judgement.

Account for cloud providers and other suppliers

Outsourcing infrastructure or a business process changes the responsibility map; it does not remove the need to understand it. List providers that support the service and identify what each one does, what data it handles and which commitments depend on it. Include less obvious dependencies such as identity platforms, support tools and outsourced administration.

A practical supplier file should help an owner answer three questions: why do we trust this provider for this use, what responsibilities remain with us, and what will we do if the provider changes or fails? Keep relevant contracts, assurance evidence, assessments and decisions together. Review the specific service and locations covered by a supplier’s report rather than accepting a logo.

For a cloud-hosted SaaS service, the cloud provider may operate physical infrastructure while your team controls application permissions, configurations, deployments and customer support. A provider’s assurance report cannot demonstrate how your employees review access or how your software changes are approved. Map the handoffs and retain evidence for your own responsibilities.

Discuss the treatment of relevant subservice organisations with the examiner. Do not select reporting terminology because it appears in a competitor’s report. Ensure that your system description, supplier oversight and responsibilities are consistent. Where customers also need to perform controls, communicate those responsibilities clearly and make them realistic for the service being delivered.

Review supplier changes as events, not just calendar tasks. A new data-processing location, acquisition, incident, contract change or critical subcontractor may alter your risk assessment. Assign someone to evaluate the change and record the response. This approach makes supplier management useful to operations as well as to assurance.

Write the system description from verified facts

The system description should explain the service and control environment accurately enough for intended users to understand the report. AICPA publishes description criteria for preparing and evaluating this part of a SOC 2 engagement. It should be aligned with the system actually examined, not assembled from unrelated marketing material.

Draft the description while scoping and implementation are progressing. Assign factual sections to people who know the operations: engineering for architecture, HR for workforce processes, operations for service delivery and security for control coordination. Have management resolve inconsistencies before the examiner receives competing accounts of the same process.

Read it as a customer would. Does the product name match the contract? Are included locations and functions understandable? Can a reader identify significant dependencies and responsibilities? Does the description make claims that the evidence cannot support? A clear explanation of a limited scope is more useful than a broad statement that conceals uncertainty.

Use a change log for significant developments during the period. New products, migrations, acquisitions and major incidents can affect what needs to be described and how controls are tested. Involve the examiner when these events arise. Waiting until the final report draft can create avoidable rework and disagreement about what the engagement covers.

Keep management’s review separate from copy-editing. A polished paragraph can still be inaccurate. The accountable reviewer should confirm the facts, responsibilities, commitments and relevant changes, and understand the assertion management is making. Do not let the readiness consultant become the only person who understands the description.

Prepare people for the independent examination

Good preparation reduces confusion during an examination. Identify a coordinator for requests, but avoid making that person the bottleneck for every answer. Control owners should know what they do, where evidence is held and how to explain exceptions accurately. A rehearsal can reveal unclear processes without trying to coach a preferred answer.

Set up a request log with the item, responsible owner, due date, evidence link and status. Track clarifications separately from missing records. Some requests require a fuller population or explanation rather than a different screenshot. Agree the exchange channel with the examiner and keep information access proportionate.

Respond directly to the question asked. If the examiner requests a population of changes for a period, provide the relevant population and explain extraction parameters; do not send a handful of selected successful changes. Where a system limitation exists, describe it early so an appropriate way forward can be discussed.

Manage exceptions with the same discipline used for operational incidents. Establish the facts, determine the cause, consider the effect, assign corrective action and retain supporting records. An exception is not resolved by renaming a file or adding a policy sentence. Avoid promising a particular audit opinion or asking the consultant to overrule an independent conclusion.

Schedule a closing review with management. Confirm that factual corrections, open questions and responsibilities for follow-up are understood. After issuance, plan how authorised recipients will obtain the report and who will answer customer questions. Treat the report as controlled assurance material, not automatically as a public download.

Estimate cost and time using the real workload

A useful SOC 2 budget separates readiness consulting, independent examination, internal staff time, technical remediation, software and recurring operation. A single headline fee can hide most of the work. Ask suppliers to state assumptions, exclusions and what causes a change in scope. Compare proposals using the same service boundaries and expected deliverables.

Team size is only one driver. A small provider with multiple products, cloud accounts and outsourced development teams may have more complex evidence and access arrangements than a larger business with standardised operations. Locations, customer commitments, control maturity, system changes and supplier dependencies also affect effort.

Use a planning workshop to estimate internal time. Ask each function which activities it already performs and where evidence is missing. Identify work that requires budget approval or architecture change. Record dependencies such as a new identity platform, a contract amendment or access to client-controlled systems. These can dominate the schedule even when documentation is quick.

Separate readiness milestones from report issuance. A programme can complete its policy review while still waiting for a control to operate, an unresolved gap to be corrected or an examination period to finish. A dashboard should show these different stages clearly so leadership and sales do not mistake progress for an issued report.

Build a sustainable recurring budget. Include evidence review, employee changes, supplier reassessment, technical maintenance, learning and future examinations where needed. The operating model should survive the departure of the original project manager. A low initial fee is poor value if the organisation must rebuild the process before every customer review.

If you need a proposal, share the service, locations, approximate workforce, key systems, existing assurance work, customer request and target date. CyberVantage360 can use those facts to discuss a scoped readiness engagement. The independent CPA firm’s fees and reporting timetable should be visible separately so that the full commitment is understood.

Three practical examples of a proportionate programme

A growing SaaS provider

Imagine a 35-person software company that has strong engineering practices but informal approvals. Its immediate priority is to describe the production service and support access accurately, make change decisions traceable and assign ownership for user access. A project that begins with dozens of new policy documents may distract the engineers without fixing the actual evidence gaps.

A proportionate plan can use existing repository reviews and release records, improve the joiner and leaver workflow, establish a documented access review and connect incident decisions to the ticketing system. Management should check whether customer commitments match the recovery capabilities the team can demonstrate. Progress is measured through working controls and reliable records.

An established BPO

Imagine a BPO with several client teams, some using client-managed virtual desktops and others processing files within the BPO’s environment. Its risk is not captured by one generic network diagram. The first exercise should map service workflows, data handling and client-specific responsibilities. Supervisors, HR and operations need to be involved alongside IT.

The programme might focus on timely access removal across both environments, supervision of exceptions, secure handling of exported records and consistent approval of role changes. A central evidence process can help, but the control design must reflect each delivery model. The report scope must be clear about which services and locations are included.

A provider already working with ISO 27001

Imagine an organisation with an established ISMS and an enterprise customer requesting SOC 2. It should inventory reusable risk assessments, access controls, supplier reviews, audits and management records. That starting point may reduce duplicated effort, but the team still needs to address the particular service description, commitments and report-period requirements.

Our recommended approach is a mapping workshop: identify shared operating controls, identify evidence that fits both scopes and list differences that need separate treatment. Keep each assurance output distinct. A customer requesting a SOC 2 report should not be told that an ISO certificate automatically provides the same information.

These are hypothetical planning examples, not claims about named CyberVantage360 clients or guaranteed results. The purpose is to show how scope and operating conditions change the work. Your programme should be based on a review of your organisation’s actual systems and commitments.

What to do in the first month

Begin with four manageable workstreams rather than an organisation-wide request for “all compliance evidence”. First, clarify the assurance need and proposed system boundary. Second, identify existing controls and their owners. Third, demonstrate a few critical workflows using actual records. Fourth, agree a prioritised plan with the sponsor and the intended independent examiner.

In the first workshop, ask the commercial team to bring the exact customer requirement. Ask operations to explain the service from the user’s perspective. Ask technical owners to show major dependencies. Record unresolved questions rather than forcing an immediate answer. The output should be a scope decision list and a clear owner for each open point.

Next, select several important end-to-end processes to test internally. Joiner-to-access, leaver-to-removal, change-to-production and incident-to-closure are often useful examples. Look at ordinary cases and exceptions. Identify where the process depends on memory, undocumented judgement or a person who is unavailable.

Then prepare the initial roadmap. Separate actions that can start immediately from those needing management approval, supplier input or technical change. Put expected evidence next to each action so that completion is demonstrable. Agree a reporting cadence with the sponsor and an escalation threshold for blocked work.

End the month by reviewing whether the scope, resources and target dates remain credible. Adjust the plan openly if the initial assumptions were wrong. It is better to correct a timetable while the customer conversation is still developing than to promise a report date that the organisation cannot support.

A readiness discussion checklist for management

• We can explain the service and why the intended customer needs assurance.
• The proposed report type, categories and timing have been discussed with the intended recipient and independent examiner.
• Service boundaries, locations, shared systems and key dependencies are documented.
• Customer commitments are linked to accountable owners and operating practices.
• Control gaps distinguish design, operation and evidence problems.
• Remediation actions have owners, dates, evidence expectations and escalation routes.
• Evidence is being retained securely and can be interpreted by someone outside the delivery team.
• Supplier and customer responsibilities are explicit.
• The system description is based on verified facts and management review.
• Consulting, software and independent examination responsibilities are clear.
• Sales language describes the actual assurance outcome and scope accurately.
• The programme has an operating owner and budget beyond the first report.

Use these points to structure a management conversation, not as a substitute for the applicable criteria or the examiner’s work. A checklist cannot establish readiness without supporting evidence. Where an answer is uncertain, turn it into a specific action and bring the right operational owner into the discussion.

Common SOC 2 questions

Is SOC 2 a certification?

SOC 2 is an independent examination and report. Use “SOC 2 report”, “SOC 2 examination” or “SOC 2 readiness” according to the activity. A consultant’s assessment, platform score or completion badge is not the independent CPA report. Customer-facing statements should identify the relevant service, scope and period accurately.

Can a small business prepare for SOC 2?

Yes, size alone does not determine whether a readiness programme is workable. The key questions are scope, customer need, management commitment and the ability to operate controls consistently. Use proportionate processes, with clear review and accountability where a small team has overlapping responsibilities.

Does using a major cloud provider make our company SOC 2 ready?

No. Review what the provider covers and what your organisation still operates. Application configuration, employee access, changes, support practices and customer commitments may remain your responsibility. The readiness assessment should test those arrangements instead of relying on a provider’s reputation or assurance badge.

Do we have to buy a compliance platform?

A platform is a tool choice, not the starting point for defining your programme. First establish scope, responsibilities and evidence needs. Then evaluate whether automation improves your actual workflows, and whether the organisation can maintain integrations and review exceptions. Confirm examination arrangements independently.

Can the consultant guarantee a successful opinion?

No consultant should commit an independent CPA firm to a predetermined conclusion. Consulting can improve readiness, organise evidence and resolve gaps. The independent firm evaluates the evidence and reaches its own opinion. Keep this distinction clear in proposals, contracts and sales conversations.

What information is useful for an initial consultation?

Share a short service description, the customer request, relevant countries and locations, major systems, existing ISO or other assurance work and your intended date. You do not need to send sensitive customer records or credentials. A scoping conversation can identify what additional information is appropriate to exchange securely.

Turn your customer request into a practical readiness plan

CyberVantage360 supports organisations with SOC 2 scoping, readiness assessment, implementation planning, documentation, evidence organisation and preparation for the independent examination. The engagement should give your team a clear view of what needs to change, who owns the work and how progress will be demonstrated.

Start with the business problem you need to solve. If an enterprise customer has asked for a report, bring the requirement. If your team already has controls but struggles with evidence, show one representative workflow. If ISO 27001 work is underway, discuss which practices may be shared and which SOC 2-specific needs remain.

Training and automation can be included where they address a real operating need. Agree the scope of Sterling Academy learning and Effivity software support in the proposal rather than assuming that every package is identical. The independent CPA engagement remains separate and should have clear responsibilities, fees and reporting arrangements.

Explore SOC 2 readiness support or discuss your service, customer requirement and target date. The first useful outcome is a realistic scope and next step, supported by facts about your business.