This guide is general information, not legal or audit advice. Talk to your CPA firm and your own advisers about your situation.
What SOC 2 is and who asks for it
SOC 2 is a reporting framework from the AICPA, the professional body for accountants in the United States. A CPA firm examines a service organisation, such as a SaaS company, and reports on its controls against the AICPA’s Trust Services Criteria. The result is a report, not a certificate. It contains a description of your system, a written assertion from your management, the auditor’s opinion and, for a Type 2 report, the tests the auditor performed and what they found.
The people who ask for it are usually your customers’ security, risk and procurement teams. A SOC 2 report gives them an independent view of your controls that they can read instead of assessing you themselves. Reports are normally shared with customers under a non-disclosure agreement rather than published.
SOC 2 is voluntary. No Australian law requires it; the need comes from what customers write into their contracts and supplier assessments. TrustProof’s SOC 2 readiness page explains what our product covers for it.
Type 1 and Type 2 reports
There are two kinds of SOC 2 report.
- Type 1 looks at a single point in time. The CPA firm reports on whether your system description is fair and whether your controls are suitably designed, as at a specific date.
- Type 2 covers a stretch of time, called the observation or review period. As well as the design, the CPA firm tests whether the controls actually operated throughout that period, usually by sampling evidence from across it.
Many customers ask specifically for Type 2, because it shows controls working over time rather than on one day. A Type 1 can be a sensible first step if a customer will accept it while your Type 2 period runs. The length of the observation period is agreed with your CPA firm, so ask your customers what they will accept before you settle on a plan.
Either way, the report is issued by the CPA firm after its own examination. TrustProof does not issue SOC 2 reports and does not form, issue or decide an audit opinion or certification decision.
The Trust Services Criteria, at a high level
The criteria are grouped into five categories. They are summarised here in our own words; the AICPA publishes the criteria themselves.
- Security: protecting systems and data from unauthorised access and misuse. Security is part of every SOC 2 report, and its criteria are often called the common criteria.
- Availability: keeping the system up and usable to the level you have committed to.
- Processing integrity: making sure the system processes data correctly and completely, as intended.
- Confidentiality: protecting information that you have agreed to keep confidential.
- Privacy: handling personal information in line with your privacy commitments.
Security is always in scope. The other four are optional: you choose them with your CPA firm, based on what you promise customers. A product with uptime commitments often adds Availability, and one holding customers’ confidential data often adds Confidentiality. Each extra category brings more criteria to evidence.
Why Australian SaaS teams get asked for SOC 2
SOC 2 is an American framework, but Australian SaaS companies meet it regularly. It usually arrives with a bigger deal:
- Enterprise procurement. Larger organisations run supplier security assessments before they sign, and a current SOC 2 report is one of the documents they commonly request.
- US customers and partners. SOC 2 is the assurance report many US buyers expect from a software supplier, so selling into the US is a common trigger.
- Security questionnaires. Long questionnaires about access control, encryption, logging, backups and incident response are a standard part of procurement. A SOC 2 report can answer many of those questions at once, and preparing for one gives you consistent, evidenced answers.
When a prospect asks for “SOC 2”, it is worth asking which report type, which categories and by when, and whether they would accept something else, such as an ISO/IEC 27001 certificate, in the meantime.
How ISO/IEC 27001 and APRA CPS 234 relate
ISO/IEC 27001 is the international standard for an information security management system. Unlike SOC 2, it leads to certification: a certification body audits you and, if satisfied, issues a certificate. Buyers usually expect an accredited body; in Australia that is usually JAS-ANZ. ISO/IEC 27001 is widely recognised by buyers in Australia, Europe and Asia, while US buyers more often ask for SOC 2.
The two cover many of the same areas, including access control, encryption, logging, change management, supplier management and incident response. The policies, records and AWS evidence you build for one can usually be reused for the other, so teams often start with whichever their customers ask for first. See ISO/IEC 27001 readiness.
APRA CPS 234 is a prudential standard, not a report. It applies to APRA-regulated entities such as banks, insurers and superannuation trustees, and requires them to manage information security, including where third parties manage their information assets. If you sell to one of these organisations, expect their supplier assessment; a SOC 2 report or an ISO/IEC 27001 certificate is often part of the evidence suppliers provide. Neither one shows, by itself, that your customer meets CPS 234; that obligation stays with them. See APRA CPS 234 readiness.
A practical path on AWS
Every organisation’s route is different, but most SaaS teams on AWS work through the same steps.
Agree the scope
Decide which product, AWS accounts, people and processes are in scope, which categories beyond Security you need, and whether you are aiming for Type 1 or Type 2. Your customers’ requests settle most of this.
Run a read-only scan
Connect your AWS accounts through a read-only IAM role and see where the configuration stands today: root and IAM access, S3, encryption, network exposure and logging. TrustProof’s free AWS security scan does this without being able to change anything.
Fix the gaps, with approval
Work through the findings by risk. Changes to production should go through your normal change process, with an engineer approving each one, because the auditor will later ask how changes are controlled.
Write and approve your policies
SOC 2 expects documented policies and procedures, for example information security, access control, change management, incident response, supplier management and business continuity, approved by management and known to staff. Cloud configuration is only part of the picture: onboarding and offboarding, access reviews and security awareness training matter just as much.
Collect evidence over the observation period
For Type 2, the CPA firm samples evidence from across the period: configuration snapshots, access reviews, change records, incident tickets and training records. Evidence collected as you go, with its date, is easier to review than evidence pulled together at the end.
Choose a CPA firm
SOC 2 reports are issued by licensed CPA firms, and a number of firms serve Australian clients, directly or through US-licensed affiliates. Ask about their experience with SaaS on AWS, their timing, which report type they suggest for your customers, and how they handle independence if they also offer readiness help.
The audit
The CPA firm confirms the scope and period, requests evidence, tests your controls and issues the report with its opinion. Exceptions found in testing are described in the report, so fix known gaps and keep evidence current before the period starts.
Common AWS gaps to check
These are the gaps TrustProof’s read-only SOC 2 checks look for. They map to four selected SOC 2 criteria (CC6.1, CC6.6, CC6.7 and CC7.2). They are not the whole of SOC 2: most criteria rely on your policies, procedures and records rather than AWS settings.
Root user without MFA, or with access keys
The root user can do anything in the account. Turn on multi-factor authentication for it and remove any root access keys, then keep root for the few tasks that need it.
IAM users without MFA, a weak password policy or old access keys
People who sign in to the console should use MFA, the account password policy should match your access control policy, and long-lived access keys should be rotated or replaced with roles.
S3 buckets that are public, unencrypted or reachable over plain HTTP
Check that buckets are not publicly accessible unless they are meant to be, that default encryption is on, and that bucket policies refuse requests made without HTTPS.
Databases and disks that are public or unencrypted
RDS databases should not be publicly accessible. RDS storage, EBS volumes and snapshots should be encrypted at rest, and customer-managed KMS keys should rotate automatically.
Network paths open to the internet
Look for security groups that allow SSH or RDP, or any inbound traffic, from anywhere on the internet. Internet-facing Application Load Balancers should serve HTTPS and redirect plain HTTP to it.
Logging and detection that is off or incomplete
Auditors commonly look for evidence that activity is recorded and watched: CloudTrail logging in every region with log file validation, GuardDuty threat detection, AWS Config recording configuration changes, and VPC flow logs.
Where TrustProof fits
TrustProof helps you prepare on AWS and gives your CPA firm an organised place to review the evidence.
- Free AWS scan: one free initial scan per verified workspace, through a read-only role, with findings ranked by risk and mapped to four selected SOC 2 criteria (CC6.1, CC6.6, CC6.7 and CC7.2). No card is required. See the free AWS scan.
- Growth plan: a one-off A$5,999 Readiness Programme plus A$899 a month or A$8,999 a year for your first framework, including GST. For SOC 2 it includes the guided SOC 2 readiness programme, with plain-language questions, policy and procedure templates and owner sign-offs, alongside the AWS checks. Continuous monitoring with daily rescans comes with the Corporate and Enterprise plans, from A$2,199 a month. See pricing.
- Fixes: prepared fixes run only after your engineer approves each one, through a separate role you add; the scanning connection stays read-only. One-Button Fix is A$1,499 one-off for one AWS account, and the Corporate and Enterprise plans include fixes.
- Auditor Dashboard (early access): your CPA firm gets its own sign-in, protected by two-step verification, and reviews the evidence you release, read-only and for a limited time. The CPA dashboard lists each mapped SOC 2 criterion with its evidence, source and collection date, and exports to PDF or CSV. See the Auditor Dashboard.
TrustProof does not issue SOC 2 reports, does not certify and does not decide audit outcomes. The opinion is always your CPA firm’s.
FAQ
Frequently asked questions
Is SOC 2 a legal requirement in Australia?
No. SOC 2 is a voluntary attestation. Australian SaaS companies usually need one because customers ask for it in procurement or write it into contracts.
Should we start with a Type 1 or a Type 2 report?
Ask your customers which they will accept. Many ask for Type 2, which covers an observation period. A Type 1, at a single date, can be a first step if your customers accept it while the Type 2 period runs.
Does TrustProof issue SOC 2 reports?
No. Only a licensed CPA firm can issue a SOC 2 report, after its own examination. TrustProof helps you prepare your AWS environment and evidence and gives your CPA firm a read-only place to review it.
Do we need SOC 2 if we already have ISO/IEC 27001?
It depends on your customers. Some accept an ISO/IEC 27001 certificate; others, particularly in the US, ask for SOC 2 specifically. Much of the work, such as policies, access reviews and AWS evidence, can be reused for both.
Can TrustProof change our AWS account?
Not through the read-only connection. Fixes need a separate role that you add, and each fix runs only after your engineer approves it.
What does it cost to start?
The first AWS scan is free. The Growth plan is a one-off A$5,999 Readiness Programme plus A$899 a month or A$8,999 a year. All prices are in Australian dollars and include GST.