SOC 2 for startups: when you need it and what it takes

Key points

• SOC 2 is an attestation report signed by a licensed CPA firm, not a certificate and not a law.
• A Type 1 report looks at whether controls are designed well at a point in time. A Type 2 also tests whether they worked over a period the auditor sets.
• The trigger is a customer: usually a larger business whose procurement or security team asks for the report.
• Security is the category every SOC 2 covers. Add availability, processing integrity, confidentiality or privacy only when customers need them.
• Most of the work is engineering habit: access control, logging, change management, vendor review and backups, with records that show they happen.
• Build the habits first, answer questionnaires honestly, then bring in an auditor when a deal needs the report.

What SOC 2 is, and what it is not

SOC stands for System and Organization Controls, a family of reports the AICPA, the American accounting body, sets the standards for and licensed CPA firms produce. A SOC 2 is an examination of a service organization: a company that runs something for its customers, such as a SaaS product that stores their data. The AICPA describes it as an examination of the company’s description of its system and of its controls relevant to security, availability, processing integrity, confidentiality or privacy. Customers and business partners request it because outsourcing to you creates risk for them, and the report gives them evidence to judge it.

The yardstick is the Trust Services Criteria, published by the AICPA’s Assurance Services Executive Committee. There are five categories:

• Security. Protection against unauthorized access and use. Every SOC 2 covers it, through what the criteria call the common criteria.
• Availability. Whether the system is up and usable as committed to customers.
• Processing integrity. Whether processing is complete, accurate, timely and authorized.
• Confidentiality. Whether information designated confidential is protected as committed.
• Privacy. How personal information is collected, used, kept, disclosed and disposed of.

Three things SOC 2 is not. It is not a certification: an auditor gives an opinion, so “SOC 2 certified” is a loose phrase for “has a SOC 2 report”. It is not a fixed checklist: you design controls that fit your company, and the auditor judges them against the criteria. And it is not a law. It says nothing on its own about whether you meet GDPR, HIPAA or any other legal duty.

A SOC 2 report is detailed, so companies usually share it with customers under a nondisclosure agreement. Its sibling, SOC 3, covers the same categories in less detail, and the AICPA treats it as a general-use report that can be freely distributed, for example from a website.

Type 1 vs Type 2

A Type 2 cannot be rushed, because it reports on what happened over the period, not on what is in place today. That is the main reason to start the habits early: records from before the period do not count, but a team already working this way has nothing to change when the period starts.

When business customers ask for it

SOC 2 is a sales question before it is a security one. Signs that you need it:

• A buyer’s procurement or security team sends a questionnaire that asks for your SOC 2 report, or makes one a condition of the contract.
• You sell to companies in regulated fields, such as finance, insurance or health care, which have to manage the risk of their own vendors.
• Your product stores your customers’ data, or sits inside their daily work, so a failure on your side becomes theirs.
• Deals stall in security review, and the same questions come back from every buyer.

You probably do not need it yet if you sell to consumers or small businesses, are running early pilots, or no buyer has asked. When one does, ask exactly what they need: a SOC 2 Type 2, any independent report, or answers to their questions. Many accept a completed questionnaire and a written description of your practices for a first contract.

Alternatives and neighbours

ISO/IEC 27001 and SOC 2 overlap a great deal. ISO describes 27001 as requirements for establishing, maintaining and continually improving a management system for information security, and a certificate from an accredited body as one way to show customers you can manage information securely. Which one buyers ask for varies by market and industry, so ask your customers before you choose. The Cloud Security Alliance’s STAR registry shows how the pieces stack: a self-assessed CAIQ at its first level, and at its second level a CAIQ backed by an ISO/IEC 27001 certification or a SOC 2 attestation.

What it touches in your product and engineering

Policies are part of SOC 2, but most of the work is in how the product is built and run. An auditor will ask to see each of these working, not only described.

• Access control. Single sign-on and multi-factor authentication for every internal tool, no shared accounts, least privilege, a process for people joining, changing role and leaving, and periodic reviews of who has access. Inside the product, roles that limit what each user can do; see What is RBAC?.
• Logging and monitoring. Audit logs of who did what in the product and in admin tools, kept centrally and protected from tampering, with alerts someone actually reads.
• Change management. Every change goes through a pull request, is reviewed by someone other than its author, passes automated tests and reaches production through a pipeline, never by hand; What is CI/CD? explains the pipeline.
• Vendor management. A list of every vendor that touches customer data, a review of each one’s own security reports, contracts that cover data handling, and a list of subprocessors you can show customers.
• Backups and recovery. Automated, encrypted backups, restores that are tested rather than assumed, and a written plan for recovering the service.
• Data protection. Encryption in transit and at rest, keys kept out of the code, and one customer’s data kept apart from another’s; Multi-tenant architecture covers the models.
• Incident response. A written plan for who does what when something goes wrong, and a record of every incident and how it was handled.

The pattern behind all of it is evidence. Pull request history, pipeline logs, access review tickets and restore tests produce the records an auditor samples as a by-product of normal work. The application-level checks, from injection to broken access control, are in the Web app security checklist.

The order to tackle it in

1. Ask your buyers what they need: which report, which type, which categories. Then set the scope: which product, which systems and which people the report will cover.
2. Fix the basics. Multi-factor authentication everywhere, no shared accounts, least privilege, and an inventory of your systems, data and vendors.
3. Put change management into the pipeline: protected main branch, required review, automated tests and deploys that leave a record.
4. Add central logging, encrypted backups with a tested restore, and a written incident response plan.
5. Write policies that describe what you actually do, name an owner for each, and have the team read and acknowledge them.
6. Run a readiness assessment, a gap check against the criteria, and fix what it finds before the audit starts.
7. Choose a licensed CPA firm. The AICPA urges companies to evaluate SOC providers thoroughly, and says it will act against member auditors who do not follow professional standards, are not enrolled in peer review or are unlicensed. Compliance software can collect evidence, but it does not replace the auditor.
8. Decide with your buyers whether to start with a Type 1 or go straight to a Type 2, then keep the controls running: SOC 2 is renewed, not passed once.

Before you have a report

• Answer questionnaires truthfully. A buyer who finds an overstated answer later trusts nothing else you said.
• Never say “SOC 2 compliant” or show a badge before an auditor has issued a report. “We are preparing for a SOC 2 examination” is honest, if it is true.
• Publish a short trust page: how data is protected, which vendors process it, and how to request more detail.
• Keep the vendor list and the records from the start. They are much harder to rebuild than to keep.

This guide is general information, not legal or audit advice. A CPA firm can tell you what your report will need, and a lawyer what your contracts promise.

When BYD Tech builds a product, the code lives in the client’s GitHub from day one and AI-assisted work is reviewed by an engineer, so the history an auditor samples starts with the first commit. The audit itself is between you and a CPA firm. Web app development describes how a build starts.