What SOC 2 is, and why you need it

A SOC 2 report is an independent audit that verifies a service provider’s security controls are designed appropriately and operating effectively. Produced by an independent auditor rather than the provider itself, it gives customers objective evidence that the systems handling their data can be trusted. 

Australian regulated organisations need SOC 2 because regulators increasingly expect them to prove that the providers handling their data operate effective security controls.  

Superannuation funds, insurers, banks and other APRA-regulated entities continue to outsource more technology services to specialist providers. While those providers take on the day-to-day operational responsibility, accountability doesn’t transfer with it. Regulators still expect organisations to demonstrate that the providers managing critical systems and sensitive data have effective controls in place. 

That’s why SOC 2 Australia has become less about providers seeking another credential and more about customers demanding stronger evidence.  

Increasingly, procurement teams are asking for a SOC 2 Type II report as part of the tender process because it provides independently verified assurance that a provider’s controls have been tested and shown to operate effectively over time. 

Interactive sees this big shift firsthand. As a provider that holds a SOC 2 report and is audited alongside many of Australia’s regulated organisations, the conversation has changed quite noticeably.  

Customers increasingly expect independent evidence that security controls operate consistently and can withstand regulatory scrutiny. That’s the role of a SOC 2 report. 

The rest of this guide explains what SOC 2 covers, why Type II provides much stronger assurance than Type I, how it compares with ISO 27001, how it supports APRA CPS 234, and what Australian organisations should look for when evaluating a provider’s audit evidence. 

 

Why Australian organisations are demanding SOC 2 from their suppliers

Two years ago, SOC 2 compliance Australia was something organisations might note during procurement. Today, it’s increasingly written into tenders and supplier evaluation criteria. 

The shift reflects a broader change in how regulated organisations manage third-party risk. In fact, as more technology services move to specialist providers, organisations are becoming increasingly dependent on external partners to operate critical systems and protect sensitive data.  

At the same time, APRA’s expectations around supplier governance and operational resilience have continued to mature. The question has moved from “Does your provider say they do this?” to “Can you show they actually do?” 

Certainly, for many organisations, that’s a practical challenge. A superannuation fund, insurer or bank may rely on dozens (or even hundreds) of technology providers. Auditing every supplier in depth simply isn’t very realistic.  

SOC 2 certification Australia gives providers a recognised way to demonstrate, through an independent audit, that their controls are appropriately designed and operating effectively. Rather than recreating that assurance themselves, customers can review independently verified evidence. 

In Interactive’s work with Australian superannuation funds and other regulated organisations, the providers that make their customers’ lives easiest are the ones that arrive with the evidence already gathered, rather than leaving procurement, risk and audit teams to chase documentation supplier by supplier.  

Instead of responding to repeated requests for policies, control documentation and testing records, they can provide a SOC 2 report that demonstrates how their security controls have been independently assessed over time. 

SOC 2 now plays an important role in helping regulated organisations understand, govern and demonstrate the security of their supply chains. 

For more on APRA’s expectations around third-party information security, see our guide to CPS 234. 

 

How SOC 2 works: the report, the auditor, and what it attests

Now for the detail behind the definition, which will help you determine what’s what.  

SOC 2 (System and Organisation Controls 2) was developed by the American Institute of Certified Public Accountants (AICPA) as a framework for assessing how service providers manage security and operational controls. A SOC 2 report is produced by an independent auditor, typically a licensed CPA firm or equivalent, not by the provider itself. That independence is what gives the report its value as evidence. 

Importantly, SOC 2 is an independent assurance report, not a pass-or-fail certification. Rather than issuing a simple certificate, the auditor evaluates the provider’s controls against the agreed scope and produces a detailed report describing what was assessed, how the controls performed and any observations arising from the audit. Because the report contains sensitive operational information, it’s typically shared with customers under a non-disclosure agreement (NDA). 

And that distinction matters. A certificate confirms that an organisation has met a particular standard. A SOC 2 report provides the evidence a customer can review when assessing whether a provider’s controls are appropriate for the services it delivers. 

Although SOC 2 originated in the United States, it has become an increasingly common supplier requirement for Australian organisations, particularly across technology, cloud and regulated industries. It isn’t an Australian or APRA framework, but it’s widely recognised as an independent way for providers to demonstrate the effectiveness of their controls to customers. 

5 Trust Services Criteria explained

Every SOC 2 report is built around the Trust Services Criteria, the framework used by the auditor to assess whether a provider’s controls are appropriate for the services it delivers. 

Only one of the criteria is mandatory: Security. The remaining four are included where they’re relevant to the scope of the services being assessed. That’s why it’s important to look beyond whether a provider has a SOC 2 report and ask exactly which criteria it covers. 

The five Trust Services Criteria are: 

• Security (mandatory): Security assesses whether systems and data are protected against unauthorised access through controls designed to safeguard information and reduce security risk. 
• Availability: Availability assesses whether systems are available for operation and use as committed or agreed, helping customers understand how a provider supports reliability and resilience. 
• Processing Integrity: Processing Integrity assesses whether systems process data completely, accurately, validly and in a timely manner, giving confidence that services perform as intended. 
• Confidentiality: Confidentiality assesses how confidential information is protected throughout its lifecycle, including how it is stored, accessed and shared. 
• Privacy: Privacy assesses how personal information is collected, used, retained, disclosed and disposed of in accordance with the organisation’s privacy commitments. 

For Australian organisations, the practical question isn’t simply “Does your provider have a SOC 2 report?” It’s “Which Trust Services Criteria are included in the scope of that report?” A report covering only Security provides a different level of assurance from one that also includes Availability, Confidentiality or Processing Integrity, particularly where a provider is responsible for business-critical or highly sensitive workloads. 

Understanding that scope helps procurement, risk and audit teams evaluate whether a provider’s assurance aligns with the services they deliver and the level of risk they are managing. 

SOC 2 Type I vs Type II: assurance versus evidence

Notably, the distinction that matters most for Australian regulated organisations is the difference between SOC 2 Type I and SOC 2 Type II. What’s more, it’s also the distinction buyers most commonly overlook. 

SOC 2 Type I: Are the controls designed appropriately?

A SOC 2 Type I report assesses whether a provider’s controls are suitably designed at a single point in time. It answers an important question: Has the organisation designed appropriate controls for the services it delivers? 

SOC 2 Type II: Do the controls actually work?

A SOC 2 Type II report goes a step further. Rather than looking at a single point in time, it tests whether those controls operated effectively over a period, typically six to twelve months, and sometimes as short as three months. 

That difference matters. A Type I provides assurance that the controls exist. A Type II provides evidence that they worked. 

For Australian regulated organisations, that’s exactly the change regulators have been making.  

APRA’s focus has moved beyond whether a control has been documented or promised. Increasingly, organisations are expected to show that controls have been tested, that recovery processes have been exercised and that critical operational capabilities have been shown to work in practice. A SOC 2 Type II report aligns with that evidence-based approach because it demonstrates how controls performed over time, not simply how they were designed. 

That’s why procurement, risk and audit teams should ask specifically for a SOC 2 Type II report, rather than simply requesting “a SOC 2 report.” A Type II report provides the independently audited evidence organisations can use to assess an outsourced provider and support their own governance, supplier assurance and regulatory obligations. 

SOC 1 vs SOC 2: What’s the difference?

It’s also worth noting that SOC 1 vs SOC 2 addresses two different areas of assurance. SOC 1 focuses on controls relevant to financial reporting, while SOC 2 evaluates security, availability, processing integrity, confidentiality and privacy controls for technology and service providers. Organisations assessing technology suppliers will typically be looking for SOC 2, particularly Type II, because it provides assurance over the operational controls that matter most. 

 

SOC 2 vs ISO 27001: overlap, differences, and when each applies

SOC 2 vs ISO 27001 is one of the most common questions Australian organisations ask because many already hold ISO 27001. As customers, particularly those in regulated industries, increasingly request SOC 2, organisations want to understand how the two frameworks differ and whether they need both. While they overlap in many areas, they’re not interchangeable. They answer different questions and provide different types of assurance.  

ISO 27001: A certified security management system

ISO 27001 is an internationally recognised standard for an Information Security Management System (ISMS). It certifies that an organisation has established a structured framework for identifying, managing and continually improving information security risks. 

The outcome is a certificate, demonstrating that the organisation’s ISMS has been independently assessed against the requirements of the standard. 

SOC 2: An independent attestation report

SOC 2 takes a different approach. Rather than certifying an information security management system, it provides an attestation report prepared by an independent auditor describing how a provider’s controls are designed and, in the case of Type II, whether those controls operated effectively over time. 

The outcome is a detailed report that customers can review when evaluating a provider, rather than a certificate displayed on a website. 

Which one should you ask for?

In practice, many organisations hold both because they serve different audiences and different purposes. 

ISO 27001 is widely recognised across Australia and Europe and demonstrates a mature approach to information security management. SOC 2, particularly SOC 2 Type II, is increasingly expected by North American organisations, technology buyers and Australian regulated industries seeking independent evidence of how operational controls perform in practice. 

If you’re deciding what to request from a provider, the answer depends on what you’re trying to assess. If you want evidence that an organisation operates a certified information security management system, ISO 27001 is appropriate. If you want independently verified evidence of how specific operational controls perform over time, SOC 2 Type II provides much greater visibility. 

Increasingly, regulated organisations aren’t choosing between the two. They’re looking for providers that can demonstrate both strong security governance through ISO 27001 and independently tested operational assurance through SOC 2 Type II. 

Because Interactive has implemented and maintains both ISO 27001 and SOC 2, it understands the role each framework plays in regulated environments. They’re complementary rather than competing. ISO 27001 demonstrates a mature information security management system, while SOC 2 provides independently audited evidence that operational controls work effectively in practice.  

What a SOC 2 audit covers and how it works 

Essentially, a SOC 2 audit is conducted by an independent auditor (typically a licensed CPA firm or equivalent) rather than by the organisation itself. The auditor assesses the provider’s controls against the agreed Trust Services Criteria and, for a SOC 2 Type II report, tests evidence that those controls operated effectively throughout the review period. The outcome is a detailed report, not a pass-or-fail certificate. 

If you’re obtaining SOC 2

Meanwhile, for organisations pursuing SOC 2 certification, the process usually begins with a readiness assessment. This helps identify control gaps, confirm which Trust Services Criteria will be included and prepare the organisation before the formal audit begins. 

For a Type II report, organisations then enter an observation period (commonly six to twelve months, and sometimes as short as three months) during which the auditor evaluates how controls perform in practice. The overall timeline, complexity and cost of the audit will vary depending on the scope, the size of the organisation and the maturity of its security and operational controls. 

If you’re reviewing a provider’s SOC 2 report

For procurement, risk and audit teams, the value lies in understanding what the report actually says. 

When reviewing a SOC 2 report, ask four questions: 

• Which Trust Services Criteria are included in the scope? 
• Is the report Type I or Type II? 
• What period does the report cover? 
• Did the auditor identify any exceptions, and how were they addressed? 

Remember, the presence of exceptions doesn’t automatically indicate a poor outcome. In many cases, the provider’s response, remediation and ongoing management of those findings provide greater insight into its operational maturity than the exception itself. 

Ultimately, a SOC 2 audit is designed to provide confidence through independent evidence. Whether you’re obtaining a report or reviewing one from a supplier, the objective is the same: understanding how effectively security and operational controls perform in the real world. 

 

Why regulated entities should ask their provider for SOC 2 Type II

For APRA-regulated organisations, a SOC 2 Type II report provides independently audited evidence that an outsourced provider’s controls are operating effectively. 

When organisations outsource critical technology services, responsibility doesn’t disappear. They remain accountable for understanding how those providers manage security, availability and operational risk. A SOC 2 report, particularly Type II, helps support that responsibility by providing independently tested evidence that can be reviewed by procurement, risk, compliance and audit teams. 

That’s why the conversation during procurement has changed. 

Rather than asking, “Are you secure?”, regulated organisations should be asking: 

• Will you provide a SOC 2 Type II report? 
• Which Trust Services Criteria are included in the report? 
• What review period does the report cover? 
• Were any exceptions identified, and how were they addressed? 

Essentially, those questions give buyers a far clearer understanding of how a provider manages operational risk than a simple security questionnaire or contractual assurance ever could. 

A SOC 2 Type II report shouldn’t be viewed as a substitute for sound governance or well-run systems. Instead, it provides independently audited evidence that helps organisations assess providers consistently and reduce the effort required to evidence third-party controls as part of their broader governance and regulatory obligations. 

For regulated organisations managing complex supplier ecosystems, that’s where the real value lies. A provider that can produce independently verified evidence from the outset reduces the amount of assurance work customers need to perform themselves and helps simplify supplier reviews without compromising confidence. 

 

How SOC 2 supports APRA CPS 234 compliance

SOC 2 is not an APRA requirement, and holding a SOC 2 Type II report doesn’t make an organisation CPS 234 compliant. The two frameworks serve different purposes. CPS 234 is a prudential standard that places obligations on APRA-regulated entities, while SOC 2 is an independently audited attestation report provided by a service provider. 

Where they align is in the management of third-party risk. 

CPS 234 requires regulated organisations to maintain the information security capability of third-party providers and to demonstrate that controls protecting information assets are appropriate, tested and effective. Assessing those controls across a large supplier ecosystem can be both time-consuming and complex. 

This is where SOC 2 Type II provides real value. A Type II report gives customers independently audited evidence that a provider’s security and operational controls have been tested over time and are operating effectively. While it doesn’t replace the organisation’s own due diligence or governance responsibilities, it provides a strong evidentiary foundation when assessing outsourced services and supporting supplier assurance activities. 

In practice, that’s why many regulated organisations request SOC 2 Type II reports from critical technology providers. Not because CPS 234 requires them, but because independently verified evidence makes it easier to understand, assess and demonstrate the effectiveness of third-party controls. 

For a deeper explanation of APRA’s information security requirements, including third-party governance, control testing and functional independence, read Interactive’s CPS 234 Hub Guide.