SOC audit readiness: what organisations consistently get wrong in the year before the report

SOC Audit Readiness  |  6 min read  |  Raayzel Business Consulting

A SOC audit report is one of the most consequential documents a service organisation can produce. For technology companies, managed service providers, payroll processors, data centres, and any business that handles client data or delivers services that affect client financial reporting, a clean SOC 1 or SOC 2 report is increasingly a commercial prerequisite. Clients require it. Procurement processes demand it. Enterprise buyers will not proceed without it.

What is less well understood is that the quality of the SOC report is determined almost entirely by what happens in the twelve months before the auditor arrives, not by what happens during the audit itself. Organisations that treat SOC readiness as an audit preparation exercise consistently find that the audit surfaces gaps they did not know existed. Organisations that treat it as a continuous controls discipline produce reports that reflect genuine operational maturity.

This article examines the most common readiness failures and what organisations need to address if they want a SOC report that holds up under client scrutiny.

Understanding what the report is actually assessing

The first failure mode is a misunderstanding of what a SOC report certifies. A SOC 1 report (SSAE 18 / ISAE 3402) addresses controls relevant to client financial reporting. A SOC 2 report addresses controls across the Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. In both cases, the report assesses whether the controls described in management’s system description were designed appropriately and, for a Type II report, whether they operated effectively over the reporting period.

The critical word is operated. A Type II report is not a point-in-time assessment of whether controls exist. It is an evidence-based conclusion about whether those controls functioned consistently across a defined period, typically six or twelve months. Organisations that design controls shortly before the audit window opens, or that operate controls inconsistently and document them retrospectively, will not produce a Type II report that holds up.

Many organisations request a Type I report initially, which assesses design only. This is a legitimate starting point, but clients and enterprise buyers increasingly require Type II. The transition from Type I to Type II requires genuine operational discipline, not merely documentation improvement.

The system description problem

The management system description is the foundation of the SOC report. It defines the boundaries of the system being assessed, the controls in place, and the complementary user entity controls that client organisations must implement for the overall control environment to function. Auditors test against it. Clients read it. If it is inaccurate, incomplete, or out of date, the entire report is compromised.

Organisations consistently underinvest in the quality and accuracy of their system descriptions. Common problems include:

• Controls documented in the system description that do not reflect how processes actually operate, because the description was written once and not maintained as the organisation evolved.
• Boundaries that are either too narrow, excluding systems and processes that are genuinely relevant, or too broad, including scope that cannot be adequately evidenced.
• Complementary user entity controls that are technically accurate but provide insufficient guidance for clients to understand what they are actually required to do.
• Descriptions of control ownership and frequency that do not match the evidence available when testing begins.

A system description review conducted six to nine months before the audit, assessed against the actual operating environment rather than the previous year’s report, is the single most effective readiness investment an organisation can make.

Evidence collection is where readiness is won or lost

The most common cause of audit findings in SOC engagements is not poor control design. It is the absence of contemporaneous evidence that controls operated as described. Controls that genuinely function but are not consistently documented produce the same audit outcome as controls that do not function at all: an exception.

Evidence collection failures fall into three categories. First, evidence that was never generated, because the control was performed informally without producing a record. Second, evidence that was generated but not retained, because no one identified it as control evidence at the time. Third, evidence that exists but is inconsistent with the control description, because the process evolved but the description did not.

Addressing this requires a systematic evidence framework: a defined list of controls, the evidence that demonstrates each control operated, who is responsible for generating and retaining that evidence, and the frequency at which it must be produced. This framework needs to be operational from the first day of the audit window, not assembled when the auditor requests the population.

Access management: the highest frequency finding

Across SOC 1 and SOC 2 engagements, access management controls generate more exceptions than any other control category. The pattern is consistent: user access reviews are performed at the required frequency but exceptions identified during the review are not remediated promptly. Privileged access is not reviewed with sufficient rigour. Terminated user access is not removed within the timeframe specified in the control description. New joiners receive access that exceeds the requirements of their role.

These are not complex control failures. They are operational discipline failures. The controls exist. The processes exist. The exceptions occur because access management sits at the intersection of IT, HR, and line management, and no single function takes unambiguous ownership of the end-to-end process.

Organisations that produce clean SOC reports on access management have resolved this ownership ambiguity before the audit window opens. They have a defined process, a defined owner, defined remediation timescales, and a monitoring mechanism that identifies exceptions before the auditor does.

Change management and the ITGC connection

IT General Controls, and specifically change management, represent the second highest frequency exception area in SOC engagements. The requirement is that changes to in-scope systems are authorised, tested, and approved before being moved to production. The reality in many organisations is that emergency changes bypass the standard process, that testing evidence is incomplete, or that approval records do not exist for changes that were genuinely authorised but informally.

The connection to ITGCs is direct. A SOC 1 report for an organisation whose system processes client financial data is, in part, an assessment of whether the controls over that system are themselves adequately controlled. Change management weaknesses undermine the credibility of every other control in the system description, because they raise the question of whether the system being assessed today is the same system that was in place at the start of the audit period.

Organisations preparing for SOC audits should assess their change management process against the specific evidence requirements of the audit before the window opens, not after the first sample request reveals gaps.

Vendor and subservice organisation management

Most service organisations rely on third-party vendors and subservice organisations that are themselves relevant to the controls being assessed. Cloud infrastructure providers, identity management platforms, monitoring tools, and data processors all sit within or adjacent to the system boundary.

SOC reports must address subservice organisations in one of two ways: the carve-out method, which excludes the subservice organisation from the report scope and requires clients to obtain their own assurance, or the inclusive method, which includes their controls within the assessment. In practice, most reports use the carve-out method. This places an obligation on the service organisation to obtain and review the SOC reports of its subservice organisations and to assess whether those reports cover the period and the controls relevant to its own system.

Organisations that do not have a structured process for obtaining, reviewing, and responding to subservice organisation SOC reports consistently find this becomes a qualification point in their own report.

Building toward a clean report

SOC audit readiness is not a project that begins when the engagement letter is signed. It is a continuous controls discipline that, when operating correctly, makes the audit a confirmation of what the organisation already knows about its control environment rather than a discovery process.

The organisations that produce consistently clean SOC reports are those that treat the audit window as the accountability mechanism for a controls programme that operates year-round. They maintain their system description actively, generate and retain evidence as a matter of operational routine, resolve access and change management exceptions promptly, and review subservice organisation assurance as a standard governance activity.

Raayzel works with organisations preparing for their first SOC engagement and with those seeking to improve the quality and defensibility of their existing reports. Engagements cover system description review, controls gap assessment, evidence framework design, and audit support through the fieldwork period. The work is advisory and execution-oriented, calibrated to the specific audit type, scope, and timeline of each organisation.

Stay ahead of the audit readiness and controls agenda.

Sign up for free insights and resources from Raayzel Business Consulting: https://lp.constantcontactpages.com/sl/sBV4psC/insights