How to set up a successful SOC Assurance Reporting Program

Now the SOC Assurance Reporting framework has been explained, and the types of SOC Assurance Reports understood, it’s time to look at what the Service Organisation and their clients need to ensure the success of their SOC Assurance Reporting program, to get the most out of the assurance process and the report(s).

Misconceptions and trends of SOC Assurance reports

One of the misconceptions about SOC 1, 2, and 3 is that only a member of the American Institute of CPAs (AICPA) can issue these assurance reports. This is factually incorrect as any qualified CPA or CA can sign the SOC assurance report however as these typically deal with complex outsourced technology risks and controls, Technology Risk & Assurance specialists (subject matter experts) play a critical role in terms of completing the fieldwork and ensuring appropriate quality assurance measures are undertaken.

From a quality and risk perspective, SOC reports involving significant technology risks and controls should ideally involve a CPA or CA with deep technology risk and controls skills and experiences.

The confusion arises as the SOC 2 ‘Trust Services’ Criteria of Security, Privacy, Processing Integrity, Availability, and Confidentiality were developed by the Assurance Services Executive Committee (ASEC), which forms part of the AICPA (US based). These Trust Services principles have since been adopted globally and increasingly require IT Assurance specialists to complete the work as technologies evolve. The need for these skills will only increase as more traditional in-house operations are outsourced, and demand for different types of assurance grows.

Interestingly, the US is moving away from ISO 27001 certification and towards SOC 2 (ISAE 3000 or the Australian equivalent ASAE 3402 or ASAE 3150, depending on use) assurance reports on controls. Australia is heading in the same direction with the value of ISO 27001 certification coming into question when compared with the wider SOC 1 and SOC 2 independent assurance reporting regime, which can effectively go beyond the ISO 27001 certification process. ISO 27001 certifiers are also hard to find and focus more on the technical nature of the areas covered by the certification (not on their continued operation). It can also be argued that, depending on the composition of the SOC team, SOC work has more of an integrated business, technology, risk, and control focus. An initial comparison of ISO 27001 and SOC 2 (Trust Services Criteria) indicated that a SOC 2 could cover up to 95% of the same coverage as the ISO 27001 and with the newly introduced concept of SOC 2+ this now covers all ISO 27001 requirements (plus many more). The detailed testing regime undertaken for SOC 2 Type II assurance (refer below for Type II) provides more comfort as the testing can assure for a 12-month period.

Insights: The SOC Assurance Program

The difference between ISO 27001 and SOC reports

After reading the above, you may still be a little confused about which SOC report to use, especially with so many consultants trying to persuade you to be ISO 27001 Certified on the basis that this ‘replaces the need for a SOC report’ – which is obviously incorrect.

ISO 27001 is a standard that covers the design and implementation of an information security management system (ISMS). While SOC 2 focuses on the design, implementation, and operational effectiveness of controls in place to manage the risk areas contained in the (AICPA-defined) Trust Services Criteria. They can be complementary as ISO 27001 ensures the ISMS exists and SOC 2 ensures that key IT risks based on the ISO 27001 framework (and others) are adequately controlled throughout reliance.

Today’s SOC reports are undertaken by teams that comprise accounting, risk and technology specialists who tend to look at the bigger picture rather than with a technology and/or IT infrastructure lens. This does not mean that ISO 27001 certifications are redundant, it’s rather a matter of horses for courses. Business outsourcing risks require a more comprehensive business, risk and technology lens, so ISO 27001 certifications seem to be gaining less traction and are being progressively replaced by ISO 27001 self-audits and SOC Assurance Reports.

Build the SOC Assurance Program

Building the SOC program for a first-time adopter should start with undertaking some type of assessment or gap analysis to determine the overall readiness of the organisation to undertake the SOC Assurance Reporting process.

As the controls are designed, implemented, remediated, and mature there will be a move to obtaining assurance as outlined in the below 3-step sequence.

Step 1 - Readiness Assessment

A Readiness Assessment is undertaken to ascertain whether the risks presented in the organisations Internal Control Framework (COSO/COBIT for SOC 1 and Trust Services Criteria for SOC 2) are adequate and in line with the scope of the area(s) obtaining assurance. The readiness assessment should be tailored to the specific area obtaining assurance and the environment in which it operates (often both manual and IT-dependent or automated controls). This report is used to structure the next step being the SOC (1 or 2) Type I Assurance Report.

Step 2 - SOC 1 or 2 Type I Assurance Report

A SOC (1 or 2) Type I SOC Assurance Report is obtained, which is a ‘point in time’ assurance report. Once the organisation is confident that the risks and controls within its SOC Assurance Program are designed effectively and in operation, the next logical step is to obtain assurance at a specified date e.g. 30 June 20XX. Basically, for one day in the year, the organisation can demonstrate that it had controls designed effectively and implemented against the risks identified within its Internal Control Framework. It cannot assure that these controls were operationally effective as only one date is considered.

Often remediation activities are still required because controls may still be immature and there may be a need for these to be further embedded into the organisations ‘business as usual’ operations. There may also be a need for further staff training on controls.

Step 3 - SOC 1 or 2 Type II Assurance Report

A SOC (1 or 2) Type II SOC Assurance Report provides assurance over a ‘period of time’. Once the organisation has proved that the required controls are in operation and are being maintained and monitored with evidence or artefacts available to support their existence and ongoing operation, then the organisation will be able to provide an Assurance Report over a specified ‘period of time’. These periods typically cover the first 3 or 6 months in the first year of operation and then on an annual basis after that.

Our recommendation on these assurance engagements, where the organisation requires assurance over a period, is to proactively undertake progressive update discussion/status updates to ensure the controls are in operation. There is no point getting to the intended reliance date (e.g. 1 July 2022 to 30 June 2023) to find that some controls were only in operation on an ad hoc or ‘as remembered’ basis. This progressive status update process increases the chances of an ‘Unqualified Opinion’ rather than a ‘Qualified Opinion’ which can then raise concerns or create doubt over the integrity of the organisation’s internal controls.

Independent SOC Assurance

It is important to note that as an assurance provider, I cannot design or implement controls for which I am providing assurance as this raises independence issues. The issue is – I would not be perceived as being independent if the control I designed and implemented failed or didn’t operate as intended.

However, I can look at the risks and provide an outline of how the control will need to operate to manage the risk. Still, the overall design, build and implementation are the responsibility of the organisation or any specialist consultants they may engage.

Some key lessons learned: SOC reports in practice

Over the last few years, several situations have highlighted to me that many organisations do not fully understand the requirements surrounding Systems and Organisation Controls Reports (ASAE 3402 or ASAE 3150) and/or any of the risk, control, testing or evidence requirements. As such, I have listed down some of the key lessons that we have learned and that we now do not take for granted when we are undertaking SOC Assurance work.

  • If you are preparing a SOC Assurance Report for a customer of a Service Organisation then it is always best to obtain their input and focus areas (based on their risk profile and the controls outsourced for Service Organisations to manage) as this avoids uncomfortable discussions later on.
  • Organisations often do not drill down into the actual ‘risks’ relevant to the areas subject to a SOC Assurance Report as they often jump straight to the COSO Internal Control Framework and the static or generic controls listed. Technology controls do not typically follow the COSO framework, which is why the Trust Services Criteria were developed by the AICPA as a form of universal Internal Control Framework for IT environments. These are continually being updated.
  • Undertaking a walkthrough of the internal controls with management/control owners is an important step to ensure that controls exist within their business and IT processes. Many organisations (usually IT staff) struggle with what a control is versus a process.
  • Evidence collection should be undertaken at regular intervals throughout reliance to maximise the likelihood of achieving an ‘unqualified’ report. I often schedule periodic check-ins that can be used to collect evidence progressively throughout the year rather than waiting for the period end date.
  • In line with the above, a good approach is to check-in (be allowed to check-in) at regular intervals to ensure the controls framework is still in operation and to adjust any legacy controls testing that may have been replaced or superseded.
  • It is always better to monitor controls regularly because during the initial stages of the control framework being implemented, these controls and the individual staff members understanding of the importance of the controls and evidence retention requirements are often not mature. Staff often mistakenly believe they can go back later and obtain the required evidence without considering the nature and timing of the controls.
  • Organisations should build control activities into their existing work calendars so that the control operation and evidence retention operation become business as usual.
  • Some clients think that only an AICPA can sign a SOC 2 IT Assurance Report because the AICPA developed the Trust Services Criteria. In Australia, a CPA or CA can sign the SOC Assurance Report under the Australian Auditing Standards (ASAE 3402 or ASAE 3150). The most critical aspect of the entire process is ensuring the work is completed and quality assured by the appropriate subject matter experts (Technology Risk & Control Specialists). For example, you don’t get a plumber to sign-off on an electrician’s work, so you don’t get a non-technology person to sign-off on technology risks and controls to work.
  • First time SOC reports may result in a ‘qualified opinion’ and this is to be expected as these exercises are often designed to ensure the maturity of the organisation’s SOC Assurance Framework. After the second assurance report, a qualified opinion would warrant some degree of concern for both the organisation and the auditor.

How to get the best out of your SOC Assurance program

As much as possible establish a ‘Controls Library’ that references the different compliance and assurance frameworks that the organisation needs to report against.

There should be a specific focus on reducing the significant overheads incurred from multiple cross-over compliance and assurance testing programs by consolidating key risk and controls testing and reporting processes. Leverage SOC assurance reports for services you may have outsourced to Service Organisations.

An example of this includes APRA, which has a number of regulatory standards that need to be followed such as CPS 231 (Outsourcing), CPS 232 (Business Continuity Management), CPS 234 (Information Security), CPS 235 (Managing Data Risk) and from 2025 CPS 230 (Operational Risk Management) etc. Suppose the key areas of coverage for Service Organisations are included in an independent SOC Assurance reporting process (with annual assurance reporting). In that case, you will find that regulators should be ‘quite reasonable’ in obtaining comfort from these consolidated SOC reports, instead of requiring separate independent assurance reports.

This means that the SOC Assurance report will need to be undertaken annually or they lose relevance – this could be very powerful from a governance perspective. Imagine the value and benefits derived if all relevant core components of the specific APRA standards were included in a Controls Library and can be mapped into a single independent SOC program.

How can we help?

Our professionals provide a full range of SOC 1, 2, 3, ISO Compliance and other third-party assurance services by applicable professional standards. Our technology risk and control assurance services work closely with our broader Risk team to provide:

  • System and Organisation Controls reporting (e.g. SOC 1 & SOC 2 (ASAE 3402/ ASAE 3150)
  • APRA Standards - IT Assurance (CPS 220, 231, 232, 233, 234, 235 & the new CPS 230)
  • ISO Compliance (27001 Readiness & Maintenance Audits (Pre-Certification))
  • IT Governance
  • Operational Due Diligence (ODD), including Technology Due Diligence
  • Internal IT Controls over Financial Reporting (using COSO & COBIT Frameworks)
  • IT Risk & Assurance Control Library Mapping and Control Self-Assessments
  • Data Privacy Impact Assessments
  • Consumer Data Right (ACCC) Attestation
  • Vendor / Third Party Assurance
  • Governance, Risk & Compliance Framework Design and Implementation

For more information and to speak to one of our specialists, contact your local BDO adviser.