SOC 2 Compliance Checklist for Australian Companies

A SOC 2 checklist is only useful if it reflects what an auditor will actually test, not a generic list of security buzzwords. Over more than two hundred assessments I have watched companies work through tidy-looking checklists and still walk into a qualified opinion, because the checklist covered topics rather than evidence. This is a control-by-control checklist for Australian companies preparing for a SOC 2 examination, written the way I run readiness engagements: each item is something you must be able to show an auditor, not just claim. Work through it honestly and you will know exactly where you stand before a CPA firm ever opens your report.

First, Understand What You Are Being Measured Against

SOC 2 is an attestation framework from the American Institute of Certified Public Accountants (AICPA). An independent CPA firm examines your controls against the Trust Services Criteria and issues a report. There are five criteria categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security, the common criteria, is mandatory. The rest are included only where they are relevant to your service. So before you touch the checklist, make two decisions: which criteria are in scope, and whether you are pursuing a Type 1, which assesses control design at a point in time, or a Type 2, which assesses operating effectiveness over a period. Those choices determine what evidence each checklist item below actually requires. If you want the reasoning behind them, see SOC 2 Type 1 vs Type 2.

The SOC 2 Readiness Checklist

1. Scope and Data Inventory

You cannot secure what you have not mapped. Before any control makes sense, you need a clear boundary.

• Document the product or service the report covers and draw its system boundary.
• Inventory every system, cloud service, database and application that stores or processes customer data.
• Map data flows, including where data enters, rests, moves and leaves.
• List your subservice organisations, such as AWS, Azure or Google Cloud, because they are part of your control story.

2. Governance and Policies

Auditors expect written, approved, dated policies that your team actually follows. A policy nobody applies creates an evidence gap.

• Information security policy, approved by leadership and reviewed at least annually.
• Acceptable use, access control, change management, incident response and business continuity policies.
• A named owner accountable for the security programme with genuine authority.
• Evidence that policies are communicated to staff and acknowledged.

3. Risk Assessment

• A formal, documented risk assessment covering threats to the in-scope systems.
• Risks rated, assigned owners, and tracked to treatment rather than filed and forgotten.
• A defined cadence for revisiting the assessment, not a one-off document.

4. Access Control and Identity

This is the single most heavily tested area in most SOC 2 examinations.

• Multi-factor authentication enforced on all systems, especially administrative and remote access.
• Least-privilege access, with roles defined and administrative rights restricted.
• Periodic access reviews that are performed and documented, quarterly is common.
• Prompt de-provisioning when staff leave, evidenced by tickets or logs.
• A password and secrets management standard that is actually enforced.

5. Change Management

• Code and infrastructure changes reviewed and approved before release.
• A traceable record for each change, so the auditor can sample across the observation window.
• Separation between the person who writes a change and the person who approves or deploys it, where feasible.

6. Logging, Monitoring and Detection

• Centralised logging across in-scope systems.
• Alerting on security-relevant events, with evidence that alerts are triaged, not ignored.
• Retention aligned to your policy and your customers' expectations.

7. Encryption and Data Protection

• Data encrypted in transit using current protocols.
• Data encrypted at rest, with key management handled sensibly.
• A data classification and handling approach so sensitive data is treated accordingly.

8. Vendor and Third-Party Management

• A register of key vendors and subservice organisations.
• Review of their security posture, for example by collecting their own SOC 2 reports.
• Contracts that reflect your security and data protection expectations.

9. Incident Response and Resilience

• A written incident response plan with defined roles and escalation paths.
• Evidence that the plan has been tested, for example through a tabletop exercise.
• Backups configured and, crucially, restore-tested rather than assumed to work.
• A business continuity or disaster recovery plan appropriate to your service.

10. People and Awareness

• Security awareness training for all staff, with completion records.
• Background checks where appropriate and lawful.
• Clean onboarding and offboarding procedures tied to access provisioning.

How the Checklist Maps to Evidence

The mistake I see most often is confusing having a control with being able to prove it. For a Type 2 in particular, the auditor samples evidence across the whole observation window. Here is how a few checklist items translate into what you must actually produce.

Checklist item	What the auditor wants to see
Access reviews	Dated review records for each period, showing who reviewed and what changed
Change management	Change tickets across the window, with approvals recorded
MFA enforcement	Configuration evidence plus a sample of accounts showing it is applied
Backups	Backup logs and, importantly, a documented restore test
Incident response	The plan plus evidence of a test or a handled real incident
Awareness training	Completion records for staff in scope across the period

If any row makes you uncomfortable, that is your gap. Better you find it now than the CPA firm finds it during fieldwork.

Turning the Checklist Into a Plan

A checklist tells you what; it does not tell you the order. From experience, sequence the work like this:

1. Lock the scope and criteria first. Everything downstream depends on it.
2. Run a readiness assessment against this checklist to find the real gaps. A structured SOC 2 readiness assessment is far cheaper than discovering gaps mid-examination.
3. Remediate the high-impact, high-effort items first, especially access reviews and change management, because they need time to accumulate evidence.
4. Start the observation window only once controls are genuinely operating.
5. Instrument evidence collection from day one of the window so you are not reconstructing it later.

Much of this control set overlaps with ISO 27001, so if you are pursuing both, do them together rather than twice; I compare them in ISO 27001 vs SOC 2. And because a checklist only proves design, validating that controls hold up in reality is where an independent IT security audit and penetration testing add real assurance beyond the paperwork.

The Items Companies Most Often Fail

• Access reviews that were never actually run. Everyone intends to; few have the dated records.
• Untested backups. Configured is not the same as recoverable.
• Change management living in people's heads. No tickets means no evidence across the window.
• Policies with no proof of adoption. An unread policy is an audit finding waiting to happen.
• Vendor management as a folder of PDFs. Auditors want to see active review, not collection.

Where a vCISO Fits

Most companies reaching for their first SOC 2 do not yet have a full-time security leader to own this checklist end to end. That is where a virtual CISO makes the difference: setting the scope, running the readiness assessment, sequencing remediation so evidence accumulates in time, and managing the CPA firm relationship so the examination is a confirmation rather than a discovery. Done well, the checklist stops being a source of anxiety and becomes a simple status board you can show a buyer's security team with confidence.

Frequently Asked Questions

What is the hardest part of a SOC 2 checklist to satisfy?

Consistently the evidence-heavy operational controls: documented access reviews, traceable change management, and restore-tested backups. These fail not because companies lack the control but because they cannot prove it operated across the entire observation window.

Do I need all five Trust Services Criteria?

No. Security is mandatory. Add Availability, Confidentiality, Processing Integrity or Privacy only where they are relevant to your service and to what your customers ask for. Including unnecessary criteria adds cost and effort without commercial return.

Can I use this checklist for both Type 1 and Type 2?

Yes. The control set is the same. The difference is evidence: a Type 1 assesses whether controls are designed correctly at a point in time, while a Type 2 requires proof that they operated across the observation window, typically three to twelve months.

How long before the audit should I start working the checklist?

Ideally several months. Remediation itself takes time, and for a Type 2 you then need an observation window during which the controls run and generate evidence. Companies with an existing ISO 27001 posture can compress this considerably.

Does automation software make the checklist unnecessary?

No. Automation tools help collect and monitor evidence, but they do not design your controls, decide your scope, or exercise judgement about relevance. They are useful once you know what you are doing; they are not a substitute for understanding the checklist.

Who signs off on the checklist being complete?

Internally, your security owner or vCISO. Formally, the SOC 2 opinion comes from an independent licensed CPA firm that examines your controls. The checklist gets you ready; the CPA firm attests.

Getting Started

Treat this checklist as a mirror, not a wish list. Go through each item and ask whether you could hand an auditor the evidence today. Wherever the answer is no, you have found your remediation work. Close those gaps, let the controls run, and the examination becomes straightforward. If you want an experienced partner to run the readiness assessment and steer the programme, get in touch.