SOC 2 for NZ and Australian SaaS: A Practitioner's Readiness Guide

SOC 2 reports on a defined system: the product, the infrastructure it runs on, the people and processes that operate it, and the data it handles. A tight, honest boundary is the single biggest lever on cost and timeline.

What the auditor tests

That the system description matches what is actually in scope, and that controls cover everything inside the boundary.

Do this first

Draw the boundary on one page: the product, production cloud accounts, supporting SaaS tools, teams and data flows. Start with Security only unless a contract demands more.

Evidence produced

• Scope and boundary document
• Data flow and architecture diagram
• List of in-scope systems and subservice organisations

The Common Criteria start with the control environment: who is accountable, how leadership oversees security, and whether policies reflect how the company really works.

What the auditor tests

Approved policies, defined roles and evidence that leadership or the board reviewed security during the period.

Do this first

Name a security owner, approve a short policy set (information security, access, change, incident, vendor, acceptable use), and put security on the board or leadership agenda at least twice a year.

Evidence produced

• Approved policies with version and review dates
• Organisation chart and security roles
• Board or leadership minutes covering security

SOC 2 expects you to identify what could stop you meeting your commitments to customers, including fraud and significant changes to the business, and to decide what you will do about each risk.

What the auditor tests

A risk assessment performed during the period, covering fraud and change, with risks linked to controls or accepted by an owner.

Do this first

Run a two-hour workshop with leadership and engineering, score the top 20 risks, link each one to a control or a named acceptance, and diarise a repeat at least annually.

Evidence produced

• Risk register with scores, owners and treatment
• Fraud risk considerations
• Dated sign-off of the assessment

Auditors sample new starters across the period and check that each one was screened, signed the right agreements and completed security training on time.

What the auditor tests

For a sample of joiners: background checks proportionate to the role, signed confidentiality and policy acknowledgements, and training completed within your stated timeframe.

Do this first

Add screening, policy acknowledgement and security training to the onboarding checklist, with a deadline such as 30 days, and run annual refresher training for everyone.

Evidence produced

• Onboarding checklist records
• Signed confidentiality and policy acknowledgements
• Training completion report

Access is the most heavily sampled area in most SOC 2 audits. Every grant needs an approval, and every leaver needs evidence that access ended on time.

What the auditor tests

For samples of joiners, movers and leavers: approved access requests, and removal from production, SaaS tools and the identity provider within your stated timeframe.

Do this first

Route all access through single sign-on where possible, use a ticket or form for every grant, and make offboarding a checklist triggered by HR with a same-day or next-day target.

Evidence produced

• Access request tickets with approvals
• Offboarding tickets with completion timestamps
• Identity provider audit logs

A periodic review proves that access still matches each person's role. Auditors look at whether the review happened, who did it, and whether the changes it found were actually made.

What the auditor tests

Completed reviews for each quarter of the period, signed by an appropriate owner, with evidence that inappropriate access was removed.

Do this first

Export users and roles from production, the cloud console, code repositories and key SaaS tools, have each system owner confirm or revoke, and save the export, decisions and tickets together.

Evidence produced

• Quarterly access review exports with reviewer sign-off
• Tickets for access removed as a result
• Privileged account list

Strong authentication protects the system boundary from outside threats. Enterprise buyers ask about it in every questionnaire, and auditors test it directly.

What the auditor tests

MFA enforced on the identity provider, cloud consoles, code repositories and remote access, with password settings that match your policy.

Do this first

Enforce MFA in the identity provider and every cloud console, require it for code repositories and admin tools, and block sign-in methods that bypass it.

Evidence produced

• Identity provider MFA policy configuration
• Cloud console MFA reports
• Password policy settings

Encryption is expected for customer data in every SOC 2 scope. The auditor will want to see configuration, not a statement in a policy.

What the auditor tests

TLS on external endpoints, encryption at rest for databases, storage and backups, and restricted access to key management.

Do this first

Export encryption settings for databases, object storage, backups and laptops, confirm TLS versions on public endpoints, and restrict who can manage keys.

Evidence produced

• Cloud encryption configuration exports
• TLS scan results for public endpoints
• Key management access list

SOC 2 expects you to find and fix weaknesses on a defined timeline. A penetration test is not named in the criteria, but auditors commonly accept it as a separate evaluation of controls, and most enterprise buyers ask for one each year.

What the auditor tests

Regular scanning, remediation within the timelines in your policy, and follow-up of findings from any penetration test.

Do this first

Turn on dependency and container scanning in the build pipeline, scan infrastructure at least monthly, set remediation timelines by severity, and book an annual external penetration test.

Evidence produced

• Scan reports with remediation dates
• Penetration test report and retest results
• Vulnerability management policy with timelines

Monitoring must be more than collecting logs. Auditors look for alerts that fire on meaningful events and evidence that someone looked at them.

What the auditor tests

Logging on in-scope systems, alert rules for key events, and a sample of alerts showing they were triaged.

Do this first

Centralise cloud audit logs, identity provider logs and application security logs, alert on privileged changes and suspicious sign-ins, and record each triage decision in a ticket.

Evidence produced

• Log source and retention configuration
• Alert rules
• Sample of alert tickets with triage notes

If an incident occurs during the period, the auditor will trace how you handled it. If none occurs, they will want to see that the plan was tested.

What the auditor tests

An approved incident response plan, records for any incidents in the period, and evidence of a test or tabletop exercise.

Do this first

Write a short plan with severity levels, roles, customer notification steps and regulator obligations, then run a tabletop exercise before the period starts.

Evidence produced

• Incident response plan
• Incident tickets and post-incident reviews
• Tabletop exercise record and actions

SOC 2 asks whether you check that your own controls work and fix the gaps you find. This is the control that catches drift before the auditor does.

What the auditor tests

Ongoing or periodic evaluations of controls, with deficiencies reported to the right people and tracked to closure.

Do this first

Run a monthly control health check: are access reviews, scans, training and backups on schedule? Log any misses as deficiencies with owners and dates.

Evidence produced

• Monthly control health checks
• Deficiency log with owners and closure dates
• Internal review or readiness assessment report

For a SaaS company, change management is the core of SOC 2. Auditors sample changes across the period and check that each was reviewed, tested and approved before it reached production.

What the auditor tests

For a sample of production changes: a ticket or pull request, peer review by someone other than the author, passing tests, and controlled deployment.

Do this first

Protect the main branch, require at least one reviewer who is not the author, run automated tests in the pipeline, and deploy only through the pipeline.

Evidence produced

• Branch protection settings
• Sample pull requests with reviews and test results
• Deployment logs from the pipeline
• Emergency change records

Auditors and buyers increasingly ask how security is designed in, not just tested at the end. A light, written secure development standard covers most of it.

What the auditor tests

A defined secure development process, security considered in design for significant changes, and separation between development and production data.

Do this first

Write a two-page secure development standard covering threat review for significant features, secrets handling, dependency management and use of production data in testing.

Evidence produced

• Secure development standard
• Design review or threat model records for significant changes
• Secrets scanning configuration

Your SOC 2 relies on your cloud provider and other subservice organisations. You need to show you assess vendors, review their reports, and operate the controls their reports say you must.

What the auditor tests

A vendor inventory, risk-based reviews during the period, and review of subservice organisation SOC reports, including the complementary controls they expect from you.

Do this first

List vendors with access to customer data or production, collect current SOC 2 or ISO 27001 evidence for the critical ones, and record which complementary controls you operate.

Evidence produced

• Vendor inventory with risk tiers
• Vendor review records
• Subservice organisation SOC reports with review notes

Recovery sits in the Common Criteria and becomes central if you include Availability. Auditors want to see backups running, restores tested and a continuity plan that matches your commitments.

What the auditor tests

Backup configuration and monitoring, a restore test during the period, and, for Availability, capacity monitoring and a tested recovery plan.

Do this first

Confirm automated backups for every production data store, run and document a restore test, and align recovery objectives with what your contracts promise.

Evidence produced

• Backup configuration and job monitoring
• Restore test record
• Business continuity and disaster recovery plan with test results

Every SOC 2 report contains management's description of the system, written against the AICPA description criteria. The auditor gives an opinion on whether it is fairly presented.

What the auditor tests

That the description covers services, infrastructure, software, people, data, procedures, commitments and complementary controls, and matches what the auditor observes.

Do this first

Draft the description early from your scope document, then update it as controls are implemented. Include the complementary user entity controls your customers must operate.

Evidence produced

• Draft system description
• Service commitments and system requirements
• List of complementary user entity controls

Evidence scattered across a dozen tools is where audits slip. Collect it in one system of record, then run a mock audit before the real one.

What the auditor tests

Not tested directly, but it decides how smoothly fieldwork runs and how many follow-up requests you receive.

Do this first

Map each control to the evidence it produces and where that evidence lives, then have someone independent of the work sample it as an auditor would.

Evidence produced

• Control and evidence matrix
• Readiness assessment report
• Remediation log for readiness findings

Only an independent licensed CPA firm can issue a SOC 2 report. The firm's scope, sampling approach and calendar shape your plan, so engage them before you finish building controls.

What the auditor tests

Not a control, but auditor independence is what makes the report credible: your readiness advisor cannot be your auditor.

Do this first

Shortlist firms that audit SaaS companies your size, confirm the report form your customers will accept, and agree the Type I date or Type II period before you lock the plan.

Evidence produced

• Engagement letter
• Agreed report type, scope and period
• Fieldwork calendar and request list