SOC 2 readiness for SaaS: the engineering work involved

SOC 2 readiness for SaaS is the work of getting your controls designed, running and producing evidence before an independent CPA firm examines them. Policies are the smaller part. Most of the effort is engineering: who can access production, how changes reach it, what gets logged, how you recover from failure, and whether you can prove each of those from system records. Teams that build these controls into their platform find later examinations much less disruptive.

This article is general information, not audit or legal advice. Your auditor determines what your examination requires, so confirm scope and expectations with them.

What a SOC 2 report is

The AICPA describes System and Organization Controls (SOC) as a suite of services that CPAs may provide in connection with controls at a service organization. A SOC 2 examination reports on controls relevant to security, availability, processing integrity, confidentiality or privacy.

Three points are worth knowing before you plan:

• The criteria. Controls are evaluated against the AICPA’s Trust Services Criteria. The current set is the 2017 criteria with points of focus revised in 2022. In October 2026 the AICPA listed exposure drafts of proposed 2027 criteria, so ask your auditor which version will apply to your period.
• The description. Your organization prepares a description of its system, and the AICPA publishes separate description criteria for preparing and evaluating it. Expect your engineers to contribute much of the content.
• The examiner. The report comes from a CPA acting as service auditor. Compliance software and consultants can help you prepare, but they do not issue the report.

Type 1 and type 2: why engineering habits matter

SOC 2 offers two report types. A Journal of Accountancy overview of the SOC reports explains the difference: a type 1 report covers the system description and the suitability of the design of controls as of a specified date, and a type 2 report adds an opinion on the operating effectiveness of those controls throughout a specified period, along with the auditor’s tests and results.

For engineering, this changes the question. A type 1 asks whether a control exists and is designed sensibly. A type 2 asks whether it worked every time, for the whole period. A code review rule that was bypassed for a handful of urgent fixes, or an access review that slipped a quarter, becomes an exception in the report. Controls that depend on people remembering are the ones that fail, so the reliable route is to make the system enforce them.

The engineering work behind SOC 2 readiness for SaaS

The criteria do not prescribe tools. They state outcomes, and you choose controls that fit your system. The areas below are the ones that usually land on the engineering team, with the kind of evidence an auditor typically asks to see. Your scope and auditor decide the final list.

If your product is multi-tenant, expect questions about how one customer’s data is kept apart from another’s. The options are covered in the article on multi-tenant SaaS architecture.

A readiness sequence that works

1. Define the system boundary. List the product, environments, cloud accounts, people and vendors that are in scope. Keep it as narrow as your customers’ needs allow.
2. Choose the categories. Decide with your auditor which of security, availability, processing integrity, confidentiality and privacy to include, based on what customers ask for.
3. Engage the auditor early. Agree the criteria version, the report type and the period before you build controls around assumptions.
4. Run a gap assessment. Map each criterion to a control you already have, a control you need, and the evidence it produces.
5. Close gaps by automating. Prefer controls enforced by the pipeline, the identity provider or cloud policy over controls enforced by a checklist.
6. Write policies that match reality. A policy describing what you do today is safer than one describing what you hope to do.
7. Collect evidence continuously. Pull it from system records on a schedule, so the audit period is not a scramble.
8. Do a dry run. Sample your own changes, access grants and incidents the way an auditor would, and fix what you find.

Common pitfalls

• Treating a tool as the outcome. Compliance platforms collect evidence. They do not design your controls or operate them.
• Chasing speed over substance. The AICPA’s SOC page currently carries a notice stressing that SOC services should be thoroughly evaluated by service organizations and CPA firms. Check your auditor’s licensing and peer review status.
• Policies copied from a template. If the policy promises quarterly reviews and you run them yearly, you have written your own exception.
• Screenshots as evidence. Manual evidence goes stale and takes engineer time. System exports and API pulls are repeatable.
• Scope creep. Every extra environment or product in scope adds controls to operate and test.
• Untracked exceptions. Emergency changes happen. Record them, review them afterward and show the trail.

How YLinkTech helps

We are an engineering firm, not a CPA firm, so we do not perform SOC 2 examinations or issue reports. What we do is the engineering work that readiness depends on. For software and high-tech companies, our Cloud and Modernization practice builds access controls, logging and encryption through its cloud security and compliance work, and enforces change control in the pipeline through DevSecOps and platform engineering. Talk to us about preparing your platform.

Frequently asked questions

Sources

• AICPA & CIMA: System and Organization Controls: SOC Suite of Services
• AICPA & CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• AICPA & CIMA: 2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022)
• Journal of Accountancy: Explaining the 3 faces of SOC (2016)

This article is general information, not professional advice. See our Disclaimer.